Online Accounts plug

Registered by Sergey "Shnatsel" Davidoff on 2011-12-04

- Google Services (Gmail, Gtalk, Google Calendar), Instant Messaging Services (AIM, IRC, Jabber), Social Services (facebook, twitter, flickr), Services without authentication (imagebin, etc)
- Store username+password in GNOME Keyring, possibly provide abstraction layer (API) for OAuth, store user info for auth-less services like Imagebin without encryption
- Provide a link to account creation page for each service which supports it
- Provide a link to the tems of service and/or privacy policy for authless services and an 'I accept' checkbox
- Pluggable list of services (where plugging means adding/removing some files and possibly running some commands, so it can be done from a .deb package)
- Show a list of apps that currently have access to each account, and ability to disallow access
- [long-term] Bridge GNOME Online Accounts API into ours, if GOA ever gains momentum

# Mockups:

# Upstream design:

# Upstream implementation:

Blueprint information

Corentin Noël
Series goal:
Milestone target:
milestone icon freya-beta2
Started by
Corentin Noël on 2013-10-30
Completed by
Corentin Noël on 2014-12-04



Random Idea: What if we used packagekit to get a list of services available in the repos? That way when you went to add a new account you'd always have an up-to-date list of all the services available? --DanRabbit

A good implementation of the API:
It supports Account storing and SSO and is very modular! --tintou

**IMVHO** making an elementary specific OA API is a bad decision. Not only is it more work, but it will also fragment the linux desktop OA scene even more. I know one thing: the Geary devs will not be enthusiastic about supporting an elementary specific OA API. (See here: I suggest Ubuntu Online Accounts, since it is used by Ubuntu, it is used by Mer/Nemo/Sailfish, and will most likely be used by KDE. I don't think that an elementary UOA plug will run into any hiccups related to not being able to deliver the UX we want. ~CameronNemo

"Btw, don’t let the Ubuntu in UOA fool you too much: AccountsSSO started in and first appeared in MeeGo (e.g. the N9 phones) and was adopted by Ubuntu. It’s not Ubuntu specific by any means, and I think it is great they adopted rather than created another system." --aseigo, relayed by CameronNemo

Yes, we're aware of that. The problem is UOA has Qt UI and depends on deprecated libraries while GOA has nice API but it's all hardcoded, which is not acceptable. - IMO this is a terrible argumentation and I don't want to have ANYTHING in common with those people. They're deluded, if not insane.
So the way I see it, we should make eOA API-compatible with UOA and possibly with GOA as well. But this whole OAuth thing is a can of worms from the legal perspective - many services require things that simply cannot be done, especially in open-source software (Such as keeping application keys secret. That's impossible - they can always be extracted from memory, no matter how hard you try and obscure them).

So the package name suggest it's named Pantheon Online Accounts (so welcome to POA !) --tintou

Implementation is good enough for beta1. Bumping to beta2 --DanRabbit


Work Items

Dependency tree

* Blueprints in grey have been implemented.

This blueprint contains Public information 
Everyone can see this information.