In the recent issue triage by @eprodrom today, we concluded with an issue item to explore the idea of writing a FEP formally describing Mastodon’s usage of the
Move activity for follower migration, as a sort of “step 1” before standardizing any improvements in a “step 2”. However, there is a sort of “step 0” that I think should be addressed, and that is that the “root of identity” is not consistent or clear between different implementations. There are fundamentally 3 different roots:
id, which is expected to be an HTTPS URI. Essentially, this option leans into the strengths and weaknesses of the WWW.
- Some cryptographic keypair. There is the possibility of using
did:keyfor this, and FEP-c390 tries to bridge this back to the HTTPS
idvia the same mechanism as profile fields (currently being formalized in FEP-fb2a): an
attachmenton the actor.
- The username+domain pair. Mastodon uses this as canonical and authoritative identity throughout its codebase, and strictly expects that this pair will resolve via Webfinger acct: URIs.
The mismatch between different “roots of identity” leads to subtle weirdness when two systems of different roots interact with each other. For example:
- In id-rooted and webfinger-rooted systems, you can perform something known as “blind key rotation”, in which the associated public key is swapped out silently in order to provide deniability for any past activities. This obviously breaks in a key-rooted system.
- In an id-rooted system (where the id does not depend on username) or in a key-rooted system , the username can be changed at any time, which obviously breaks in a username-rooted system.
- In a username-rooted or key-rooted system, the HTTPS URI can be changed at any time, which obviously breaks id-rooted systems that depend on HTTPS URIs.
In such breakages, the “same” actor is now considered a different actor in only some systems, but not in others. What should be done about this? This has knock-on effects for the concept of “migration”:
- In an id-rooted system, the key or username can change without necessitating a migration. Migration is only necessary when the actor is “different”, i.e. has a different
id. (This can be ameliorated by checking for and respecting HTTP redirects.)
- In a key-rooted system, the id or username can change without necessitating a migration. Migration is only necessary when the actor is “different”, i.e. has a different key. (This can be sidestepped by maintaining a log of key rotations.)
- In a username-rooted system, the id or key can change without necessitating a migration. Migration is only necessary when the actor is “different”, i.e. has a different username or domain. (Caveat: Mastodon is not fully rooted in usernames, and partially uses id in some places, particularly for objects and activities.)
It seems like the most “canonical” thing to do would be to take the id-rooted path, but support DIDs. In the DID spec,
alsoKnownAs allows for bridging to other schemes or identifiers. You could have an
id of the form
did:key and an
alsoKnownAs containing its current HTTPS URI(s), but any move away from HTTPS would need to extend ActivityPub such that the HTTP GET/POST behavior has an alternative that works and can be relied upon consistently. You would basically need a DID method that can be transformed into an HTTPS endpoint. Also you would need to decide which DID methods are acceptable and should be supported.