Nomadic identity for the fediverse?

[notplants]

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:
https://terse.telent.net/note/7fec3921

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.

[notplants]

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

[macgirvin]

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.

[notplants]

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.

[mikestaub]

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

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

[melvincarvalho]

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 …

[melvincarvalho]

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.

[Chilly-Code]

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?

[Sebastian]

regarding DID, for alternatives to blockchain have a look at this method
https://trustbloc.github.io/did-method-orb/

[silverpill]

@melvincarvalho

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 …

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.

[aschrijver]

@Chilly-Code

What do you think about Gravatar?

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

[Sebastian]

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

[cambridgeport90]

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?

[silverpill]

Using PGP is a good idea indeed.

I’d like to support identity proofs based on GPG keys in addition to wallet-based proofs I mentioned earlier in this thread.

My general plan is to use Move() activity for account migrations, but let people sign this activity with their own key. If I understand correctly, implementation of Move() in Mastodon requires a cooperating server. If your old server is offline or if admin banned you, there’s no way to move your followers. But if user-signed activities are allowed, you can simply register new account on another server, import your follower list and send them a command to un-follow your old account and follow your new account.

To make user-signed activities possible on Fediverse, I’m working on two protocol extensions:

• Embedded signatures. Mastodon can create them, but their implementation is outdated and not portable. There should be a clean and simple way to sign JSON object, otherwise embedded signatures will never be adopted in Fediverse. I’ve implemented JSON signing according to Verifiable Credential Data Integrity 1.0 standard (which replaces old LD signatures spec), using JCS algorithm, which is much simpler than RDF canonicalization. It has implementations in several languages and for signing simple JSON objects people can even use ordinary JSON serialization libraries that can produce compact JSON with sorted keys because the output will be the same.
• Identity proofs. This is a verifiable link between domain-based account and user’s public key identity. When server receives activity signed by user-owned key, it can verify its authenticity just like it does when activity is signed by server-owned key.

That doesn’t solve the problem of data ownership, but I think my solution is compatible with any data migration mechanism: manual export/import, backing up on IPFS, Solid, or mirroring to multiple servers.

In the future, I want to create FEPs for both of these extensions. Feedback is welcome!

[cambridgeport90]

That sounds amazing… I will be keeping an eye on this.

[silverpill]

@silverpill

I’d like to support identity proofs based on GPG keys in addition to wallet-based proofs

I decided to use Minisign instead of PGP. Its signature format is simpler than PGP data format, and its public keys can be represented as did:key identifiers, while PGP keys would need a custom DID method.

I also implemented activity signing and verification using Ethereum and Minisign keys. Unfortunately there’s no browser extension that can create Minisign signatures, there are only command line tools, so this signing method is not suitable for everyone. (On the other hand, browser wallets are bad for privacy because they connect to 3rd party API providers and often contain trackers.)

---

In other news, Data Integrity spec was promoted to W3C Working Draft.

[silverpill]

Here’s my embedded signatures proposal: #21 - Add FEP-8b32: Object Integrity Proofs - fep - Codeberg.org

[Ciantic]

I’m just learning ActivityPub, but isn’t this already possible at some level? Because ActivityPub identity files contain your public key, which can be used to verify messages in other servers.

Suppose John Doe owns example.com he could store his identity in his own server but set outbox and inbox to some other server.

This way if he ever wants to change server to something else he just changes outbox and inbox addresses?

https://example.com/john.json

{

	"id": "https://example.com/john.json",

    // Inbox/outbox points to different server
	"inbox": "https://mastodon.social/users/JohnDoe/inbox",
	"outbox": "https://mastodon.social/users/JohnDoe/outbox",

    // private key is in mastodon.social
	"publicKey": {
		"id": "https://example.com/john.json#main-key,
		"owner": "https://example.com/john.json",
		"publicKeyPem": "-----BEGIN PUBLIC KEY-----\nMIIBIjANBgkqhkiG9w0At35owb...\n-----END PUBLIC KEY-----\n"
	}
}

Ideally you could have multiple private/public key pairs, one for each client. In this case Mastodon.social is only one, but if you had multiple you’d need multiple pairs.

[silverpill]

If he owns the domain and the server, why would he put his inbox and outbox on some other server? I don’t see any benefit in that.
Also, in your example the identity is still linked to domain name. If the identity server is not available, other actors will be unable to fetch the key.

[Ciantic]

It would make adoption easier if one could just put static file on own server, and let Mastodon or other server handle the dynamic parts i.e. outbox and inbox, and following etc.

(Kind of like email, you just point MX to someone who hosts the server, but you hold the identity.)

Yes it would link identity to domain, but that would be still better than putting identity files on random servers.

I know what you are after, something like in Bluesky, which has ephemeral identities with did but it also has domain specific ones.