Export translations

Settings

Group

Language

Format

Export for off-line translation

Export in native format

Export in CSV format

<languages/>
<div lang="en" dir="ltr" class="mw-content-ltr">
'''Nomadic identity''' is a feature currently available only to {{Internal link |target=Hubzilla}} and its latest successor commonly referred to as {{Internal link |target=What is (streams)? |link-name=(streams)}}. It provides a unique way of moving between instances fairly easily and even cloning your {{Internal link |target=Fediverse |link-name=Fediverse}} identity. It is not available for or compatible with ActivityPub, though.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
== History ==
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Nomadic identity was invented in 2011 by Mike Macgirvin. The year before, he had released a Facebook competitor named Mistpark, meanwhile renamed to {{Internal link |target=Friendica |link-name=Friendika}}. 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.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
{{Internal link |target=Moving instances |link-name=Moving instances}} 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.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
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 {{Internal link |target=DFRN |link-name=DFRN}} protocol. So Macgirvin started designing a whole new protocol named {{Internal link |target=Zot and Nomad |link-name=Zot}}. In 2012, he handed the development of what was now known as Friendica over to the community and forked it into what would become {{Internal link |target=Redmatrix (discontinued) |link-name=the Red Matrix}} and, in 2015, evolve into Hubzilla.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Nomadic identity, as implemented on Hubzilla and (streams), relies on the availability of {{Internal link |target=Channels (Hubzilla & (streams)) |link-name=channels}} which serve as containers for the user's identity and content. It deals with the handling of these channels between servers.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
One advantage of nomadic identity is that it is probably the best existing way of moving your identity from one server to another. Unlike {{Internal link |target=Fediverse projects |link-name=projects}} 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.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
So let's suppose alice@foo.social wants to move to bar.social. The process goes like this:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
* 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.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Afterwards, at least on Hubzilla, all non-nomadic contacts, for example on {{Internal link |target=Mastodon |link-name=Mastodon}}, 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.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
=== Clone ===
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
==== How cloning works ====
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
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.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
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.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
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.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
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.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
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.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
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.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
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.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
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.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
==== Selecting a new main instance ====
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
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.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
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.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
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.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
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.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
==== How connections perceive clones and switched main instances ====
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Nomadic identity, especially cloning, works best with connections which support nomadic identity themselves.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
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.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
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.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
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.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
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.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
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.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
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.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
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.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
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.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
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.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
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.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
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.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
== Implementations ==
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
The only Fediverse protocols which support nomadic identity are {{Internal link |target=Zot and Nomad |link-name=Zot and Nomad}}. Thus, nomadic identity is only implemented on Hubzilla and (streams).
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
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 {{Internal link |target=Osada (discontinued) |link-name=Osada}} didn't have it. The other two Osada incarnations, {{Internal link |target=Zap (discontinued) |link-name=Zap}}, Redmatrix 2020, Mistpark 2020 and Roadhouse, all had it implemented.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
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.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
=== Compatibility between Hubzilla and (streams) ===
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Compatibility between the currently two implementations of nomadic identity is highly limited even though (streams) is a descendant of Hubzilla, and its Nomad protocol is a descendant of Hubzilla's Zot protocol.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Synchronised clones are only possible within the same server software. It is not possible to create a synchronised clone of a Hubzilla channel on (streams) or vice versa.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Using nomadic identity tools to move a channel from Hubzilla to (streams) is possible: The channel has to be manually exported from Hubzilla and then manually imported into a (streams) account. But since Nomad is so much more advanced than Zot, moving a channel from (streams) to Hubzilla is impossible without manipulating the exported channel, and manipulated exported (streams) channels can damage entire Hubzilla hubs upon import, so it is officially declared impossible.
</div>