It's sad to see that #Gnome accounts mainly features non-free services.
For whatever reason the number 1 entry is Google. Then, yay, Nextcloud as a free software integration, followed by Facebook, Microsoft, Flickr and Foursquare.
The last two are usually hidden, those are free protocol-based integrations like SMTP+POP3/IMAP and Kerberos.
I wonder if we can't do better than pushing those big non-free services using our wonderful free desktop platform.
@gnome any thoughts?
@rain FSDG? (Sorry, I'm sometimes bad with acronyms)
@sheogorath Sponsors matter, I guess
To be honest, I don't think it's RedHat's fault. People add what they think is needed and useful. RedHat gives people the room to contribute those things.
It's on us to contribute more choices, because at least since the move to GitLab I don't see any rejected MR for new providers.
It's not about blame, but about working on it in a constructive way.
@flo It is, but they updated it within the past two months, so this will be updated in the next Gnome release.
The services are not really sorted by anything other than the internal name. The list is also dynamically generated from the available services. The code that accesses those platforms is all free software. In any case, those services can be disabled by distributions, given that distributions decide what kind of GNOME their users get.
@ebassi 👍🏻 I will do so! Is there any reason or interest to go for something that is more config file based? I mean we see kind of a patter here, there is some oauth2 endpoint, webdav, caldav, carddav, maybe smtp and imap, …
Wouldn't it make sense to get services out of source code towards a config file or similar? (If yes, I guess the reason it didn't happen yet is that it's work that has to be done)
@sheogorath the architecture is slightly more complicated than a list of end points: https://wiki.gnome.org/Projects/GnomeOnlineAccounts — there's a lot of code to handle differences in handling authentication (not just OAuth2) and capabilities, and exposing them to the core applications and system components.
@ebassi Makes sense, just read the the design document.
What's the general way that is taken to introduce new providers? Let's say I would like to add a email provider and it would be added on a GOA level, would this automatically picked up by applications that integrate with GOA or would they also need any change?
(Currently try to understand how abstract GOA is or if it's more like glue to get things work together easily)
@sheogorath The only way to add a new provider is to add it to GOA, in tree; if it exposes the same capabilities of the other services, then apps don't need to change at all, but if it adds new capabilities then apps will need to be updated to take advantage of them. GOA is mostly a single-sign-on system; after you added a new provider, you'll need to have actual API to access the services.
@ebassi Thank you very much for all the insight!
Let's see if I can fiddle around with it an find a way to improve it 🙂