Nomadic identity/fr: Difference between revisions

From Join the Fediverse
VisualWikitext
(Created page with "Supposons qu'alice@foo.social veut migrer sur bar.social. Le processus se déroule ainsi :")
(Updating to match new version of source page)
Tags: Mobile edit Mobile web edit
 
(49 intermediate revisions by 3 users not shown)
Line 1: Line 1:
<languages/>
<languages/>
'''L'identité nomade''' est une fonctionalité pour le moment uniquement présente sur {{Internal Link |target=What is Hubzilla? |link-name=Hubzilla}} et son dernier successeur connu sous le nom de {{Internal Link |target=What is (streams)? |link-name=(streams)}}. Il offre un moyen unique de se déplacer dans d'autres instances facilement et de dupliquer votre identité du {{Internal Link |target=What is the Fediverse? |link-name=Fediverse}}. Cependant, ce n'est pas disponible, ni compatible avec {{Internal Link |target=What is ActivityPub? |link-name=ActivityPub}}
<div class="mw-translate-fuzzy">
'''L'identité nomade''' est une fonctionalité pour le moment uniquement présente sur {{Internal link |target=Hubzilla}} et son dernier successeur connu sous le nom de {{Internal link |target=What is (streams)? |link-name=(streams)}}. Il offre un moyen unique de migrer dans d'autres instances facilement et de dupliquer votre identité du {{Internal link |target=What is the Fediverse? |link-name=Fediverse}}. Cependant, ce n'est pas disponible, ni compatible avec {{Internal link |target=What is ActivityPub? |link-name=ActivityPub}}
</div>


<span id="History"></span>
<span id="History"></span>
== Histoire ==
== Histoire ==


L'identité nomade fut créée en 2011 par Mike Macgirvin. L'année d'avant, il a lancé un concurrent à Facebook : Mistpark, depuis renommée {{Internal Link |target=What is Friendica? |link-name=Friendika}}. Mais la décentralisation et les instances de Friendica, appelées noeuds public, qui étaient gérés par la communauté, ont eu des déffaillances. Les utilisatrices et utilisateurs ont perdu leur compte et tout leur données à chaque fois qu'un noeud s'éteignait. Cela arrivait parfois sans aucune annonces.
<div class="mw-translate-fuzzy">
L'identité nomade fut créée en 2011 par Mike Macgirvin. L'année d'avant, il a lancé un concurrent à Facebook : Mistpark, depuis renommée {{Internal link |target=Friendica |link-name=Friendika}}. Mais la décentralisation et les instances de Friendica, appelées noeuds public, qui étaient gérés par la communauté, ont eu des déffaillances. Les utilisatrices et utilisateurs ont perdu leur compte et tout leur données à chaque fois qu'un noeud s'éteignait. Cela arrivait parfois sans aucune annonces.
</div>


