#nomadicidentity

The NomadPub intro page now includes a "Research" section: https://codeberg.org/ap-next/ap-next/src/branch/main/nomadpub.md#research I listed the most important open research problems there: key management (alt-DIDs), alternative transports, E2EE and generic servers. #NomadicIdentity

@@patrickleavy@mastodon.social A whole lot. Sorry, but this will be very very very long again. I don't know if you've read my previous (very long) commentary. But just implementing one or two FEPs won't get you the same full-blown nomadic identity (https://joinfediverse.wiki/Nomadic_identity) that Hubzilla (what I'm writing from right now; https://hubzilla.org https://en.wikipedia.org/wiki/Hubzilla https://joinfediverse.wiki/Hubzilla) has had since 2012. And having this level of nomadic identity has to be the goal. What has to be done is: Take something like Mastodon. Non-nomadic. Where your account, your login, equals your identity. Make your identity cloneable Now, before you can make identities nomadic, you have to uncouple them from the login, from the account. Mastodon has to introduce a sort of container for your identity, like the channels that Hubzilla, (streams) and Forte have always had (https://joinfediverse.wiki/Channels_(Hubzilla_&_(streams))) This is necessary so that a future nomadic Mastodon will know what to clone and what not to clone. For example, cloning your password is dangerous nonsense. So, everything that makes up your account except for your login credentials will have to be moved into this container. your short nameyour long nameyour profile images, including alt-textsyour profileyour followersyour followedyour toots, including stats like faves, boosts etc.copies of the conversation trees of all your toots, including stats like faves, boosts etc. as well as attached files for each messageall files you've ever attached to tootsyour settingsyour filtersyour mutesyour blocksyour server blocksetc.Essentially, everything except for your login credentials will have to be moved from directly residing on your account into that box. Change your login Also, your login will have to change from short name + passphrase to e-mail + passphrase. Your short name is part of your identity, it's in the container, it will be cloned, so it can't be used to log you in anymore. In order for this to work, half of Mastodon's server backend will have to be rewritten. Decentralised IDs Next, Mastodon must switch from the Webfinger IDs that it uses now to decentralised IDs as per FEP-ef61. For a while, I guess, it will have to use both next to one another. Then it will have to phase out its Webfinger IDs. The decentralised IDs must be tested against other Fediverse software that already understands them or that's nomadic itself: (streams), Forte, Mitra, Tootik. For example, @@silverpill@mitra.social of Mitra and @Mike Macgirvin of (streams) and Forte must test whether their software correctly understands Mastodon's DIDs. And the Mastodon developers must test whether Mastodon correctly understands the DIDs from Fediverse server applications that already use them. Once it has gotten rid of its Webfinger IDs, the next phase can start. Implement cloning within Mastodon The central element of nomadic identity is not the ability to move your identity. That's only a byproduct of cloning your identity. A clone, in nomadic identity, is a full backup of the container with your identity in it. A real-time, live, bidirectional backup that you can log into and use just like the "original". The clone always has the same idea as the original, regardless of which server it's on. The key elements of clones and cloning must be implemented and tested: cloning an identity container to a different server after registering a new, blank account therecloning an identity container to a different server where you already have an account with a different containerised identityanything that happens on the original being sync'd to the cloneanything that happens on the clone being sync'd to the originalclone going offline, things happening on the original, clone coming back online, things that happened on the original being reliably sync'd to the cloneoriginal going offline, clone still working with the ID based on the original's domainoriginal going offline, things happening on the clone, original coming back online, things that happened on the clone being reliably sync'd to the originalmaking additional clones of an identity container that has already been cloned at least oncethe whole syncing shebang from the original to any number of clonesthe whole syncing shebang from one of the clones to the original and also directly to the other clonesdeclaring one of the clones the new original, thus changing the ID of both the former original and all clones Implement moving within Mastodon Only when cloning works reliably, we can talk about moving, even though that's what everyone on Mastodon is giddy about. Why? Because moving involves cloning. It's an automated process. At least it is on Hubzilla, (streams) and Forte, and it really should be one on nomadic Mastodon. Basically, first you make a clone. Then you declare the clone the new original, and your old original is demoted to a clone. Then you have to wait until your change of ID from changing the original has federated to all your followers and followed and everywhere and whatnot. Then, one last sync so that both the former-clone-now-new-original and the old-original-now-clone are really identical, and you won't lose any data. Then your old-original-now-clone is deleted. We don't want to leave any dead stuff behind, now, do we? Lastly, if your old account where your old original used to reside has no other identity on it, the whole account is deleted. In nomadic containerised identity, accounts cannot/should not exist with no identity container on them. Cloning and moving beyond Mastodon The last possible step is still utter science-fiction: Cloning or moving from Mastodon to something else that's nomadic and understands FEP-ef61. Cloning or moving from Mastodon to Mitra. From Mastodon to Tootik. From Mastodon to (streams). From Mastodon to Forte. Oh, and maybe also back to Mastodon. The difficult part is not only to make Mastodon capable of cloning identity containers to other nomadic software. And to make Mastodon accept identity containers from other nomadic software being cloned to Mastodon. I mean, this would be difficult already. (streams) and Forte are vastly, vastly different from Mastodon. No, the difficult part is to make these four capable of cloning from or to someplace else. As it stands now, you can only clone from Mitra to Mitra, from Tootik to Tootik, from (streams) to (streams), from Forte to Forte. Even cloning between (streams) and Forte has never been possible, even though they're very similar. Oh, and cloning from and to Hubzilla is another story because Hubzilla doesn't have FEP-ef61 implemented. #Long #LongPost #CWLong #CWLongPost #FediMeta #FediverseMeta #CWFediMeta #CWFediverseMeta #Fediverse #Mastodon #Hubzilla #Streams #(streams) #Forte #Mitra #Tootik #NomadicIdentity

Updating FEP-ef61: Portable Objects: https://codeberg.org/fediverse/fep/pulls/883

I added a section about key management. This part of nomadic identity was often misunderstood - some people thought that secret keys need to be managed by servers, and that servers could impersonate users.

No, there are 3 options:

• Server-side signing: secret keys are managed by a server (gateway). Activities are generated and immediately signed by a server.
• Delegated signing: secret keys are managed by a separate service. Activities are generated by a server, which calls a signing service and then adds integrity proofs to activities.
• Client-side signing: secret keys are managed by a client. Activities are generated and signed by a client, which communicates with a server via FEP-ae97 API.

Server-side signing is easier to implement, but client-side signing was the goal from the beginning - and this is what I am trying to do with Mitra Mini

#fep_ef61 #NomadicIdentity

One caveat I might have, and this is not an issue with the article, of course, and I generally agree that "the fediverse needs more apps", but! This is where the Atmosphere has a big advantage. Yes, some of us might prefer to have separate accounts on different servers and platforms, and keep individual hobbies, interests, and other layers of our personality separate. I think that's fine. But some of us might prefer to manage one account, and until nomadic identity is widely supported across the fediverse, having more apps to sign up for might not entice everyone. Just a thought! https://socialhub.activitypub.rocks/t/nomadic-identity-for-the-fediverse #fediverse #NomadicIdentity

FEP-ef61: Portable Objects has been updated: https://codeberg.org/fediverse/fep/pulls/872 The ap+ef61 URI scheme is now allowed, while ap remains the recommended one. This is to ensure compatibility with @fedify@hollo.social whose maintainers decided to use the ap+ef61 scheme until the specification is finalized. #fep_ef61 #nomadicidentity