Both the primordial fediverse of ActivityPub as well as the federated Matrix have been mulling over various private-key approaches to the ideal of decentralized or nomadic identity, but I think we’ve been trying to solve too many deep-rooted problems in one go. This has kept us in a holding pattern for many years:
- Nomadic identity for the fediverse?
- Decentralised user accounts · Issue #246 · matrix-org/matrix-spec · GitHub
Meanwhile there’s a major convergence of OAuth/OIDC support across apub applications, Matrix is going all-in on it as its root default, and other social web protocols are tagging along as well.
- Mastodon: OAuth - Mastodon documentation
- Misskey: feat(backend): support OAuth 2.0 authorization by saschanaz · Pull Request #11053 · misskey-dev/misskey · GitHub
- Lemmy: OIDC single sign on · Issue #2930 · LemmyNet/lemmy · GitHub (rough consensus for OAuth was reached here)
- Pleroma: Authentication & Authorization - Pleroma Documentation
- Pixelfed: pixelfed: "We are working on OIDC support, and exploring Ind…" - Mastodon
- GoToSocial: OpenID Connect (OIDC) - GoToSocial Documentation
- Kitsune: OIDC (OpenID Connect) | Kitsune Documentation
- Matrix.org - Better authentication, session management and permissions in Matrix
- GitHub - matrix-org/matrix-authentication-service: OAuth2.0 + OpenID Provider for Matrix Homeservers
2023 Protocol Roadmap | AT Protocol
“Auth refactor: We want to improve both third-party auth flows (eg, OAuth2), and to support verifiable inter-service requests (eg, with UCANs). These involve both authentication (“who is this”) and authorization (“what is allowed”). This work will hopefully be a matter of integrating and adapting existing standards.”
I’ve been thinking intently about identity since the start of this year:
This line of thinking brought me to a framing that helps me categorize different web applications for my own purposes:
- Stream = Declarative, linear flow.
- Bonfire = Discursive, omnidirectional flow.
- Garden = Contemplative, bottom-up flow.
- Identity = Conduit of flows.
Your identity (ID) both inhabits and holds the places and behaviors which the Bonfire, Stream and Garden symbolize, simultaneously experiencing and expressing itself through those outlets.
These metaphorical constructs exist in the web as concrete protocols:
There are no strict boundaries in the Stream/Garden/Bonfire trio. A blog for instance can behave like a bonfire when it is more discursive through its comment sections, it can be consumed in stream-form via an RSS reader, and it takes the shape of a garden when it’s deeply interlinked and less concerned with chronology.
Likewise, Reddit’s individual threads are bonfires, its frontpage feed is a stream and its ‘best of last week/month/year’ is an organically structured garden.
There’s no need to agree on the exactness of these analogies. What I do hope we can agree on is that identity ought to be distinct from any specific authorship protocol.
Like the separation of church and state, it seems prudent to keep the management of our digital identities separate from our social network servers.
My default ‘fedi ID’ is currently hosted on
writing.exchange/@erlend - a Mastodon instance. This is already a big improvement from letting Twitter (or Google, or GitHub) be the chief custodian of my digital identity, since they won’t even let me move elsewhere if I’d like to do that. Mastodon makes that possible, thus giving me some genuine ownership over my contact list.
But I’m still beholden to an external server admin. Should
writing.exchange go down, that’s my fedi ID gone, along with all my followers (contact list). This has already happened to several fediverse instances being run by hobbyists who for whatever reason (lost interest; finances; health; technical issues) stopped running their server, in some cases with no warning whatsoever.
Users on a fediverse server are also disempowered in more subtle ways:
If an instance admin defederates from another instance in the fediverse, users won’t be notified of any followers they had from that instance; they’re just silently lost
(Apparently Mastodon has plans for this, but I don’t think instances should be fully trusted with this responsibility anyhow.)
A user can be banned, their account made inaccessible, unable to take their data elsewhere. Regardless of legitimate reasons for banning users, invalidating their default online persona is a kind of digital death sentence without opportunity for appeal. Very few offenses actually merit that kind of punishment.
Bluesky solves this in a web3 kind of way as a self-authenticating social protocol, based on a combination of DNS names and Decentralized Identifiers. However, some number of unknown unknowns remain in this space, and for now their solution depends on a centralized authority to function.
However, I do think some limited degree of centralized authority is necessary as a first step out of our current identity entanglement. The internet runs on all sorts of centralized technologies - e.g. Let’s Encrypt - and we go along with it because their innate openness grants us credible exit. The loss of Let’s Encrypt isn’t an existential thread to my online persona, but the loss of of my Google/GitHub/Mastodon account very much is.
The shortest path to a baseline of identity autonomy as far as my fedi ID is concerned would be if Mastodon allowed me to log in with my own OIDC account, instead of insisting on making one for me.
I can imagine three different degrees of OIDC autonomy:
- Completely self-hosted OIDC provider.
- 3rd party OIDC provider service, entrusted to do auth on behalf of my own domain.
- 3rd party OIDC provider service that provides a (sub-)domain for me.
Even the last option is an improvement over the status quo, because even though I’m still entrusting my identity management entirely to a 3rd party, at least my identity isn’t tightly bundled together with my social networking persona. And that 3rd party would generally be more trustworthy/reliable than your average ActivityPub instance if some institutional actors similar to Let’s Encrypt have stepped up as providers, like Mozilla, Linux Foundation etc.
So what I want is for Mastodon to let me sign up on its server via my personal domain name, the same way currently I log into Mastodon/ActivityPub clients via my personal (but not autonomous) Mastodon domain.
I.e. when signing up for an account on an instance like
mastodon.social, I should get to sign up with
erlend.sh via web sign-in.
My inability to follow the exact technicalities of authentication specifications is a limiting factor here, so I will need some help correcting or expanding upon what comes next.
I know what I want is something IndieAuth-like, which apparently Mastodon is close to supporting already. But it seems more accurate to refer to the functionality I need as plain web sign-in, because IndieAuth is apparently not OIDC compatible.
But that general method of signing in with ones personal domain is essential for self-hosted/indie OIDC to work as a form of SSO in spaces that are outside of your own control, e.g. a Mastodon instance, because we can’t rely on prefilled provider options such as Google, GitHub & Facebook.
Web sign-in presents a middle road between the broken status quo and the ideal state we need to get to. It doesn’t solve the subtle lock-in effects of a traditional fediverse instance on its own, but it realizes the essential first step of making netizens’ online identity independent from their impermanent choice of fediverse instance.
As such, domain-based accounts, especially when self-hosted, serve the function of a minimum-viable ‘nomadic identity’.
- Own your ID
- Own your content
- Own your contacts
Another way to put this is that I wanna make the equivalent for the fediverse of what my former boss Jeff Atwood envisioned for Discourse as a “gravatar on steroids”.
Whether Mastodon will be the pioneer of OIDC-powered web sign-in remains to be seen.
This Kitsune issue served as a seeding ground for the ideas I’m conveying with some degree of greater clarity here. Kitsune is a particularly exciting candidate for this exploration because it aspires to support multiple domains as well as domains as usernames, which aligns perfectly with domains as root authorities of identity.
It’s also made in Rust, further aligning it particularly well with Rauthy which, to my knowledge, is the most mature OIDC server/provider around that is optimized for self-hosting. I’ve previously written about how Rauthy could essentially be used as a compatibility layer between ActivityPub and Solid, but Solid is in no way a prerequisite for any of this ‘autonomous fedi-ID’ MVP to work. The storage layer backups of post content & contacts could just as well be built directly on top of Rauthy, or an experimental protocol like Solid-lite.
Proving this out will require:
- An implementation of web sign-in/up in the likes of Mastodon or Kitsune.
- Support for web sign-in in Rauthy.
- A hosted instance of Rauthy, configured for ActivityPub SSO.
Personally I’m also very interested in the fully self-hosted use case of Rauthy, which could be operated through a Tauri desktop app and bundled together with a basic site generator:
This topic serves as an open-ended call to action for anyone who might be interested in pursuing this together with me and a bunch of other folks such as the maintainers of the Rust projects mentioned herein.