Nomadic identity for the fediverse?

hey all, was wondering, is anyone still actively working on #nomadicidentity for the fediverse?

My interest in nomadic identity is somewhat inspired by scuttlebutt: to allow for migrating an account between servers, without needing the consent of the server you are migrating away from.

To start the conversation, and give a bit more detail on how I imagine this could be implemented:

I imagine you have a secret key for your account which is stored on your laptop (or bitwarden), not the server. Then when you want to migrate your account to another instance, you can use this secret key to re-create your account on the new server. The new server then makes (cryptographically authenticated) requests to the servers of all the people that were following you, telling them to follow your new account on the new server.

Basically server migration as I think it works now, but not requiring the consent of the server you were migrating away from.

I saw a thread related to this too, about what a .mbox file would like for the fediverse:

Ideally nomadic identity would bring one of my favorite parts of scuttlebutt, to the fediverse. I think if implemented well, without making anything more confusing. It would make the networks users build more resilient to possible destruction (intentionally or by negligence, from their server admins… which is something that can happen on the fediverse).

I’m not super versed in all the details of activity pub, but thought I would share, and would be very curious to hear anyone’s thoughts or related projects.

ps. I also posted about this on my mastodon account, but I thought this was probably a better place to ask.


also inspired by this short post: ActivityPub will include nomadic identity – More inspiration

Nomadic identity is supported by one project family and by nobody else. It still works “acceptably” across the fediverse but may require manually approving your clones from each of your connections on the ActivityPub side, and this doesn’t happen automatically as it does from sites using the Zot or Nomad protocols. We do supply the information necessary to connect to and/or link these clones automatically over ActivityPub and this is based on Mastodon’s existing account migration primitives. At this point in time there has been zero interest from other projects in supporting this mechanism or even the general concept.

There have been some alternate implementation proposals based on DID+blockchain, and/or using Solid, and/or serving your identity and content over torrents. Solid doesn’t really fit the brief as you only have one store but can share it with multiple fediverse servers. So if your store goes down you still lose everything. The other proposals might be plausible for some (but not all) use cases. They currently suffer from a general lack of developer interest and at this point the Zot and Nomad projects still provide the only known examples of working code.


Thanks for the info @macgirvin. I will have to look more deeply into Zot and Nomad at some point.

Also curious about DID+blockchain.

To me a private key that lives on your computer, which you can re-create your account from, seems somehow elegantly simple and resilient, and the other solutions sound overly-complex, but still curious to learn more.

DID+VC is definitely the future of web3. As for blockchains, this is the most promising project I am currently aware of.

I am wondering if it can be used to bridge the Fediverse with the blockchain ecosystem? TPS benchmarks? · Issue #1 · OriginTrail/dkg-client · GitHub

1 Like

In solid your identity is your so-called “WebID”

What that is, basically a user url

You have a profile page, much like mastodon, and you have different items in that profile page e.g. the person, the key, you can add as many things as you want

Each item is delineated with a # charterer, a bit like an anchor, it’s also called an ‘indexical’

That also differentiates the person from the document. So a document may have an etag, a created time etc. but the person would have different properties. Typically solid uses “#me” as a relative link to this (relative to the profile document). Mastodon doesnt do this (yet) but it would be 1 line in the json, namely “@id”: “#me” – that would converge fediverse identity together with solid identity, for those that think that would be a good idea

However this ties the identity to the http page it is on. In the case of relative data (e.g. “#me”) is it slightly nomadic in that if you move the data, it’ll function on the new host. But the previous inbound links would break without a redirect. Many people have experimented with redirect services with solid, all have failed.

The most usable hack so far found is to use DNS with a CNAME, much like how people use email with their own domain names. Might not be too hard to write a service for this. I know that must dyndns services are just a curl GET with a secret

I’ve not touched on ‘nomadic’ identity, which is domain independent. You can have one of these. With the so-called content addressable identifiers. The ni: scheme (naming things with hashes) is one, the did: another, there’s quite a few. What you do is hash something and then use that to identify someone. It will be domain independent. But the challenge then is to look up the data from the identifier. It’s hard to build a network effect around that, and http already has a network effect

There’s a couple of compromise solutions I can think of. First one is to derference your identifier in /.well-known/ni/hash/identifer which is actually domain independent and can go from domain to domain. Any s/w knowing this well-known location can look up data, your followers etc.

Another is to have a hybrid solution where you have both a profile url and you put another content addressable uri in that. We’re in early stages of that, but it might be useful.

The problem of changing inbound links is something that no one has solved to date. That’s basically because you own own half a link, getting the other party to change anything, especially when they are busy is a long process.

I’d recommend working on profile and adding some kind of domain independent information inside profiles. Thinks like key data are already making their way into systems, the more the better. Incrementally we can try and experiment with nomadic id, while keeping the existing social graph …

1 Like

Im actually working on a system like this. Currently all your data lives in git, and can be recreated from it

The flow is:

Private key can derive a public key
Public key is turned into an identifier
The identifier recreates your profile, or your data, or your application

There’s a little bit of glue needed so that you can find a git mirror for the identifier. And also verify the history. It also should pull in new changes as they happen in real time

Obviously git is not ideal for mainstream users, so it’s experimental, and for devs right now. But hopefully in the medium term I could remove the git component and have something that’s installable from pubkey uri or an audited data trail etc.

Why not simply start with Gravatar?
I think that Gravatar would simplify the creation of a new user account on a different network . Just pust in your email address and Gravatar fetches your public profile data and profile image that can be used to prefill the user sign up form.

This would make the life so much easier for every first-time registration I guess. Of course developing a user migration standard would be the most ideal solution but it should not prevent us from adopting Gravatar.

Does Mastodon or any other platform support Gravatar (I am new to Mastadon) and not why not? It is such a simple JS API.

What do you think about Gravatar?

regarding DID, for alternatives to blockchain have a look at this method

I’ve started to do this in my project, where profiles can have verifiable links to blockchain addresses. These links are represented as attachments of Actor object, similarly to how Keybase identity proofs were done in Mastodon:

"attachment": [
    "name": "did:pkh:eip155:1:<address>",
    "type": "IdentityProof",
    "signatureAlgorithm": "<proof-type>",
    "signatureValue": "<proof-value>"

The digital signature proves that actor ID and DID belong to the same person.

To solve my specific problem I used did:pkh identifiers, but I think this approach could be used for all kinds of DIDs.

Gravatar is basically a tracker. Just for that reason I avoid it everywhere I can.

1 Like

For my own project I was also very enthusiastic for did.

We do not even need a blockchain cause many different did-methods were registered and some of them even make use of ActivityPub, e.g. The did:orb Method v0.2

The problem arised when Google and Apple raised “formal objections” against did and used their superpowers in the W3C. Then it became clear that did will not become a standard and I doubt anyone else in fedi will use it.
It is good to see people using it.
cc @steffen


a nice idea for the keys that you mention… why not use PGP for this? (lots of federated projects a.k.a. Matrix, are particularly good at requiring separate keys, rather than riding on the ones you have already.) thoughts?