Do you know where the latest version of did:keri specification can be found?
https://identity.foundation/keri/did_methods/ is a draft from 2021.
https://weboftrust.github.io/ietf-did-keri/draft-pfeairheller-did-keri.html is a draft from 2023.
I think it means living like a nomad. One day you’re on the site A, and the next day you’re on the site B. Same “you”, different sites (servers).
We can’t remove the “nomadic” qualifier because non-nomadic identity also exists in Fediverse.
1 Like
Ugh.. I see that at least they placed me on the wrong footing in thinking that their “WebOfTrust” org was the well-known one. But that is WebOfTrustInfo. 
That’s minus points, I’d say, and raises further question of who is behind this effort, and perhaps that is mostly only Samuel Smith.
https://weboftrust.github.io/keridoc/docs/intro/intro claims to " document everything related to KERI, ACDC and CESR and alike", and that then leads to https://github.com/WebOfTrust with last human activity in March this year.
That is not exciting for a shortlist in terms of likelihood for broad adoption, and I am sorry if my confusion around the double-use of WOT made you waste time checking things out. Maybe there is uptake elsewhere, as the KERI article series mentions it being a candidate for “Trust Spanning Protocol Task Force (TSPTF) under the Trust Over IP (ToIP) Foundation is currently developing the trust spanning protocol where KERI is used as one of its candidate protocols for Verifiable Identifiers (VIDs).”
First time I hear about this effort, but their Atlassian Confluence search (which has no sort functionality 
) at least shows KERI being discussed up to late 2024. Afraid things are as messy in the identity world as they were years ago.
2 Likes
I still find it vague. The conceptual architecture of AP only knows actors. Indeed you can say that there is only a single “me” identity. To access/operate actor A or B I may need to show some form of identity proof. The actors may then assume my identity, so they can do activities on my behalf. And actor A may need a way to express to actor B that “Hey, it’s me”, the “my” identity, to access/interact with B.
Isn’t this what identity standardization efforts are trying to model in various different ways and without a need to define “nomadic”? Does this come close to what nomadic identity means:
Nomadic identity is a secure way to transfer identity proofs of a person between actors, so that they can act on the person’s behalf.
?
One piece of context you may be missing is that in anthropology, nomads are not rootless wanderers. Rather, we travel a regular circuit, with annual variations, traditionally determined by the seasonal affordances of different bioregions.
In the context digital systems, one way to think about this is that I’m still me, regardless of whether I’m communicating as @strypey here, or @strypey@mastodon.nzoss.nz, or @strypey:matrix.iridescent.nz. My one identity is nomadic across all 3 addresses (and others). Similarly, a single fediverse identity can be nomadic across multiple servers. In both cases, I can travel between them according to the affordances I need at the time.
Addressing your protocol question, an AP Actor is a user agent not an identity. An identity is a representation of the person a user agent works on behalf of. You may be conceptually blending the two, as most AP software does, following Mastodon’s example.
If you haven’t used channel cloning on Hubzilla, or other Nomad-verse software, I highly recommend giving it a try. This will give you a more visceral sense of the UX described by “nomadic identity”.
2 Likes
Not confusing things, just formulating differently. And that’s the thing.. with auth/authz not part of the AP spec, all discussion around it is where the dev ecosystem has filled in the blanks over time, and people doing so in various ways with different designs and terminology, and free reign to make own choices and interpretations.
From that came forth the strong need for “nomadic identity”, which I don’t doubt is legit. With the concept apparently invented for the fediverse and not part of existing standardization efforts around identity (unless under different names?), it is fair to ask what exactly is “nomadic identity”. A precise, crisp and concise definition to align our common understanding is essential. Another example of the need for clear language is, I wouldn’t consider a Service or Application actor to be a “user agent”, unless by convention we agree to call it that. Without good definition, a good specification is not possible.
My original question was whether the need for “nomadic identity” stems from needs to overcome limitations that follow from constraints in the spec, or how the ecosystem has implemented those blanks the specs left open.
In the discussion above I see numerous different concepts and areas that might benefit from “nomadic identity”, yet I don’t see agreement on what it means. The aforementioned FEP-7952: Roadmap For Actor and Object Portability by @codenamedmitri and @bumblefudge make very good arguments for “Portability” which seem to benefit from “nomadic identity” (maybe they even describe a mechanism, without using the name?) and with a good Nomadic Identity FEP available, might point to that as a prerequisite for Portability, defer to it, and focus in the text purely on fleshing out these portability capabilities.
And beyond the scope of the fediverse, it is quite important to also be able to reach out timely to standardization efforts around Identity, and point out where their specs may be inadequate for lacking nomadic identity. If only to risk being side-lined if one of those efforts becomes the ubiquitous world-wide identity standard and the fediverse cannot comply to it because of past choices and tech debt that is now in the installed base.
1 Like
First time I hear about this effort, but their Atlassian Confluence search (which has no sort functionality
AFAIK, KERI is still working partly in ToIP (Trust-Spanning Protocol and DID:SCID) and partly outside of its IP strictures. There was a meetup in Geneva the day before the GDC Identity conference, but I was double-booked with the DIF event and didn’t attend. KERI is best thought of as a “hard fork” of DIDs and VCs, borrowing a lot of ideas but breaking low-level technological foundations and “starting anew”. There is another “hard-fork” around Blockchain Commons (Christopher Allen’s thinktank/community), which takes a less re-inventy approach to the DID/VC but similarly is not “backwards compatible” with it.
In the discussion above I see numerous different concepts and areas that might benefit from “nomadic identity”, yet I don’t see agreement on what it means.
To be totally frank, I also couldn’t find a definitive “normref” for what nomadic meant, having only a an intuitive sense from many documents I found linked off of posts here and in W3C minutes. I went with “portability” because it’s more of a neutral/literal concept-- can control of an account (and authentication of content) move between hosts and apex domains, period. I intuit (but can’t be entirely sure) that there are additional requirements around the continuity of that experience, or different assumptions about the host<>account relationship that constitute nomadic identity on top of mere portability (which says nothing about how an account or a host<>account relationship are experienced or expressed to others).
please tag me in anyone submits a FEP or RFC or anything else defining these systems in more detail, I’m curious!
2 Likes
In a narrow sense, “nomadic identity” is a specific feature implemented in Hubzilla and Streams. Initially, it had nothing to do with ActivityPub, because the work on ActivityPub started years after @macgirvin developed the feature.
The detailed history of it can be found here: https://joinfediverse.wiki/Nomadic_identity
In 2023, I published FEP-ef61 (Portable Objects), where an equivalent to nomadic identity was proposed for ActivityPub. Mike Macgirvin implemented this proposal in Streams, and it is often viewed as a continuation of his previous work at Hubzilla and Streams.
So, the concept of “nomadic identity” today is a bit broader than 5 years ago, but still closely related to Hubzilla and Streams projects.
The development of nomadic ActivityPub is tracked at https://codeberg.org/ap-next/ap-next/src/branch/main/nomadpub.md. The document includes the following definition:
Nomadic identity is a feature that was originally introduced in Zot protocol. It allows users to freely move accounts and content between servers.
FEP-ef61 is based on Decentralized Identifiers (DIDs) and Verifiable Credential Data Integrity standards, and was developed in collaboration with the respective working groups.
2 Likes
Thank you. That is very informative. And it makes me ponder the following..
- Aren’t we really speaking here about defining and satisfying the non-functional requirement of Portability of the ActivityPub protocol in a general sense?
- Is the abstraction “Nomadic identity” really needed, or does it result from other abstractions that were introduced before, such as the notion of “Instances” that we are tightly bound to, and that we take for granted now?
PS. As a definition from the Hubzilla docs I extracted the following:
Nomadic identity, as implemented on Hubzilla and (streams), relies on the availability of channels which serve as containers for the user’s identity and content. It deals with the handling of these channels between servers. One advantage of nomadic identity is that it is probably the best existing way of moving your identity from one server to another.
As a path into the future fedi and AP vNext doesn’t it equate to offering the following protocol capabilities to take into account (and not introducing the abstraction)?
- Self-sovereign identity
- Portable data
“Self-sovereign identity” and “portable data” are technical terms. “Nomadic identity” is how it is perceived by end users.
Yes, “nomadic” is related to “instances”, but instances is just what federation is.
Yes, and federation is also a technical concept, and it is design choices how you expose fedizens to it.
Update. Please allow me to muse some more.. I think that “nomadic identity” may be an avoidable abstraction and just another way of stating the need for Self-sovereign identity and Portable data. For the latter that equates to defining an overall Portability non-functional requirement for the AP protocol as a whole.
For identity it is more interesting. The conceptual architecture of AP gives us raw power and potential. Subsequent choices and introductions of abstractions may help or hurt that potential. What is Identity? It is not part of the conceptual architecture, neither as Users, Apps and Instances. I think that if you scrutinize what it really is, then it breaks apart into 2 pieces: It is part of the Security NFR’s (See this doc) to improve for the AP spec, and it is particular service designs that model it on the social web.
With that it lives up to the promise of the AP conceptual architecture: Offer a secure decentralized social networking environment that supports modeling of Identity solutions on top of it.
Do either of these encompass the ability to clone channels from one instance to another, so that posting to one posts to all, and people browsing channels can automatically pull from the a clone if the home instance is unavailable?
To me this is the killer feature of nomadic identity. For example, channel cloning allows me to self-host on an unreliable net connection, while clones of them on more robust services allow them to remain reliably available. Clones can also keep my channels alive if my home instance goes down and never returns.
1 Like
I don’t know. Best ask the group. I came to find clarity and my feedback is that Nomadic identity may benefit from more clarity on scope, definition, naming, and relation to other technologies as basis for a good FEP.
I think the concept of nomadic identity can not be replaced with “data portability” because there are portability mechanisms that are not “nomadic”. For example, migrations.
The Move activity is a portability mechanism, but it makes only one aspect of social profile portable. Similarly, downloading an archive of posts from a Mastodon server and importing it into a different server is a portability mechanism, but identity is not preserved, because these posts will be attributed to a different actor.
1 Like
@macgirvin just followed-up to a related fediverse discussion on the subject, with:
Nomadic identity is nothing more than a full backup of your social profile, friends, settings, and content that is always kept up-to-date on one or more alternate instances. So if anything goes wrong with your chosen instance; anything at all – you can carry on like nothing happened.
And people think “choosing an instance” makes the fediverse complicated. That’s nothing compared to what happens if you choose the wrong instance or the admin decides they don’t like you. Nobody talks about this, because it can be devastating.
We provide a way to extract yourself and all your content from this situation. If you’re on Mastodon, you have no such safety net. If something goes wrong, you can migrate your friends if you have warning; otherwise your existence in the fediverse and everything you ever posted is gone. Forever.
Poof.
This has happened before. in 2011 it happened to nearly a half-million people in the space of a week or two. Most of these went back to either Facebook or Twitter and left the fediverse forever.
As for the current conversation, what allows an identity to be nomadic is that it isn’t permanently attached-to or associated-with a particular
- username, or
- DNS name
these things can change at any time, but you’re still you - no matter what instance or software brand you are using right now; and our own software tends to reflect this.
“Nomadic identity isn’t just a good idea. It’s a bloody great idea.”
And I gave the following response:
Nomadic identity is nothing more than a full backup of your social profile, friends, settings, and content that is always kept up-to-date on one or more alternate instances.
Now this is a clear definition, thank you! Fully aware of the problem and any good solution is a great idea
Where I was confused was the “identity” in the name, considered identity and data to be separate concepts. Moving all your content is more like a “Mobile home” facility. A name fit for ‘end-users’ too.
Or ‘nomadic homes’ as the name. Or ‘roaming profiles’ perhaps.
Proposal to rename this protocol capability
This definition of nomadic identity makes me a proponent to brainstorm a better name for this protocol capability, to avoid any confusions around existing identity concepts in other open standards and people’s own mental models of what identity is, both for developers and end-users alike.
There was further follow-up with Mike to address possible renaming..
I did explain how this was connected to identity towards the end. You kind of need nomadic identity to have nomadic homes.
Confusion that arises with me is in how I conceptually perceive the notion of self-sovereign identity. Namely as your identity in some digital representation, that is decoupled from the data you own and where it resides. Where SSI allows one to have nomadic homes just as well.
Maybe that is not the case in how the standards are developed and ‘something extra’ i.e. nomadic identity is required.
Either that or it may be better named to avoid the confusion with other uses of “identity”.
And Mike’s reply:
I guess the circular reference wasn’t a good idea. Let’s re-phrase that. You need a “portable identity” to implement nomadic homes. A “portable identity” is one that has doesn’t reference a DNS server and/or account. Because these aren’t really an “identity”, but rather a “location”. Your portable identity is something that identifies you, not the machine and account you happen to be posting from.
Me: The location independence is what I also associated with my notion of SSI conceptually, and then there are a plethora of ways to technically achieve it. Witness all the competing standards.
Do you think “portable identity” covers the load better?
I wondered earlier if this particular mechanism of portable identity was needed to overcome design choices in the protocol that tied identity to domain names? Which we must now live with and work around to keep backwards compat.
“Portable identity” would be a very good name. The protocol then has a “Portability” non-functional requirement which breaks down into separate mechanisms for portable identity and portable data. Where one depends on the other.
2 Likes
“portable identity” is not well-defined concept, I prefer to call it cryptographic identity or key-based identity.
However, the name of the FEP is “Portable objects”. The combination of cryptographic identity and cryptographic integrity proofs makes objects portable.
2 Likes