Notes from a call on goa / todoist integration

Date: July 14

Topic: Do we want to put 'non-core' accounts like todoist into goa ? If so, how does this look ?

Notes (from memory): goa started out as a convenience to save users the trouble of entering their credentials in many 'core apps' that want to access the same accounts, e.g. the google account which is used for mail, files, printing and many other services in evolution, nautilus, gvfs, the print service, etc. All the consumers of goa accounts share a single registration with the service provider, typically called 'GNOME'. We don't really want this single registration to be used outside of core applications, since we might loose access altogether if a token is revoked because a 3rd party app misbehaves. So goa is somewhat tied to the concept of 'core apps'.

But there is no enforcement of this restriction. Any app can just use goa, and the documentation does not exactly make it clear that they shouldn't. And we don't provide any support infrastructure for 3rd party apps to 'do their own' account setup.

We discussed widening the scope of goa to manage per-application registrations, and allowing users to remove access for individual applications. But it seemed unclear that we can avoid multiple logins this way. It also wasn't clear if we can remove access without throwing up another webview for the user to authorize this.

We spent some time trying to separate the concerns of UX (multiple logins) and DX (goa library calls vs roll your own oauth).

Having applications do their own authentication fits with the general theme of applications being separate and standalone.

A downside of moving authentication to applications is that we may have to link them all with webkit, unless we can do the login part by shelling out to a browser.

Action items:

• write a comparison of the two approaches: goa with a widened scope vs provide a library for in-app authentication (allan, matthias)
• outline UX for a the account setup flow with a widened goa scope (georges)
• investigate splitting out an oauth support library from goa (rishi)
• prototype a 3rd-party standalone approach that will work in a sandbox, using OpenURI portal instead of webview

1. Comparison

Pro goa with a widened scope:

• A misbehaving app won't get the GNOME token revoked by the service
• Users have a single place to go and see and modify all users of their accounts
• We may be able to safely revoke access for an application
• Developers get an api that hides most of the details of interacting with the registration side of a service

Con goa with a widened scope:

• New services need to be added to goa, even if we don't have any core applications using them
• We may not be able to avoid logging in again for each new application token
• We may not be able to avoid a webview for revoking accesss
• The control-center UI will get more complicated (a nested list: accounts, with registered applications for each account

Pro in-app handling:

• Applications are standalone
• It will work on other platforms
• We can provide a more natural list of accounts inside the app

Con in-app handling:

• Currently no convenient library support
• Need to either link against webkit or shell out to a browser, with suboptimal UX
• Only way to safely remove access from the local app is to uninstall it, or go to the service website outside the app

2. Prototypes