did:ap:key itself doesn’t require a server. Signed ActivityPub objects must be stored somewhere, but now they can be stored on multiple servers, or even on a client, it doesn’t matter.
If you have further questions or suggestions, please use the FEP-ef61 discussion topic:
Cross-referencing fedi discussion on Nomadic Identity started by @jenniferplusplus and @deadsuperhero’s WeDistribute article on the topic:
ariadne’s proposal would be the end goal, but we still think we need to set aside “changing the server” (or, more specifically, “trying to convince admins”) for a bit, and focus on what clients (and end-users) can do about it. we should… give power to the ppl, y’know?
I’ve been wondering about the applicability of ATproto’s did:plc as a transitional building block for nomadic identity:
Turns out @arcanicanis has explored this possibility quite deeply already, with some fairly promising results:
…and one of the ATproto devs has now joined the discussion:
It’s kinda-sorta off-handed comments, as it was more a curious experiment of whether I could create and publish a did:plc, or if it was only an incomplete facade or something. The oddly interesting part is that it tries to coerce it to a DID document in JSON-LD format, but I don’t know if anything constructive could be done with that.
But effectively this could be done in a far, far simpler approach with did:key (or more specifically, did:ap:key) as we already have: just essentially have “keyservers for fedi”. People could stand up a keyserver where someone can publish their fediverse DID, and as long as the FEP-8b32 proof matches up, and values of the object correspond correctly, it would be accepted.
There’d be nothing new that’s have to be implemented, since it could use all the same primitives as already present with current nomadic identity efforts (JCS for canonicalization, Object Integrity Proofs for signature representation), instead of additionally dragging in DAG-CBOR and CIDs just to sign/update an identity.
It can be a stand-in solution to give more certainty to identity resolution, before there’s finally larger servers with nomadic identity support that have a broader picture of the network, to naturally serve as a resolver (to fill the gap when a receiving server doesn’t know the authority for an did:ap:key-based identifier).
I probably could even write a usable concept in a night or two.
Perhaps it should be named did:ap:web then (based on did:web), not a did:ap:key?
Not really, as a did:web identifier (or did:ap:web counterpart) could just naturally be resolved on it’s own. I’m saying of having well-known keyservers that key-based identities can be published to, in order to assist resolution of did:ap:key identities in the beginning, such as if implementations choose to avoid the overhead of the aliases being codified into the DID (or if the mentioned servers are gone). At least, it can be “training wheels” to let people start poking with portable objects before they have a full implementation, maybe.
As for did:ap:web, it might not be worth distinguishing a separate ActivityPub-specific DID counterpart to did:web, if the server provides the JSON-LD representation of the actor when application/did+ld+json is requested. Thankfully an ActivityPub actor can also be a valid DID document at the same time, so did:ap:web might not even be needed.
Also with did:ap:key, I don’t know if it’d be worth prototyping another method, such as something that allows key rotation (sign and hash-based with JCS instead of DAG-CBOR); or just roll that into did:ap:key instead, as it’s a separate [experimental] identifier that isn’t necessarily “set in stone” yet.
Nonetheless, I think most of the work now should be just prototyping actual implementations of FEP-ef61, and experimenting with variations from it, to see what the most appropriate path to take is (aliases in DID or not, envelope or not, etc). Some of the discussion is just dragging out hypotheticals of ‘how it could be done’ and ‘how it can work’, when these things should be decided by field testing some experiments. I guess I’ll just jump ahead and try to get a complete working implementation first, then start arguing for a particular path.
Relevant development:
Unbundle the services and concerns of a typical instance
- Sign everything: Recognize client-side cryptographic signatures as proof of authorship (by implementing FEP-8b32: Object Integrity Proofs), in addition to the current practice of relying solely on the instance URL.
- B.Y.O. Actor ID: Using Object Integrity proofs enables Identity Hosting to be separated from the other instance concerns. Actor profiles can now be hosted separately from the instance (including as a static JSON object on a personal website), which in turn enables service providers to offer their users a “BYO (Bring Your Own) domain name” feature.
- Separate Inbox/Outbox: (Optional) The previous steps enable message transfer and Inbox/Outbox hosting to be outsourced to separate service providers (the Actor profile links to these in the usual manner).
- Separate Object and Collection hosting: (Optional) Similarly, AP Objects and Collections can now be stored on domains separate from the Actor’s domain (since authorship and controller-ship can be proven cryptographically, in a domain-independent way). This enables the user to migrate storage service providers without having to change their Actor ID.
@erlend_sh What about it? All of that was previously described in FEP-ef61
I had an easier time understanding the intended outcomes of FEP-7952.
Are you saying FEP-7952 and FEP-ef61 are effectively trying to do the same thing? If so, y’all gotta talk to each other.
Well, yes, very similar goals and hopefully not mutually-exclusive. My thinking is that FEP-ef61 has a hard adoption curve because implementations that DON’T implement it have a hard time resolving those URLs and getting those Actors/objects. If all the servers that don’t implement FEP-ef61 resolution at least implement FEP-7952 resolution (which in many cases requires no changes breaking or otherwise, more like if they confirm they haven’t accidentally hardcoded an interpretation of the Actor object narrower than the AP spec allows), then they can at least follow and interact normally with an actor on a FEP-ef61 implementation, if EITHER that ef61 implementation also implements 7952 routes/resolution for its actors OR the individual actor does a “copiedTo” mirror to a 7952 microserver.
There’s also a tiny FEP coming soon that clarifies some of this fallback/resolution behavior in a way that is hopefully non-breaking for anyone but could help interop across these Actor styles going forward by establishing a simple, testable baseline for resolution mechanisms acrosss migrations and divergent actor<>service relationships.
Hopefully, in the long run, 7952 (and this more testable/CI-friendly “Actor Resolution” FEP) is a half-measure that enables more experimentation in a ef61 direction, as well as in a bluesky/nostr/zot interop direction, for people interested in that, and in an interoperable moderation direction, for people interested in that.
Yes, the primary goal is the same - decoupling identity from a server and achieving data portability (FEP-ef61 has additional goals described in the Motivation section). The proposed solution is also similar, although I haven’t analyzed FEP-7952 in detail. I think FEP-ef61 combined with did:web identity would have the same properties as their solution.
Everyone involved in the creation of this new proposal was well aware of the existence of FEP-ef61 ¯\_(ツ)_/¯
This portable actor can be discovered from Mastodon: @nomad@mitra.social.
Interoperability with vanilla ActivityPub implementations is described in Compatibility section.