you don't need that to be federated you need single sign on that works
-
@kopper this would be very cool if someone who's not a massive corp had something to do this
@hipsterelectron tbf you could use your mastodon instance as an "mastodon flavored" oauth provider. the atproto way of doing dynamic client registration is on teh way of being standardized (www.ietf.org/archive/id/draft-parecki-oauth-client-id-metadata-document-02.html) which should, in theory, allow for it to be more generic than "mastodon flavored" or "atproto flavored" (and token inspection can be used as a generic way to acquire profile details like avatars and names). openid connect also is/was a thing but it's Too Enterprise on top of oauth which is also Too Enterprise itself -
@hipsterelectron tbf you could use your mastodon instance as an "mastodon flavored" oauth provider. the atproto way of doing dynamic client registration is on teh way of being standardized (www.ietf.org/archive/id/draft-parecki-oauth-client-id-metadata-document-02.html) which should, in theory, allow for it to be more generic than "mastodon flavored" or "atproto flavored" (and token inspection can be used as a generic way to acquire profile details like avatars and names). openid connect also is/was a thing but it's Too Enterprise on top of oauth which is also Too Enterprise itself@hipsterelectron we have the decentralized single sign on technology but people would rather make things federated because they like buzzwords instead of doing something people actually want to use
-
V volpeon@icy.wyvern.rip shared this topic