Nomadic identity

Nomadic identity is a feature currently available only to Template:Internal Link and its latest successor commonly referred to as Template:Internal Link. It provides a unique way of moving between instances fairly easily and even cloning your Template:Internal Link identity. It is not available for or compatible with Template:Internal Link, though.

History

Nomadic identity was invented in 2011 by Mike Macgirvin. The year before, he had released a Facebook competitor named Mistpark, meanwhile renamed to Template:Internal Link. But decentralisation and community-run public nodes, as instances are called on Friendica, had started showing a side-effect, namely users losing their online identities and all their data whenever a node shut down. This would sometimes happen without announcement.

Template:Internal Link was implemented as far as that was possible so that people could relocate to elsewhere when the shutdown of their home node had been announced, but this would be of no help in the case of a sudden shutdown. Even full account backups weren't a remedy if they weren't made in the first place.

Macgirvin decided that the only way to secure people's online identity was for it to exist on multiple independent servers. Thus, the idea of nomadic identity was born. However, this was impossible to implement on Friendika with its Template:Internal Link protocol. So Macgirvin started designing a whole new protocol named Template:Internal Link. In 2012, he handed the development of what was now known as Friendica over to the community and forked it into what would become Template:Internal Link and, in 2015, evolve into Hubzilla.

What it does

Nomadic identity, as implemented on Hubzilla and (streams), relies on the availability of Template:Internal Link which serve as containers for the user's identity and content. It deals with the handling of these channels between servers.

Move

One advantage of nomadic identity is that it is probably the best existing way of moving your identity from one server to another. Unlike Template:Internal Link based on ActivityPub, it doesn't create a dumb copy or partial copy of your account on another server and leave the original behind as a usually dead account. It actually moves the content without leaving anything behind, and it moves all the content.

So let's suppose alice@foo.social wants to move to bar.social. The process goes like this:

• Create a new account on bar.social (unless Alice already has one there).
• Upload the whole alice@foo.social channel to the new account on bar.social. This can be done either by having bar.social download it from foo.social or by manually downloading the channel from foo.social to a file and then manually uploading this file to bar.social; the latter has been experienced to be more reliable.
• Change the identity of the channel which is still alice@foo.social at this point to alice@bar.social.
• Have all contacts on servers that understand nomadic identity change their connections with alice@foo.social to alice@bar.social. Hubzilla and (streams) users will only notice the move because the ID has changed, but everything will work the same after the move.
• Delete the old instance of the channel on foo.social.
• If the account on foo.social has no more channels, delete the account on foo.social.

Afterwards, at least on Hubzilla, all non-nomadic contacts, for example on Template:Internal Link, have to be manually notified of the move. They are one-sided at this point, i.e. they are followed, but not followers. So all followers have to manually follow alice@bar.social after the move.

Clone

How cloning works

The big killer feature of nomadic identity are clones. Nomadic identity makes it possible for one and the same channel to reside on multiple servers simultaneously. This is actually less complicated than it sounds.

The process of getting there starts much like a move, but with two differences: The original channel is not deleted. And thus, the original ID is kept by default. It can optionally be changed to refer to the new server, thus turning the original into a clone, but it doesn't have to.

So when Alice's alice@foo.social channel is uploaded to bar.social, this uploaded instance of the channel is not a dumb separate copy. It is automatically linked to its source on foo.social. Not only does it become a full identical clone of it, it remains an identical clone.

Both instances of the channel are fully kept in-sync with each other. And in fact, so do all other clones created later because you can have more than just one clone. You always have one "main instance" which normally is the one you copy everything from, but you can have as many clones as you can find servers for.

Whatever happens on the main instance is automatically and almost immediately mirrored to all clones. If you post something from your main instance, the post is only sent from the main instance, but mirrored to the clones and stored on them. If you upload an image, it's mirrored to the clones. If you connect to someone, that's mirrored to the clones.

Whatever happens on one of the clones is mirrored to the main instance and all other clones. For example, you can log onto one of your clones and post from it if the server with your main instance on it is down. In this case, it's only that clone that sends the post to the contacts, but the post is still mirrored.

Connections to channels on Hubzilla and (streams) which know nomadic identity also know about all clones. Messages sent from one of these channels to a cloned channel always go out to both the main instance and the clones, provided they're online. This ensures that there's always at least one instance of the channel that receives the message. At least on Hubzilla, a side-effect is that new messages have to be marked as read on all instances separately. If an instance couldn't receive a message in time, e.g. because it was offline, the message is cloned from one of the other instances later on.

The advantage of having such clones is having the greatest resilience possible in the Fediverse. Even if the server with the main instance of your channel on it spontaneously disappears, you lose nothing. You've got everything on your clones which will continue syncing changes between each other.