{{Internal Link |target=Moving instances |link-name=Changer d'instances}} a été mis en oeuvre aussi poussé qae possible pour que toat le monde puisse se relocaliser ailleur quand la fin de leur noeud-mère a été annoncé, mais cela ne fut d'aucune aide  dans le cas d'une fermeture soudaine. Même les sauvegardes complètes de leur compte n'étaient d'aucune aide si elles n'étaient pas réalisées.
{{Internal link |target=Moving instances |link-name=La migration d'instances}} a été mis en oeuvre aussi poussé que possible pour que tout le monde puisse se relocaliser ailleur lorsque la fermeture de leur noeud-mère a été annoncé, mais cela ne fut d'aucune aide  dans le cas d'une fermeture soudaine. Même les sauvegardes complètes de leur compte n'étaient d'aucune aide si elles n'étaient pas réalisées.


Macgirvin a décidé que le seul moyen de protéger les identités en ligne des personnes était qu'elles puissent exister sur plusieurs serveurs indépendants. Ainsi, l'idée d'une identité nomade émergeat. Cependant, ce fut impossible de la mettre en oeuvre sur Friendica avec son {{Internal Link |target=DFRN |link-name=protocole DFRN}}. Donc Macgirvin a conçut un nouveau protocole appelé {{Internal Link |target=Zot and Nomad |link-name=Zot}}. En 2012, il laisse le développement de ce qui était connu sous Friendica à la communauté et crée une nouvelle branche de ce qui deviendra {{Internal Link |target=What is the Red Matrix? |link-name=the Red Matrix}} et en 2015, évoluera en Hubzilla.
<div class="mw-translate-fuzzy">
Macgirvin a décidé que le seul moyen de protéger les identités en ligne des personnes était qu'elles puissent exister sur plusieurs serveurs indépendants. Ainsi, l'idée d'une identité nomade émergeat. Cependant, ce fut impossible de la mettre en oeuvre sur Friendica avec son {{Internal link |target=DFRN |link-name=protocole DFRN}}. Donc Macgirvin a conçut un nouveau protocole appelé {{Internal link |target=Zot and Nomad |link-name=Zot}}. En 2012, il laisse le développement de ce qui était connu sous Friendica à la communauté et crée une nouvelle branche de ce qui deviendra {{Internal link |target=Redmatrix (discontinued) |link-name=the Red Matrix}} et en 2015, évoluera en Hubzilla.
</div>


<span id="What_it_does"></span>
<span id="What_it_does"></span>
== Comment ça fonctionne ? ==
== Que fait-il ? ==


L'identité nomade, telle que mise en oeuvre par Hubzilla et (streams), s'appuie sur la disponibilité des {{Internal Link |target=What are channels on Hubzilla and (streams)? |link-name=chaînes}} qui servent de conteneur pour l'identité et le contenu des utilisatrices et utilisateurs. Il gère la gestion de ces chaînes entre les serveurs.
<div class="mw-translate-fuzzy">
L'identité nomade, telle que mise en oeuvre par Hubzilla et (streams), s'appuie sur la disponibilité des {{Internal link |target=Channels (Hubzilla & (streams)) |link-name=chaînes}} qui servent de conteneur pour l'identité et le contenu des utilisatrices et utilisateurs. Il gère la gestion de ces chaînes entre les serveurs.
</div>


<span id="Move"></span>
<span id="Move"></span>
=== La migration ===
=== La migration ===


Un des avantages de l'identité nomade, est que c'est probablement la meilleure méthode existante pour migrer votre identité d'un serveur à un autre.. Contrairement aux {{Internal Link |target=What are Fediverse projects? |link-name=projets}} reposant sur ActivityPub, il ne crée pas de copie, ni de copie partielle de votre compte sur un autre serveur et laisse le compte originel derrière comme un compte mort. En fait, il ''déplace'' le contenu sans rien laisser derrière, puis il déplace ''tout'' le contenu.
Un des avantages de l'identité nomade, est que c'est probablement la meilleure méthode existante pour migrer votre identité d'un serveur à un autre.. Contrairement aux {{Internal link |target=Fediverse projects |link-name=projets}} reposant sur ActivityPub, il ne crée pas de copie, ni de copie partielle de votre compte sur un autre serveur et laisse le compte originel derrière comme un compte mort. En fait, il ''déplace'' le contenu sans rien laisser derrière, puis il déplace ''tout'' le contenu.


Supposons qu'alice@foo.social veut migrer sur bar.social. Le processus se déroule ainsi :
Supposons qu'alice@foo.social veut migrer sur bar.social. Le processus se déroule ainsi :


<div lang="en" dir="ltr" class="mw-content-ltr">
* Créer un nouveau compte sur bar.social (Sauf si Alice en possède un ici).
* Create a new account on bar.social (unless Alice already has one there).
* Téléverser complètement la chaîne d'alice@foo.social sur le nouveau compte bar.social. Ceci peut être réalisé soit en demandant à bar.social de le télécharger depuis foo.social. Ou en téléchargeant manuellement la chaîne foo.social vers un fichier. Puis de le téléverser manuellement ce fichier vers bar.social; cette dernière méthode est considérée comme plus sur et reliable.
* 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.
* Changer l'identité de la chaîne qui est encore restée sous  alice@foo.social at vers alice@bar.social.
* Change the identity of the channel which is still alice@foo.social at this point to alice@bar.social.
* Tous les contacts les servers qui comprennent l'identité nomade change leur connection avec alice@foo.social vers alice@bar.social. les utilisatrices et les utilisateurs remarqueront seulement la migration car l'ID a changé, mais tout marchera de la même manière après la migration.
* 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.
* Supprimer la vieille instance de la chaîne sur foo.social.
* Delete the old instance of the channel on foo.social.
* Si le compte sur foo.social n'a plus de chaînes, supprimer le compte sur 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">
<div class="mw-translate-fuzzy">
Afterwards, at least on Hubzilla, all non-nomadic contacts, for example on {{Internal Link |target=What is 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.
Peu après, du moins sur Hubzilla, tous les contacts non-nomades, par exemple ceux sur {{Internal link |target=Mastodon |link-name=Mastodon}}, doivent être notifié manuellement de la migration. À partir de là, cela ne fonctionnera que dans un sens, c'est à dire qu'ils seront suivis mais pas abonnés. Donc tous vos abonnés devront manuellement s'abonner à alice@bar.social après la migration.
</div>
</div>


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


<div lang="en" dir="ltr" class="mw-content-ltr">
<span id="How_cloning_works"></span>
==== How cloning works ====
==== Comment le clonage fonctionne ? ====
</div>


<div lang="en" dir="ltr" class="mw-content-ltr">
La pièce maitresse des comptes nomades sont les clones. L'identité nomade permet à une et même chaîne de résider sur plusieurs serveurs en parrallèle. C'est en fait moins compliqué qu'il n'y paraît.
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">
Le processus pour en arriver là commence comme celle de la migration, mais avec deux différences : la chaîne d'origine n'est pas supprimée. Par conséquent, l'ID d'origine est gardée par défaut. Elle peut être optionellement modifié pour faire référence au nouveau serveur, transformant ainsi l'original en clone, mais ce n'est pas obligé.
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">
Donc quand la chaîne d'Alice, alice@foo.social est téléversée sur bar.social, la chaîne téléversé sur cette instance n'est pas une simple copie. Elle est automatiquement reliée  sa source sur foo.social. Non seulement cela crée un clone identique parfait, ça ''reste'' un clone identique.
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">
Les deux instances de la chaine sont syncronisées avec l'une et l'autre. Et en fait, il en va de même pour tous les autres clones créés ultérieurement, car vous pouvez avoir plusieurs clones. Vous avez toujours une "instance principale" qui est normalement celle à partir de laquelle vous copiez tout, mais vous pouvez avoir autant de clones que vous pouvez trouver de serveurs.
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">
Tout ce qui se passe sur l'instance principale est automatiquement et presque immédiatement répliqué sur tous les clones. Si vous publiez quelque chose depuis votre instance principale, la publication est uniquement envoyée depuis l'instance principale, mais mise en miroir sur les clones et stockée sur ceux-ci. Si vous téléchargez une image, elle est répliquée vers les clones. Si vous vous connectez à quelqu'un, cela se répliqué dans les clones.
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">
Tout ce qui se passe sur l'instance principale est automatiquement et presque immédiatement répliqué sur tous les clones. Si vous publiez quelque chose depuis votre instance principale, la publication est uniquement envoyée depuis l'instance principale, mais mise en miroir sur les clones et stockée sur ceux-ci. Si vous téléchargez une image, elle est répliquée sur les clones. Si vous vous connectez à quelqu'un, cela se réplique dans les 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.
</div>


<div lang="en" dir="ltr" class="mw-content-ltr">
Les connexions aux chaînes sur Hubzilla et (streams) qui connaissent l'identité nomade connaissent également tous les clones. Les messages envoyés depuis l'une de ces chaînes vers une chaîne clonée sont toujours envoyés à la fois à l'instance principale et aux clones, à condition qu'elles soient en ligne. Cela garantit qu'il existe toujours au moins une instance du canal qui reçoit le message. Au moins sur Hubzilla, un effet secondaire est que les nouveaux messages doivent être marqués comme lus séparément sur toutes les instances. Si une instance n'a pas pu recevoir un message à temps, par ex. comme elle était hors ligne, le message est cloné ultérieurement à partir de l'une des autres instances.
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">
L'avantage d'avoir de tel clones est d'avoir la plus grande résilience possible dans le Fédiverse. Même si le serveur de l'instance principale de votre chaîne tombe, vous ne perderez rien. Tout sera conservé sur vos clones qui continueront de syncroniser les changements entre-eux.
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">
<span id="Selecting_a_new_main_instance"></span>
==== Selecting a new main instance ====
==== Choisir une nouvelle instance principale ====
</div>


<div lang="en" dir="ltr" class="mw-content-ltr">
Comme déjà précisé, cloner permet de changer d'instance principale, c'est à dire faire d'un des clones l'instance principale. En fait, la migration ne fait rien d'autre : elle crée un clone nomade, fait automatiquement du clone la nouvelle instance principale et de l'ancien original le clone, puis supprime le clone.
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">
Du coup, si le serveur avec l'instance principale dessus disparait, vous pouvez faire d'un des clones la nouvelle instance principale. Si jamais le serveur avec l'instance principale est remis sur pied, il syncronisera immédiatement avec les autres instances, et ce qui était autrefois l'instance principale sera rétrogradé au rang de 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.
</div>


<div lang="en" dir="ltr" class="mw-content-ltr">
<div lang="en" dir="ltr" class="mw-content-ltr">
Line 153: Line 135:


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


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


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


{{Navbar}}
{{Navbar}}
{{category |category=Beginners guides}}
{{category |category=Usage}}
{{Category |category=What is}}

Latest revision as of 06:07, 14 November 2024

Other languages:

L'identité nomade est une fonctionalité pour le moment uniquement présente sur Hubzilla et son dernier successeur connu sous le nom de (streams). Il offre un moyen unique de migrer dans d'autres instances facilement et de dupliquer votre identité du Fediverse. Cependant, ce n'est pas disponible, ni compatible avec ActivityPub

Histoire

L'identité nomade fut créée en 2011 par Mike Macgirvin. L'année d'avant, il a lancé un concurrent à Facebook : Mistpark, depuis renommée Friendika. Mais la décentralisation et les instances de Friendica, appelées noeuds public, qui étaient gérés par la communauté, ont eu des déffaillances. Les utilisatrices et utilisateurs ont perdu leur compte et tout leur données à chaque fois qu'un noeud s'éteignait. Cela arrivait parfois sans aucune annonces.

La migration d'instances a été mis en oeuvre aussi poussé que possible pour que tout le monde puisse se relocaliser ailleur lorsque la fermeture de leur noeud-mère a été annoncé, mais cela ne fut d'aucune aide dans le cas d'une fermeture soudaine. Même les sauvegardes complètes de leur compte n'étaient d'aucune aide si elles n'étaient pas réalisées.

Macgirvin a décidé que le seul moyen de protéger les identités en ligne des personnes était qu'elles puissent exister sur plusieurs serveurs indépendants. Ainsi, l'idée d'une identité nomade émergeat. Cependant, ce fut impossible de la mettre en oeuvre sur Friendica avec son protocole DFRN. Donc Macgirvin a conçut un nouveau protocole appelé Zot. En 2012, il laisse le développement de ce qui était connu sous Friendica à la communauté et crée une nouvelle branche de ce qui deviendra the Red Matrix et en 2015, évoluera en Hubzilla.

Que fait-il ?

L'identité nomade, telle que mise en oeuvre par Hubzilla et (streams), s'appuie sur la disponibilité des chaînes qui servent de conteneur pour l'identité et le contenu des utilisatrices et utilisateurs. Il gère la gestion de ces chaînes entre les serveurs.

La migration

Un des avantages de l'identité nomade, est que c'est probablement la meilleure méthode existante pour migrer votre identité d'un serveur à un autre.. Contrairement aux projets reposant sur ActivityPub, il ne crée pas de copie, ni de copie partielle de votre compte sur un autre serveur et laisse le compte originel derrière comme un compte mort. En fait, il déplace le contenu sans rien laisser derrière, puis il déplace tout le contenu.

Supposons qu'alice@foo.social veut migrer sur bar.social. Le processus se déroule ainsi :

  • Créer un nouveau compte sur bar.social (Sauf si Alice en possède un ici).
  • Téléverser complètement la chaîne d'alice@foo.social sur le nouveau compte bar.social. Ceci peut être réalisé soit en demandant à bar.social de le télécharger depuis foo.social. Ou en téléchargeant manuellement la chaîne foo.social vers un fichier. Puis de le téléverser manuellement ce fichier vers bar.social; cette dernière méthode est considérée comme plus sur et reliable.
  • Changer l'identité de la chaîne qui est encore restée sous alice@foo.social at vers alice@bar.social.
  • Tous les contacts les servers qui comprennent l'identité nomade change leur connection avec alice@foo.social vers alice@bar.social. les utilisatrices et les utilisateurs remarqueront seulement la migration car l'ID a changé, mais tout marchera de la même manière après la migration.
  • Supprimer la vieille instance de la chaîne sur foo.social.
  • Si le compte sur foo.social n'a plus de chaînes, supprimer le compte sur foo.social.

Peu après, du moins sur Hubzilla, tous les contacts non-nomades, par exemple ceux sur Mastodon, doivent être notifié manuellement de la migration. À partir de là, cela ne fonctionnera que dans un sens, c'est à dire qu'ils seront suivis mais pas abonnés. Donc tous vos abonnés devront manuellement s'abonner à alice@bar.social après la migration.

Clone

Comment le clonage fonctionne ?

La pièce maitresse des comptes nomades sont les clones. L'identité nomade permet à une et même chaîne de résider sur plusieurs serveurs en parrallèle. C'est en fait moins compliqué qu'il n'y paraît.

Le processus pour en arriver là commence comme celle de la migration, mais avec deux différences : la chaîne d'origine n'est pas supprimée. Par conséquent, l'ID d'origine est gardée par défaut. Elle peut être optionellement modifié pour faire référence au nouveau serveur, transformant ainsi l'original en clone, mais ce n'est pas obligé.

Donc quand la chaîne d'Alice, alice@foo.social est téléversée sur bar.social, la chaîne téléversé sur cette instance n'est pas une simple copie. Elle est automatiquement reliée sa source sur foo.social. Non seulement cela crée un clone identique parfait, ça reste un clone identique.

Les deux instances de la chaine sont syncronisées avec l'une et l'autre. Et en fait, il en va de même pour tous les autres clones créés ultérieurement, car vous pouvez avoir plusieurs clones. Vous avez toujours une "instance principale" qui est normalement celle à partir de laquelle vous copiez tout, mais vous pouvez avoir autant de clones que vous pouvez trouver de serveurs.

Tout ce qui se passe sur l'instance principale est automatiquement et presque immédiatement répliqué sur tous les clones. Si vous publiez quelque chose depuis votre instance principale, la publication est uniquement envoyée depuis l'instance principale, mais mise en miroir sur les clones et stockée sur ceux-ci. Si vous téléchargez une image, elle est répliquée vers les clones. Si vous vous connectez à quelqu'un, cela se répliqué dans les clones.

Tout ce qui se passe sur l'instance principale est automatiquement et presque immédiatement répliqué sur tous les clones. Si vous publiez quelque chose depuis votre instance principale, la publication est uniquement envoyée depuis l'instance principale, mais mise en miroir sur les clones et stockée sur ceux-ci. Si vous téléchargez une image, elle est répliquée sur les clones. Si vous vous connectez à quelqu'un, cela se réplique dans les clones.

Les connexions aux chaînes sur Hubzilla et (streams) qui connaissent l'identité nomade connaissent également tous les clones. Les messages envoyés depuis l'une de ces chaînes vers une chaîne clonée sont toujours envoyés à la fois à l'instance principale et aux clones, à condition qu'elles soient en ligne. Cela garantit qu'il existe toujours au moins une instance du canal qui reçoit le message. Au moins sur Hubzilla, un effet secondaire est que les nouveaux messages doivent être marqués comme lus séparément sur toutes les instances. Si une instance n'a pas pu recevoir un message à temps, par ex. comme elle était hors ligne, le message est cloné ultérieurement à partir de l'une des autres instances.

L'avantage d'avoir de tel clones est d'avoir la plus grande résilience possible dans le Fédiverse. Même si le serveur de l'instance principale de votre chaîne tombe, vous ne perderez rien. Tout sera conservé sur vos clones qui continueront de syncroniser les changements entre-eux.

Choisir une nouvelle instance principale

Comme déjà précisé, cloner permet de changer d'instance principale, c'est à dire faire d'un des clones l'instance principale. En fait, la migration ne fait rien d'autre : elle crée un clone nomade, fait automatiquement du clone la nouvelle instance principale et de l'ancien original le clone, puis supprime le clone.

Du coup, si le serveur avec l'instance principale dessus disparait, vous pouvez faire d'un des clones la nouvelle instance principale. Si jamais le serveur avec l'instance principale est remis sur pied, il syncronisera immédiatement avec les autres instances, et ce qui était autrefois l'instance principale sera rétrogradé au rang de 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 Zot and Nomad. 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 Osada didn't have it. The other two Osada incarnations, Zap, 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.

Compatibility between Hubzilla and (streams)

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.

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.

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.

Navigation bar
About the Fediverse
🏠 🐎 🔠 💬 👤 ✏️ 🚚 📱 😇 ❓ 📍 🔗
Fediverse projects
Wiki More Editing
ℹ️ 🗺 ⌛️ 🏅 🌍 📰 🛠 🔄 💢 🚧 ☑️ 🎮
Retrieved from "https://joinfediverse.wiki/index.php?title=Nomadic_identity/fr&oldid=36081"