Embed Notice

@alex @ShariVegas First we need to decouple user identity from the server. This means each user has at least two keys, one of which is stored on the server and used for HTTP signatures, and another one is stored on the client. For example, Mitra supports Ethereum keys managed by MetaMask browser extension, and Minisign keys (it's a command-line signing tool). But client-side key can be also stored on the server in a password-encrypted backup. The exact implementation doesn't matter.

Next we implement identity proofs (FEP-c390). With identity proof you can link user-controlled identity (client-side key, represented by DID) to server-controlled identity (actor ID). Recipients who understand identity proofs see actor ID and DID as different identities of the same person.

Now users can start to sign activities with their own keys (FEP-8b32). Signed activity is transport-agnostic. It can be delivered by relays or by any other means. Recipients who understand identity proofs may ignore actor property (it could be a relayer actor) and treat signer's identity as primary.

This is still backwards-compatible with existing Fediverse servers.

Once a sufficient number of servers/platforms support FEP-c390 and FEP-8b32, we can abandon DNS-based actors and do something similar to what chatternet is doing.