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.
“The first truly fully decentralized identity system.”
Quote from Hitchhikers Guide to KERI. Part 2:
KERI in a Nutshell
Conceptually, the Key Event Receipt Infrastructure (KERI) protocol is a decentralized identity protocol designed to be an identity overlay for the Internet. Each word in KERI has the following meanings:
- Key refers to asymmetric key cryptography that is used to control persistent self-certifying identifiers, called Autonomic Identifiers (AIDs).
- Event refers to a series of Key Events in a hash-chain verifiable data structure called Key Event Logs (KELs) that record the key-state evolution of AIDs via the Pre-Rotation mechanism.
- Receipt refers to signed receipts of key events, called Key Event Receipts that provide non-repudiable proof while exchanging key events between AIDs.
- Infrastructure refers to the protocol for exchanging non-repudiable key event receipts, including the designation of Witnesses, Watchers, Jurors, and Judges.
I used to follow developments around Web of Trust closely, but the huge fragmentation and lack of outlook on broadly accepted/adopted open standards made me lose hope for such technology to emerge anytime soon, and I stopped following the field other than superficially. I only learned about KERI today (via HN discussing FOKS), and it is the first time I got the (first) impression that they..
The 3-part article series “Hitchhiker Guide to KERI” mentions the perceived complexity in the introduction:
Despite its potential, KERI often finds itself shrouded in misunderstanding, often being criticized for its perceived complexity. Thus, this blog aims to provide an introduction guide to KERI, demystifying its intricacies and advocating for its widespread adoption.
Two years on from the mention by @silverpill it might be worthwhile to give KERI another deeper look for applicability on the fediverse. One intriguing design goal, referring to the well-known XKCD-927 in the article is:
“Could there possibly be a unifying DID method that covers the use cases of all others?” This is precisely what KERI attempts to be.
What makes KERI special is also the fact that it is not just another DID method. The KERI protocol has a grander vision of being the identity overlay for the internet.
I’ve read the article, it clarified things a bit. The idea looks very similar to the one of did:webvh, where a verifiable event log is built from a self-certifying genesis event.
I think it can be used in fediverse, but unless KERI has some non-obvious advantages, I would prefer did:webvh because the spec is less jargon-heavy.
I guess here we have one of those decision points that may greatly influence the future of the fediverse. According to the bottom-up process any interested project initiatives can make the pragmatic choice that fits the needs of the participants at the time, with the risk getting stuck with that choice once there is an installed base. And protocol and tech debt when other initiatives add their own pragmatic variations or alternative technologies.
That is an argument to tackle the issue in top-down fashion and start at W3C SocialCG with a Digital Identity Taskforce or similar. CC @codenamedmitri @eprodrom
Maybe anno 2025 the ‘technology bet’ for the identity open standards most likely to gain broadest adoption can be made with confidence. It would require making a shortlist with options, elaborate pros and cons, and comparing them against a range of factors.
As a more general remark I would add that the words “nomadic identity” are not indicative of a feature of the fediverse, but rather represent a fix for the current implementation of the fediverse. The need for an identity to be ‘nomadic’ stems from the way that identities are tied to instances / domain names. The general case is making “identity” an intuitive concept on the fediverse i.e. “doing identity right”.
There is a shortlist in the “DID methods” section of FEP-ef61:
…did:web, did:dns, did:webvh (formerly did:tdw) and did:fedi.
But currently we only use did:key to avoid over-complicating things.
Nomadic identity is not a fix. These words accurately describe how portable identity works in a federated network.
Shouldn’t it also include KERI? It seems serious enough of an initiative to just scratch it off. Maybe more complex than others idk, but to that stand particular benefits as listed on their landing page.
What I mean to say is - and I did a search - that the term looks to be invented in context of the fediverse, to address the limitation that flows from the specs that actor identity is tied to domain names. From the perspective of that constraint “nomadic identity” indicates a fix. Only on the condition that identity as expressed on this particular (AP) network is nomadic, can one consider it to be adequately representing the concept of Identity.
I get the logic behind understanding “nomadic” in contrast with the “static” identity of most AP software, but it’s equally true to contrast either with the “floating” identity of pure P2P networks like Scuttlebutt or Nostr, and then define it as a “fix” to that. I agree with @silverpill here, “nomadic” is descriptive of a system where identities have a home base but can move their flag to another at will, or just broadcast from elsewhere while keeping the same home base.
Just saying that it is a weird concept with no real equivalence in real life, where a person has their identity no matter where they go, and regardless whether they are a nomad or homebound. That raises the question what nomadic identity conceptually really means. I know that modeling identity online is incredibly hard (hence no broadly adopted open standards yet). I observe that “nomadic identity” is an abstraction crafted to help make the fediverse tick. A means to say “everything that represents me now sits on this server”. Most likely “nomadic identity” on the fediverse is important to address. Is that identical to “identity on the fediverse” or should that be separately addressed? If it is identical then the word “nomadic” is superfluous. If it is not identical then maybe the subset of identity addressed by “nomadic identity” is indeed a fix to circumvent the actor domain name constraint, and we should be acknowledging that. Or the risk exists that later we bolt all kinds of things on top to make it represent general identity.