Selecting a new main instance

As already mentioned, cloning makes it possible to change the main instance, i.e. make one of the clones the main instance. In fact, moving does nothing else: It creates a nomadic clone, it automatically makes the clone the new main instance and the old original the clone, then it deletes the clone.

So if the server with the main instance on it has disappeared, you can make a clone the new main instance. Should the server with the main instance come back to life, it immediately syncs with the remaining instances, and what used to be the main instance will be demoted to clone.

The ID of a cloned channel always depends on where the main instance is. If the main instance resides on foo.social, then the ID is always e.g. alice@foo.social. Even the ID of the clones on bar.social and bax.social is alice@foo.social. If the clone on bar.social is chosen as the new main instance, then the ID changes to alice@bar.social on all instances, including the one on foo.social which becomes a clone.

That being said, switching main instances should be done with care. It takes several minutes to change the ID of a channel after switching its main instance. The ID has to be changed all across the channel itself, and all nomadic connections, i.e. currently those on Hubzilla and (streams), have to be changed. This process should not be disturbed until it's done.

How connections perceive clones and switched main instances

Nomadic identity, especially cloning, works best with connections which support nomadic identity themselves.

Channels on servers of projects that support nomadic identity are always fully aware of other channels on such servers being nomadic. If the Hubzilla channel alice@foo.social has clones on bar.social and baz.social, the Hubzilla channel bob@quux.social will be aware of that.

No matter which instance Alice sends something from, bob@quux.social will perceive it as coming from alice@foo.social because that's the identity of Alice's channel. Even if foo.social should be offline, the channel will still be identified as alice@foo.social.

Vice versa, everything bob@quux.social sends to alice@foo.social is always sent to foo.social, bar.social and baz.social. It'll only completely fail if all three are offline at the same time. If one of them is temporarily offline, what it has missed during its downtime will be mirrored to it afterwards.

If Alice switches the main instance to bar.social, all that changes for bob@quux.social is that the channel is named alice@bar.social now.

Connections on servers of projects that don't know nomadic identity behave differently. They don't know clones either and can't identify them as such. So to them, the clones of alice@foo.social appear as the separate "accounts" alice@bar.social and alice@baz.social, identities which they themselves patch together from the short name and the domain name.

This means that only messages sent from foo.social itself will appear as sent by alice@foo.social. Messages sent from bar.social will appear as sent by alice@bar.social even though there isn't even any account or channel with that ID, technically speaking. Users of Mastodon & Co. may be tempted to follow alice@bar.social even though they already follow alice@foo.social because they may think Alice has moved. Since only one instance of a clone ever sends any given message, they still only receive each message only once.

Messages sent from Mastodon & Co. are only sent to one instance of a cloned channel and then mirrored to the other instances. So if carol@mastodon.wherever has a mutual connection with alice@foo.social, but none with the clones, and posts something, that post only goes to the main instance on foo.social, and then it's mirrored from there to the clones on bar.social and baz.social. That way, all instances of the channel eventually receive the post.

However, this only works as long as the instance the post is sent to is actually online. If foo.social is down, Mastodon & Co. don't divert a post for alice@foo.social to alice@bar.social or alice@baz.social. They don't have a concept of clones, and they don't know that what they perceive as alice@bar.social and alice@baz.social are clones of alice@foo.social. So the transmission of the post is eventually dropped altogether due to a timeout.

This is a major reason why switching the main instance should be communicated to users of non-nomadic projects as having moved. They can stay connected to the former main instance, even though it's a clone now.

That is, in theory, such trouble could be avoided by cloned channels having all their followers on non-nomadic projects follow both the main instance and all clones. The followers will only suffer from a somewhat more cluttered list of followed "accounts" and maybe having to send the same direct message to multiple "accounts". But they will still only receive messages from these followed "accounts" only once.

On the other end, Hubzilla and (streams) will list connections from e.g. Mastodon to multiple instances of the same channel as only one connection. If the same Mastodon account connects to yet another instance of the channel, they won't notice and grant that Mastodon account the same rights it already had previously.

Implementations

The only Fediverse protocols which support nomadic identity are Template:Internal Link. Thus, nomadic identity is only implemented on Hubzilla and (streams).

It also used to be implemented on Hubzilla's direct predecessor, Red a.k.a. the Red Matrix, which had it first. Of the projects between Hubzilla and (streams), only the first Template:Internal Link didn't have it. The other two Osada incarnations, Template:Internal Link, Redmatrix 2020, Mistpark 2020 and Roadhouse, all had it implemented.

Bluesky, the commercial microblogging platform by Twitter founder Jack Dorsey, is working on a similar feature. However, Bluesky has only just started decentralising itself, and it is not connected to the Fediverse, save for through bridges and on a very few projects, including Friendica.