@how Why even hide their name, by the way?
@nipos In case you didn't notice, @defunkt sold out to M$. So no, it won't stick as an acceptable solution. Already hundreds of projects moved away from Github, and I'm sure more will.
As far as free software is concerned, Github is bound to become a leaf in the system, not a main zone -- was it ever? I remember heated discussions with @defunkt regarding, e.g., chooseyourlicense.com and his position on the GPL.
Now, who wants a PRISM company to track their logins?
@nipos You're saying that M$ does not suck as much as G, F or T. I can't understand why frankly. They're in the same boat.
I guess Twitter is the lesser evil although since I use Mastodon I have no use for it.
Github will certainly stay, like G and F, but I won't be there anymore -- never have used M$, never will. If I want to contribute to some project hosted there, I can use Git without Github. Or they can do without me, yes?
@how ça me rappelle un wifi de bibliothèque.
@Feufochmar There's no reason to support only some OAuth providers, as there's no reason to grant all access to all OAuth providers on your data. Yet, the current implementations of OAuth only bring an all-or-nothing and you-know-me solutions.
Proper implementation would:
- authenticate with ANY provider
- grant only what the site believes is OK -- and that implies eventual restrictions on untrusted OAuth providers.
@how The problem with OAuth is that you can't get any user info (like the display name or user id) with the OAuth end-point API. The OAuth only tell you if the authentication succeeded or failed.
You have to make a call against a non-normalized API to get the user info from a OAuth provider. So you can't enable a provider without some associated code to support it. Furthermore, the authorisations you can ask to a provider are specific to that provider (ex: Mastodon has read/write/follow).