GNOME Online Accounts: why it is the way it is
This keeps cropping up every now and then, so I thought of writing this down once and for all. Private conversations are poisonous for a community driven free software project like GNOME.
Background
In the new GNOME 3.x series there has been a push to integrate the user’s online accounts into the desktop. Towards this end, almost a year ago, a new single sign-on (SSO) framework was written for GNOME 3.2. However, more recently, Ubuntu created its own SSO to achieve a similar objective.
An SSO is only as effective as the applications that use it, and having to support two different frameworks with their own set of APIs and ways of doing things is a pain for application developers. Given the long history between the two projects, it is not surprising that they also share quite a few applications, and in turn developers.
The split
Ubuntu’s SSO is based on the one used by MeeGo, while GNOME wrote its own. I do not know why Ubuntu decided not to use GNOME Online Accounts (GOA), because they decided to switch after GOA was born.
But why did GNOME write its own when MeeGo already had one? Sounds like NIH, doesn’t it?
However, it is a bit more complicated than that. MeeGo (and now Ubuntu’s) SSO has a DBus daemon written using Qt. We have been down this road before, most recently with Maliit. The daemon would have had to be rewritten without Qt using GObject for it to be a part of GNOME. This problem has only increased with Ubuntu reimplementing the signon-ui service using QWidgets and QtWebKit, which is then embedded into System Settings using XEmbed. MeeGo’s implementation of this service was proprietary.
Secondly, MeeGo used libdbus-glib-1 instead of GDBus when the discussion to use it in GNOME first took place. I do not know whether it has changed since then or not. We have been actively trying to move away from libdbus-glib-1 to GDBus. One of the problems with libdbus-glib-1 is that it is not thread-safe. If we mix the two in an application, the same process will end up having two connections to the DBus daemon. We want to avoid that. This means that we would have to migrate it to GDBus.
Both of these would require non-trivial changes to the code and hence it is not as NIH as one might think it to be.
Not to mention that the pass through authentication scheme used by MeeGo would only make it harder to patch existing applications to use the SSO.
Ofcourse, one can argue that we could have still tried to push the needed changes to MeeGo. Maybe we could have done so, but I am not convinced that it would have made life any easier for GNOME, MeeGo or Ubuntu. More on that later.
Third-party plugins
One of the ways in which Ubuntu’s SSO differs from GNOME’s is that it allows third-party plugins to offer new account types or providers. They leverage this to make Empathy export its code for adding chat accounts (Jabber, SIP, etc.) via external plugins. While we do agree that plugins can be useful, we are not too excited about allowing third-party or external plugins. We intend to support in-tree plugins for GNOME Online Accounts.
Third-party plugins lead to a kitchen sink. There is no way you can stop them from stepping on each others feet. This was one of the reasons why we stopped supporting external panels in the System Settings against a lot of stiff opposition.
Fictitious screenshot showing duplicate providers supplied by 3rd party plugins.
Someone’s kitchen sink can be another’s extensibility. However GNOME 3 is still young and I think it is important to stay clear of kitchen sinks at this point.
There is no fundamental reason not to have all the different types of chat accounts supported by Empathy in the SSO itself, as long as we take care not to clutter the UI and keep the popular ones separate from the rest. The thumb rule for adding a new account type to the SSO is to have a GNOME application that hooks into it. In this case, we have two — Empathy and GNOME Shell.
Thirdly, having an application provide a new account type via a plugin violates the basic layering of the GNOME platform. This is mostly a good taste vs. bad taste thing. The SSO is supposed to be right at the bottom serving accounts and credentials. Things like libgdata, libzapojit, libsocialweb, etc. sit on top of it and leverage the information as GDataGoaAuthorizer and ZpjGoaAuthorizer currently do. Then you have the applications using these libraries to offer something useful to the users. In fact Empathy already works this way in GNOME.
Having a circular dependency where applications provide critical functionality to the SSO via plugins, which they then consume, only complicates the whole platform.
GNOME and Ubuntu
Recently GNOME and Ubuntu has diverged quite a bit in their plumbing layers. Think in terms of gdm vs. lightdm, systemd vs. upstart, gnome-shell vs. unity, and so on. Both projects are focused on building a vertically integrated product, and it is only fair that they get the liberty to make decisions that are best for them and be free to fail or succeed without getting flamed.
Then there is the issue of copyright license / assignment agreements that Canonical asks for those components that are hosted on Launchpad. For example, signon-ui. I am not a lawyer, but my understanding is that GNOME has always stepped carefully when it comes to signing these agreements with a company because it makes it tricky for competing commercial entities to participate.
This is why I am doubtful that we would have ever been able to merge or share everything because this divergence is only going to increase. The SSO will closely tie in to the way we will do application bundles and sandboxing in GNOME, which in turn will depend on systemd. These things are still being hotly discussed within GNOME, so I do not know what the exact implementation will be neither do I know what Ubuntu plans to do, but it is possible that theirs will be different.
So, if one wants to make sure their application is both a GNOME and an Ubuntu application they will have to spend some extra effort to make sure that it works well on both platforms. But it is not bad as it sounds. Both GNOME and Ubuntu are doing a great work of taking free software on the desktop forward, and the effort spent in supporting both will only be rewarded by a greater number of users.
Debarshi's den 
Hi Debarshi! What I would have liked to see back then when GOA was born is at least some cooperation to figure out the common points between the MeeGo implementation and the yet-to-be-written GOA; maybe a common D-Bus API, or at least some agreement on the features and the concepts, so that it could be possible to keep the client API similar and make life easier to application developers.
My understanding is that the MeeGo solution was only quickly investigated, and as soon as some (perfectly valid) reasons not to use it in GNOME were found, it was happily discarded and ignored. Indeed, the effort on taking something existing, studying it and improving it is generally higher than starting from scratch; but this is exactly what NIH is about, and it can be detrimental in the long run. I guess that part of the reason to start something new was the understanding that MeeGo would soon be dead and all that code become unmaintained and irrelevant (as at that point Ubuntu was not using it). Luckily (or unlikely, depending on the point of view) that didn’t happen, and now we find ourselves in this awkward position.
IMHO, the biggest drawback in GOA — though you also seem to defend it in your blog post — is the third-party extensibility; I might be wrong here, but I think that if GOA had been more extensible, Ubuntu wouldn’t have looked for a different solution. This just my guess, of course.
Alberto Mardegan (@mardy)
6 October, 2012 at 14:24
Hey Alberto!
Yes, trying to investigate if we can work towards a common DBus API makes sense. Some of us from GNOME tried to reach out to various folks in Ubuntu regarding this after GUADEC. But we have not heard back anything from “the other side” yet. I know this sounds vague and hazy but I don’t want to take names of individuals involved in private conversations and emails on the public Internet. There is no need to fuel the gossip mills. 🙂
So maybe we should talk about it on IRC some time. I am ‘rishi’ on Freenode and GIMPNet.
While I am happy that the code found a new life, I don’t know why Ubuntu decided not to use GOA. I don’t know what they could not have achieved with downstream patches, because currently they are having to patch the System Settings and various applications anyway. If I had known we could have worked it out.
Maybe Ubuntu had valid reasons to do their own thing. They are building their own product and should have the freedom to choose what is best for them, and I wish them all the best. It is a joy to see what they have achieved.
Third-party extensibility is interesting, and currently an argument for it is to allow proprietary providers. eg., Skype. But it also opens up a can of worms. We don’t need to open that can right now.
Apart from the layering violation, if Empathy or Evolution starts providing their own IM or email or calendaring providers, then we immediately say no to competing applications like Pidgin or Thunderbird (if it survives). Whether they want to integrate with the SSO, and whether GNOME wants them to use the SSO are open questions. It is a trade-off between spreading and diluting the respective brands.
Debarshi Ray
6 October, 2012 at 16:27
[…] Debarshi Ray printed in his blog an explainable article about the reasons of this split. Ubuntu is using the SSO of Meego while Gnome has written its very own from scratch. The reason that Gnome forced to build a new SSO was that Meego’s SSO has a DBus daemon written using Qt and the deamon had to be rewritten without Qt using GObject for it to be a part of GNOME. […]
GOA and UOA in Ubuntu | woGue
6 October, 2012 at 17:24
Who says that the __daemon__ (SSO, or in the past Maliit) must be part of GNOME? Useful infrastructure services need adoption from a wide range of projects, so branding such essential services like SSO (or input methods) as GNOME “property” would actually lower adoption and therefore usefulness of those projects. To demonstrate the absurdity of your claim that such central services must only use GNOME technology, let’s imagine for a moment that same requirements would be established for the display server, for the C library, for the kernel… Welcome to Absurdistan.
Mathias Hasselmann (@taschenorakel)
6 October, 2012 at 17:54
Hey Mathias!
It was not me who turned down Maliit, was it? 🙂
I could not dig up a citation on the Maliit issue, but I am just stating the status quo. Whether the current practice is right or wrong is a bigger debate, but I am sure it will take a long while for it to change if it ever is going to change.
Having said that, the kernel or the display server are not written in Qt. For years KDE has had a dependency on GObject via Telepathy, Gstreamer, NetworkManager and earlier even Qt. That does seem like an unfair balance of power from KDE’s point of view. But whether that means GNOME should accept Qt is not a decision that is for me or a single individual to make.
Debarshi Ray
6 October, 2012 at 18:49
“That does seem like an unfair balance of power from KDE’s point of view”
What? Really? When did FOSS become a matter of who has “power” over others? I really hope you’re not being serious; this is the sort of attitude that both gnome and KDE devs point to in the other camp, using it to say that we really can’t work with them.
If you’re unhappy with the status quo, change it! Who gives a crap if the daemon is written in Qt? It works, yes? What advantage does spending all that time to rewrite it with gobject give?
workman161
7 October, 2012 at 19:39
I don’t buy the “it should have been rewritten in GObject” argument either. As long as we have the user side lib (the one used to integrate SSO with GNOME apps) as a nice glib/gobject API what’s the problem? And there is one, we integrated Empathy with Ubuntu Online Accounts without writing a single line of Qt.
When KDE people complained that they should not use Telepathy, GStreamer or Folks because it’s written in GObject we argued that was stupid and that code sharing is the best for both projects. We should stay coherent and stick with the same logic here.
guillaumedesmottes
8 October, 2012 at 10:33
There are QWidgets involved via Ubuntu’s signon-ui implementation.
Debarshi Ray
8 October, 2012 at 13:59
[…] Ray, the GOA maintainer has started a public dialog about the GOA/UOA split on his blog. Check it out! […]
Ubuntu Online Accounts and the Ubuntu GNOME Remix « Just Jeremy
6 October, 2012 at 18:07
Debarshi, not blaming you for Maliit. Just wanted to point out that your reasoning that the Maemo’s SSO daemon would have been rewritten in GObject to be acceptible doesn’t work. Similar about libdbus usage. Nothing stops anyone from leaving the SSO daemon in Qt or using libdbus, while wrapping the D-Bus interface with a nice, GNOME friendly GDBus based library. Actually letting applications from different worlds talk with each other was one of the rationales for developing and deploying D-Bus. AFAIR.
(Sorry for not replying directly, wordpress.com doesn’t permit for twitter logins).
Mathias Hasselmann (@taschenorakel)
6 October, 2012 at 20:27
I think the perceived “kitchen sink” problem with 3rd party plugins can be largely mitigated simply by application and framework authors talking to one another. For example if Evolution is first on the scene with a 3rd party plugin for a particular online service and Thunderbird or KMail authors want to provide a similar feature, the best approach is to just talk it over, agree on what’s needed, and see if we can promote the app-specific plugin up into the core framework to be shared among us. But there’s value in allowing application authors to take the initiative in extending the framework, rather than having to first negotiate with a gatekeeper. JFDI, etc.
Matthew Barnes
6 October, 2012 at 20:37
mbarnes – gosh if only there was some kind of conference where all these people could meet up. We do NOT have a middleware type conference wehre we can all freely discuss these things.
sramkrishna (@sramkrishna)
7 October, 2012 at 01:39
@sramkrishna: Next chance might be UDS in Copenhagen end of October. Not too distant from Brno, and the Canonical guys will be there.
Mathias Hasselmann (@taschenorakel)
7 October, 2012 at 16:53
Mathias,
If you are suggesting that I travel to Copenhagen on my own money to talk to a group of people who have not responded to email, who have not responded to invitations on this very page, who privately decided to do go their own way and worked behind closed doors towards that end (read Jeremy Bicha’s blog), who weren’t very forthcoming at GUADEC, then I think I will have to say that I am not interested.
GOA has always been developed in a very open manner — discussions on d-d-l, blogs, public IRC, etc.. Every time something has been turned down (eg., no point in adding Twitter if there is no broad consensus on Gwibber as a Twitter app and Ephy’s webapp mode might be a better idea), or postponed (eg., can’t use OAuth2 for Google because that will break Evolution — this has been solved for 3.8, by the way) a reason has been given via public channels. I have personally harassed various people in GNOME, to come with a solution (eg., a UI design that lets us add fringe non-branded providers without cluttering the UI).
None of the more high level decisions (eg., Twitter or no Twitter) were ever set in stone anyway. How can that be? GNOME 3 is just 1.5 years old. An SSO by itself is useless unless you have good quality applications using it, and we already have some — Evolution, Empathy and Documents. For 3.8, we will have Files, System Settings (background panel) and deepen the integration with the existing applications.
All this talk of how to write a plugin is just a mere detail.
Debarshi Ray
7 October, 2012 at 17:55
Will Files have support for Google drive in 3.8?
Andreas Tunek
7 October, 2012 at 22:47
Good question. 🙂
When I said Files, I had this in mind: https://live.gnome.org/ThreePointSeven/Features/Owncloud
Having said that, there is a fundamental problem that makes it difficult to support something like Google Drive (or earlier Google Documents) in Files. This is because Google Drive being a database driven store does not fit in very well with the abstraction of Gvfs, which is heavily used by Files. So writing a Gvfs backend for such a service becomes tricky. I do remember a Gvfs backend for Google Documents floating around somewhere. Don’t remember what the state of it is.
However, SkyDrive looks a lot closer to the Gvfs model. Therefore, it should be the first target for integration in Files. One would have to write a Gvfs backend using libzapojit for that.
Debarshi Ray
7 October, 2012 at 23:36
The problem is deeper than online accounts.
Each of the shells is developed in its own little world with not much thought about 3rd party app developers, or in many cases even the users. An app developer shouldn’t have to special-case each desktop API as that adds to development cost and therefore makes desktop Linux a less attractive target platform. As for users, why would a KDE user expect a KDE app to behave any differently than a Gnome app? What possible justification is there for users to care?
The problem seems reducable to the fact that there’s no uniform shell API for Linux desktops. FreeDesktop.org was a start but it’s largely stopped covering new ground (i.e. online accounts.) The good news is a third party could create a uniform shell API on their own, the bad news is the amount of work involved. That said, I wish someone would take this on.
Eric Gregory
8 October, 2012 at 22:44
I must say, from the “End-User” Point of view, UOA is much better than GOA, for the following reasons:
GOA doesn’t offer enough services. I can setup my facebook, google, and windows live accounts, but accounts like AIM I have to go through a totally different UI (empathy). This would’t be so bad if these two cooperated, but I found that if I have some accounts set up in GOA (facebook, google, WL), and some set up in empathy (AIM), on a cold boot when I first open empathy the GOA accounts sign in fine, but AIM refuses to sign in until I toggle it on/off. If I set them all up directly through empathy this problem does not occur. In addition when I resume my machine from suspend the opposite happens: Aim signs on fine, the GOA accounts absolutely refuse to sign on until I kill telepathy. I saw these issues in both fedora and arch. With UOA I can set up all my accounts in one place, and experience none of the above “game-breaking” issues.
Brandon Watkins
15 October, 2012 at 07:32
“Ubuntu’s SSO is based on the one used by MeeGo, while GNOME wrote its own. I do not know why Ubuntu decided not to use GNOME Online Accounts (GOA), because they decided to switch after GOA was born.”
That’s a bad start. I think think GOA is better because it was created first. That’s non-sense.
Juan (@reidrac)
14 February, 2013 at 10:28
[…] I sat in Debarshi Ray’s talk on GNOME Online Accounts (GOA) for users and developers. Debarshi did a great job showing how GOA works in GNOME. He had […]
DevConf.cz event, day 1 part 1. » The Grand Fallacy
23 February, 2013 at 14:28
Hi folks,
just a quick note to you all that we (Intel OTC) are rewriting the SSO daemon and authentication plugins in C using glib and gdbus (so at least that hurdle is cleared).
The Linux Desktop way of security-less environment is not acceptable in other environments. For us there is a strict requirement for SMACK-based mandatory access control. So you can define which application(s) can access which credentials and in which ways.
We have reviewed the GOA project, but find it quite hard to add a full fledged ACL system there and fairly unlikely that it would get accepted upstream.
Anyway, the work in progress is here:
http://code.google.com/p/accounts-sso/source/list?repo=gsignond
(also the authentication plugins will be ported to glib, this is already done for sasl, and work has started on oauth)
Of course we’re open to discussions and clearing up of any misunderstandings and such.
Alexander Kanavin
15 March, 2013 at 21:02
“The Linux Desktop way of security-less environment is not acceptable in other environments. For us there is a strict requirement for SMACK-based mandatory access control. So you can define which application(s) can access which credentials and in which ways.”
That sounds like you are talking about application sandboxing. I am happy that you are interested in that area because it is something that we have recently started working on.
“We have reviewed the GOA project, but find it quite hard to add a full fledged ACL system there and fairly unlikely that it would get accepted upstream”
GNOME is working on a better application story, and sandboxing is one aspect of it. Here is one random URL on that topic: https://live.gnome.org/GnomeOS/Design/Whiteboards/Sandboxing
The G in GOA stands for GNOME, and I am curious what made you reach the above conclusion.
Debarshi Ray
18 March, 2013 at 16:39
accounts-sso has, as you wrote yourself, a plugin architecture which is why it can also be invoked for services running on the client, i.e. User A has these login credentials for Facebook, that encryption key for his /home, and those access permissions for apps running under his name.
Markus S.
16 May, 2013 at 03:18
Whatever technical aspects there might be: but it cannot be that with some every day simple update of the environment (ubuntugnome 14.04, which supposed to be a LTS), that all of the sudden GOA does not work anymore!
Time to move on and away from Gnome, too many restritions and limitations for some blabla-security reasons and what not.
Gnome developers just fix things for worse.
So if you guys think that it should become a valid alternative to M$, then your guess is downright wrong.
Lukas Wymann
1 August, 2014 at 07:31
[…] Ray, the GOA maintainer has started a public dialog about the GOA/UOA split on his blog. Check it […]
Ubuntu Online Accounts and the Ubuntu GNOME Remix | Just Jeremy
31 March, 2017 at 19:19