Texte original : « Le protocole social est déployé ! » Qu’est-ce que Farcaster ? 》

Auteur : ELEN

Farcaster Protocol est un autre produit phare sur la piste SocialFi après Lens Protocol. Il s'agit d'un projet des anciens dirigeants de Coinbase, Dan Romero et Varun Srinivasan, qui a actuellement reçu 30 millions de dollars d'investissement dirigé par A16Z.

L'objectif de Farcaster est de fournir un protocole neutre et fiable pour l'écosystème WEB3, permettant aux utilisateurs d'avoir un contact direct avec leur public, tout en permettant aux développeurs de créer librement de nouveaux clients.

Viafarcaster V Dieu s'est installé

L'objectif à long terme de Farcaster est de devenir une infrastructure sous-jacente importante dans la voie sociale WEB3. Cela est cohérent avec l'orientation de Lens Protocol. Cependant, la conception architecturale de Farcaster est beaucoup plus sophistiquée que celle de Lens Protocol et tente de combler le fossé. entre WEB2 et WEB3. Une stratégie pour trouver un point d’équilibre optimal.

ViaBlockTurbo

Aujourd'hui, nous allons examiner de plus près la conception de la couche de protocole de Farcaster et les idées d'applications écologiques. Si vous souhaitez étudier en profondeur, vous pouvez consulter le github officiel :

https://github.com/farcasterxyz/protocol

Introduction à Farcaster

Les réseaux sociaux ont connu la croissance la plus rapide au cours des 10 dernières années. De nombreuses plateformes sociales fournissent aux développeurs des API, permettant aux développeurs de « créer secondairement » et de développer de nouveaux écosystèmes, tels que divers plug-ins amusants sur Twitter. Cependant, ces dernières années, les choses ne semblent pas aller bien. Il semble y avoir de moins en moins de choses que les développeurs peuvent faire. Les restrictions sur les API et diverses censures font que les développeurs ne sont plus libres, parfois même sans préavis. privés du droit d’accès.

Farcaster est un protocole complètement décentralisé qui permet aux développeurs de créer des applications de réseaux sociaux décentralisées. La définition de Farcaster de la décentralisation est simple : lorsque deux utilisateurs souhaitent communiquer entre eux, il n’y a aucun moyen de l’empêcher. Autrement dit, les utilisateurs ont un contrôle total sur leur identité, leurs données et leurs connexions sociales. Les développeurs peuvent créer une application sociale complètement décentralisée en brisant les restrictions de tout tiers ou même du réseau.

Cette vision est également ce que Lens Protocol veut réaliser. Nous pouvons penser que la plus grande valeur du protocole sous-jacent de SocialFi est de fournir une méthode de mise en œuvre technique sous-jacente complètement décentralisée, afin qu'il ne soit contrôlé par aucun tiers. Semblable à la valeur d’IPFS sur le marché du stockage décentralisé.

Viafarcaster.network Architecture Farcaster

Farcaster adopte une architecture hybride on-chain + off-chain pour achever la construction d'un protocole décentralisé. L'identité de Farcaster est stockée sur la chaîne Ethereum et exploite Ethereum pour garantir sa sécurité, sa composabilité et sa cohérence. Les identités sont contrôlées via les adresses Ethereum et les messages hors chaîne sont signés via des comptes Ethereum.

Les données de l'utilisateur sont cryptées et signées via l'identité et stockées sur des serveurs contrôlés par l'utilisateur (Farcaster Hubs). La raison pour laquelle les données ne sont pas stockées sur la chaîne est que le coût de règlement sur la plupart des réseaux L1 et L2 est trop élevé et la vitesse. est trop lent.

Cette architecture est différente de la conception du protocole LENS. Farcaster prend davantage en compte les besoins réels des développeurs et ressemble davantage à l'expression des médias sociaux WEB2, réduisant ainsi le coût de l'apprentissage des utilisateurs. Cependant, Farcaster est toujours décentralisé et l'identité des utilisateurs. , les données et les relations sociales sont basées sur la blockchain.

Compte

Les comptes Farcaster sont similaires aux comptes sur les réseaux sociaux pseudonymes tels que Twitter ou Reddit, et les individus peuvent gérer plusieurs comptes en même temps. Chaque compte est associé à un numéro unique, appelé Farcaster ID ou Fid. Un identifiant Farcaster peut être obtenu à partir d'une adresse Ethereum en appelant le registre des identifiants Farcaster (FIR). Cette adresse est appelée adresse séquestre et peut signer des informations hors chaîne et en chaîne au nom du compte. Les utilisateurs peuvent choisir d'obtenir un nom Farcaster ou un fname auprès du Farcaster Name Registry (FNR), qui leur attribue un nom unique tel que @alice.

On peut comprendre que Fid est une identité en chaîne, tandis que FNR est une identité socialement lisible. Si Fid est l'adresse du portefeuille, alors FNR est ENS.

Informations sur la signature

Les informations de signature sont un objet infalsifiable et autocertifié, signé par fid. Les informations de signature représentent les actions de l'utilisateur, telles que la publication, les commentaires sur les réseaux sociaux (commentaires/retweet) ou la modification des informations du compte, telles que le nom d'utilisateur.

Les messages signés ont des attributs de message, qui contiennent une charge utile. La charge utile est sérialisée, hachée et signée par une paire de clés valide (par exemple, l'adresse du costume). L'enveloppe contient le hachage, la signature et la clé publique de la paire de clés de signature, que tout destinataire peut utiliser pour vérifier la signature du fid.

Les messages doivent être sérialisés à l'aide de RFC-8785, hachés à l'aide de BLAKE2b et signés à l'aide du schéma de signature Ed25519. Chaque message doit également contenir un fid pour interroger l'adresse du dépôt en chaîne et un horodatage pour le tri.

application

Les applications sont les programmes que les gens utilisent pour interagir avec le réseau Farcaster. Une application simple peut consister en un client de bureau ou mobile autonome qui communique directement avec Farcaster Hub. Il peut publier de nouveaux messages et afficher les messages publiés par d'autres FID. Ces applications sont auto-hébergées et doivent être instanciées avec une adresse d'hébergement ou une clé de signature valide.

Des applications plus complexes peuvent ajouter un serveur principal proxy pour indexer les données du Hub. L'indexation permet au serveur de mettre en œuvre des fonctions telles que la recherche, l'alimentation d'algorithmes et la détection du spam, qui sont difficiles ou coûteuses à exécuter sur le Hub. Une telle application peut être auto-hébergée en stockant les clés sur le client ; être déléguée en exigeant que l'utilisateur fournisse une clé de signature déléguée ou être déposée en gérant toutes les clés ;

Moyeux

Le Hub est un serveur permanent qui vérifie, stocke et réplique les informations de signature. L'utilisateur sélectionne un Hub et publie son URL sur la chaîne à l'aide de FIR. Leurs abonnés peuvent utiliser cette URL pour rechercher et télécharger leurs messages. Dans le même temps, les utilisateurs peuvent également exécuter eux-mêmes le Hub ou utiliser des services d'hébergement tiers.

L'identité de Farcaster

Le système d'identité de Farcaster permet à l'identité d'un utilisateur d'avoir les propriétés suivantes :

Sécurisé et entièrement décentralisé Facilement identifiable sur les réseaux sociaux Facile à mettre en place (rapide et bon marché) Récupérable (ne viole pas la nature de la décentralisation)

Ces fonctionnalités sont difficiles à mettre en œuvre dans un système d’identité car elles sont souvent en conflit. Par exemple, il est difficile d’avoir un système de noms décentralisé et fiable (par exemple s’il faut garantir l’unicité du système de noms).

Farcaster équilibre ces fonctionnalités via deux systèmes indépendants. Le Farcaster ID Registry (FIR) émet de nouveaux numéros d'identification, appelés fids ; le Farcaster Name Registry (FNR) émet de nouveaux noms d'utilisateur, appelés fnames. Les Fids sont des identifiants sécurisés et décentralisés qui sont présents dans chaque message et sont conceptuellement similaires aux uuids.

Les noms FIR sont principalement destinés à la modification FIR, remplaçant fid lors du rendu, et peuvent être modifiés à tout moment. Séparer une identité en ces deux composants nous permet d’atteindre nos objectifs, mais au prix d’ajouter une certaine complexité au système. Les deux systèmes implémentent également un mécanisme de récupération qui protège la perte des paires de clés contrôlant les noms sans affecter la décentralisation.

Registre d'identification Farcaster (FIR)

Les identifiants Farcaster sont des identifiants numériques, similaires aux uuids. Lorsqu'ils seront affichés à l'utilisateur, ils seront précédés d'un point d'exclamation (par exemple : !8098).

Un FID représente une entité unique, telle qu'une personne ou une organisation. Chaque référence à cette entité doit utiliser son fid, et non son fname. Les frais d'inscription au FID sont très bas et il est détenu à vie. Les contrats FID ne peuvent en aucun cas être améliorés ou modifiés.

Le FID commence à 0 et est incrémenté de 1 à chaque nouvel enregistrement. Un fid est stocké sur la chaîne sous la forme d'un uint256, garantissant un approvisionnement quasi infini car il peut être incrémenté jusqu'à ~10^77.

Les utilisateurs peuvent utiliser FIR pour configurer les URL afin de trouver l'emplacement de leurs informations hors chaîne.

Registre des noms de Farcaster (FNR)

Les noms de Farcaster sont uniques, similaires aux noms d'utilisateur sur d'autres réseaux. Lorsqu'ils seront affichés à l'utilisateur, ils seront précédés d'un symbole @ (par exemple : @alice).

Fname, ainsi que les jetons de profil, de nom et de vérification, permettent d'identifier visuellement une entité lors de la navigation sur le Web. Contrairement aux fids, fname est principalement lisible et n'a rien à voir avec les données sous-jacentes créées par l'utilisateur. La propriété de fname n'est pas permanente et les utilisateurs doivent payer des frais annuels. Le renouvellement de fname peut être effectué 90 jours avant l’expiration de fname. Les noms expirés seront vendus aux enchères aux Pays-Bas, les enchérisseurs étant tenus de payer des frais annuels et une prime, à partir de 1 000 ETH. La prime diminue de 10 % toutes les 8 heures jusqu'à atteindre 0 ETH.

Les Fnames sont des NFT émis par le Farcaster Name Registry selon le principe du premier arrivé, premier servi. Chaque nom doit correspondre à l'expression régulière /^[a-z0-9][a-z0-9-]{0,15}$/. Ils ont des propriétés spécifiques qui les rendent plus utiles dans les réseaux sociaux par rapport à d'autres espaces de noms tels que ENS. Ils sont moins chers à créer et à posséder, sont moins sensibles aux attaques homophones en raison des limitations du jeu de caractères et sont également récupérables. Farcaster ne nécessite pas l'utilisation de fname, les utilisateurs sont libres d'utiliser d'autres espaces de noms et leurs fid.

Abandonner l'utilisation de fname n'aura pas beaucoup d'impact, car Farcaster est conçu autour de fid, et chaque information et comportement pointe vers fid plutôt que vers frame. Les fnames peuvent être modifiés à tout moment sans perdre les informations de dépendance précédentes.

Politique de nom d'utilisateur

Pendant la période bêta, les noms d'utilisateur peuvent être enregistrés gratuitement et sont soumis à une politique simple. Le but de cette politique est d'empêcher que des noms soient pris par des utilisateurs inactifs ou utilisés de manière malveillante pour usurper l'identité d'autrui. La solution à ce problème n’est pas facilement automatisée et nécessite un jugement humain pour être exécutée. La politique de nom d'utilisateur repose sur deux principes fondamentaux :

Usurpation d'identité - Si vous vous inscrivez sous un nom d'utilisateur appartenant à une personnalité ou une entité publique bien connue, votre nom peut être radié. Par exemple, @elonmusk, @vitalikbuterin, @google ou @whitehouse. Inactivité - Si vous n'avez pas utilisé activement un nom d'utilisateur pendant plus de 60 jours, votre nom peut être radié à la demande d'un autre utilisateur ou à notre discrétion.

Nous prévoyons qu'une intervention manuelle sera souvent nécessaire car il peut y avoir des conflits légitimes. Par exemple, vous avez enregistré @vitalik et Vitalik Buterin s'est inscrit après vous et souhaitait ce nom. Dans ce cas, nous posons trois questions pour guider la décision :

Cet utilisateur est-il actif et engagé sur Farcaster ? (Par exemple, s'ils ont publié des articles de haute qualité au cours des derniers mois.) Cet utilisateur a-t-il un droit légitime à ce nom ? (Par exemple, si son nom est également Vitalik) Cet utilisateur a-t-il des comptes actifs similaires sur d'autres réseaux ? (Par exemple, s'ils ont vitalik et vitalik.ens sur Twitter).

Si les réponses à ces questions sont majoritairement oui, ils conserveront le droit à leur nom. Dans le testnet, l'équipe principale arbitrera ce conflit, et nous espérons établir formellement un système de gestion autour de ce problème à mesure que nous nous rapprochons du réseau principal. Si un nom est retiré à la suite d'un arbitrage, les utilisateurs ne seront pas remboursés.

Récupération de compte

Si un utilisateur perd la clé de l'adresse contenant l'ID et le nom, l'ID et le nom Farcaster sont récupérables. Les deux contrats mettent en œuvre un système de récupération différée qui permet de transférer les demandes d'adresse de récupération vers une nouvelle adresse. Si l'adresse de garde n'annule pas le transfert dans les trois jours, l'adresse de récupération peut finaliser le transfert.

Les utilisateurs peuvent définir l'adresse de récupération sur une autre adresse de leur propre portefeuille, un multisig partagé avec des amis ou un service de récupération tiers. Les utilisateurs peuvent également modifier l'adresse de récupération à tout moment. La propriété reste décentralisée car l'adresse de récupération ne peut pas effectuer de transferts que l'adresse de garde n'accepte pas.

Le transfert d'actifs vers une nouvelle adresse séquestre supprimera l'adresse de récupération. Sinon, un utilisateur pourrait acheter un nom sur OpenSea, pour ensuite que l'ancien propriétaire le récupère secrètement en utilisant son adresse de récupération.

traitement de l'information

Le traitement de l'information est le processus par lequel le Hub accepte de nouveaux messages et détermine le statut de l'utilisateur. Les utilisateurs envoient des messages à un Hub pour chacune de leurs actions. Si un utilisateur aime une URL, ne l'aime pas et l'aime, trois messages seront générés. Un Hub qui reçoit toutes les informations déterminera l'état actuel des URL préférées de l'utilisateur.

Hub peut supprimer les deux premières informations pour économiser de l'espace. Le Hub peut compresser ces messages à l'aide d'une opération de fusion, ce qui évite les incohérences côté client et économise de l'espace. Les messages peuvent avoir des règles différentes pour leurs opérations de fusion. Par exemple, deux likes d'un utilisateur au même utilisateur peuvent être compressés en un seul, mais pas deux réponses.

Le Hub peut perdre certaines informations de l'utilisateur et se retrouver dans un état d'erreur. Par exemple, il peut recevoir uniquement le premier message J'aime et Je n'aime pas, ce qui définit le statut actuel sur Je n'aime pas. L’opération de fusion doit permettre à l’État d’avancer et d’atteindre une cohérence au fur et à mesure de la rediffusion des messages manquants. En d’autres termes, la fusion devrait finalement garantir une forte cohérence.

Hub y parvient en implémentant un ensemble de CRDT pour chaque type de message, codant des règles de validation et de fusion spécifiques. Cette fonctionnalité rend les Hubs hautement disponibles, car ils peuvent être mis hors ligne à tout moment et peuvent toujours être restaurés pour être synchronisés. Formellement, notre ensemble CRDT est un CRDT2 anonyme à état delta, et chaque message est une mise à jour connectée et irréductible sur l'ensemble.

Tri des informations

La collecte d'informations peut trier les informations de signature par horodatage et résoudre les conflits de fusion avec une stratégie écrite en dernier lieu. Cependant, ils ne peuvent pas garantir un ordre parfait, car les horodatages sont susceptibles de subir des décalages d'horloge, des dérives d'horloge, une usurpation d'identité par des utilisateurs malveillants et peuvent entrer en collision pour un certain nombre de raisons. Les applications peuvent utiliser des horloges mixtes pour produire des horodatages parfaitement ordonnés sans collisions, mais nous ne pouvons pas forcer leur utilisation.

Au lieu de cela, nous définissons un système de classement pour les messages qui garantit un classement total en utilisant des horodatages pour déterminer l'ordre initial et des hachages pour briser les collisions. L'ordre total est garanti car deux messages ne peuvent pas avoir la même valeur de hachage à moins qu'il ne s'agisse du même message. Deux messages a et b peuvent être comparés à l'aide de cet algorithme :

Si a.timestamp>b.timestamp, alors a est supérieur. Si a.timestamp < b.timestamp, alors b est supérieur. si a.timestamp == b.timestamp

- Si a.hash>b.hash, alors a est plus grand.

- Si a.hash < b.hash, alors b est supérieur.

        - 如果a.hash = b.hash，a == b

Les horodatages sont comparés sous forme de nombres, tandis que les hachages sont comparés sous forme de chaînes. Étant donné que les comparaisons de chaînes varient selon les implémentations, nous devons être précis dans nos algorithmes de comparaison. Nous pensons que deux valeurs de hachage x et y peuvent être comparées en comparant chaque paire de caractères :

Si toutes les paires de caractères sont égales et que x et y se terminent tous deux, alors x == y Si toutes les paires de caractères sont égales et que x se termine en premier, alors y>x Si une paire de caractères différente xC, yC est rencontrée, alors Si ASCII( yC)>ASCII(xC), puis y>x

Vérification des informations

En plus des validations spécifiques au type de message, tous les messages doivent réussir les validations suivantes :

message.timestamp n’a pas plus d’une heure d’avance sur l’heure du système. message.fid doit être un numéro fid connu dans le FIR. signerPubKey doit être un signataire géré valide ou une signature déléguée pour message.fid hashFn(serializeFn(message)) doit correspondre à enveloppe.hash, où hashFn est une fonction Blake2B et SerializeFn effectue la normalisation JSON. EdDSA_signature_verify(envelope.hash, enveloppe.signerPubKey, enveloppe.signature) devrait réussir.

Moulages

Cast est une information publique créée par les utilisateurs, qui contient du texte et peut également être intégrée dans des médias, des activités en chaîne ou d'autres Cast. Les casts sont stockés dans une collection CRDT3 en deux étapes pour résoudre les conflits entre les messages.

Un Cast peut être ajouté via le message CastAdd, qui est placé dans l'add-set du CRDT. Chaque Cast est indexé par sa valeur de hachage, qui est garantie unique sauf si les Casts sont identiques. Par extension, deux messages d'ajout ne seront jamais en conflit à moins qu'ils ne soient identiques, auquel cas l'un d'entre eux peut être supprimé en toute sécurité.

Les diffusions peuvent être supprimées via le message CastRemove, qui contient une référence au hachage du CastAdd cible. Lorsque ce message est reçu, la cible est supprimée de l'ensemble d'ajouts si elle existe, et celle supprimée est ajoutée au jeu rem. Les conflits entre ajouts et suppressions sont gérés avec la règle Remove-Wins, tandis que les conflits entre suppressions sont gérés avec la règle Last-Write-Wins, en revenant à l'ordre lexicographique en cas d'égalité.

Ajouter des informations

Un Cast Add peut contenir du texte Unicode de 320 caractères maximum et deux URI de 256 caractères maximum. Le client est responsable du décodage et du rendu de l'URI et du texte ensemble.

Une distribution sans parent est une distribution de niveau supérieur et le client doit apparaître sur le profil ou la chronologie de l'utilisateur. Une diffusion parentale est une réponse à une autre diffusion, une URL Web ou un objet en chaîne et doit être affichée dans un fil de discussion.

Les votes forment une série d'arbres, où chaque racine est un vote ou URI et chaque nœud enfant est un vote de réponse. Chaque arbre peut être rendu sous forme de conversation en fil de discussion. L'arborescence est garantie apériodique car le nœud parent doit être haché et signé avant qu'un nœud enfant puisse pointer vers lui. Toute modification apportée aux données du nœud parent détruira toutes les relations avec ses nœuds enfants.

Les informations de diffusion doivent passer les étapes de vérification suivantes.

Le texte doit contenir <=320 caractères Unicode valides. L'intégration doit contenir 0 à 2 éléments. Les éléments doivent être un URI de 256 caractères maximum. Si un parent est présent, il doit s'agir d'un URI valide, différent de l'URI de ce message (par exemple, fid:/cast:).

Supprimer les informations

Cast Remove contient simplement une référence au hachage de Cast Add. Il permet la suppression définitive du Cast tout en supprimant les données du Cast original.

Le message doit passer les étapes de vérification suivantes :

message.data.body.hash ne doit pas être égal à message.envelope.hash. message.timestamp doit être <= horloge système + 10 minutes message.data.fid doit être un fid connu dans le FIR

règles de fusion

Lorsqu'un message d'ajout a est reçu, si r existe dans le rem-set et que r.data.body.hash est égal à a.hash, supprimez a. Sinon, ajoutez a à l'ensemble d'addition. Lorsqu'un message de suppression r est reçu, s'il y a un.hash égal à r.data.body.hash dans l'ensemble ajouté, supprimez-le. S'il y a un r' dans rem-set, où r.data.body.hash est égal à r'.data.body.hash, si r'>r, jetez r' si r' ;

Actes

L'action est une opération publique effectuée par un utilisateur sur une cible, qui peut être un autre utilisateur ou une activité en chaîne. Actuellement, deux types d'actions sont pris en charge : aimer et suivre. Le protocole peut être facilement étendu pour prendre en charge de nouvelles actions. Les utilisateurs peuvent annuler et refaire des actions en activant l'attribut d'activité sur le message. Conceptuellement, chaque action constitue un avantage dans le graphe social.

L'action est gérée à l'aide de LWW-Element-Set CRDT, qui garantit une cohérence éventuelle. Conceptuellement, il existe une collection unique qui stocke tous les messages, et les conflits sont résolus via des horodatages et un ordre de hachage lexicographique. L'ajout est effectué en construisant un message d'action a avec active défini sur true, tandis que la suppression est effectuée en définissant active sur false. Dans les deux cas, la logique de fusion des messages en ensembles est la suivante :

S'il y a une action x dans la collection, son type, son Uri cible et ses valeurs fid sont les mêmes que l'action entrante y. Si x>y, rejetez y ;

vérifier

La vérification est une preuve de propriété bidirectionnelle entre un compte Farcaster et une entité externe. La vérification peut être utilisée pour prouver la propriété d'adresses Ethereum, de NFT spécifiques, d'autres comptes de réseaux sociaux et même de noms de domaine.

Il existe trois concepts fondamentaux en matière de vérification :

Déclarations, y compris des références aux comptes Farcaster et aux entités externes. Les revendications peuvent être hachées pour créer un identifiant unique pour chaque revendication. Preuve de directionnalité d'une entité externe autorisée à faire la demande montrant son intention de se connecter au compte Farcaster. Preuve de directionnalité d'un compte Farcaster pour accepter les demandes d'association d'une réclamation à un compte Farcaster.

Autorisation du signataire

Une autorisation de signataire est un message autorisant une nouvelle paire de clés à générer des signatures pour un compte Farcaster.

Lorsqu'un fid est créé, seule l'adresse de garde peut signer des messages en son nom. Les utilisateurs ne souhaiteront peut-être pas charger cette paire de clés sur chaque appareil, car cela augmente le risque de compromission du compte. Une adresse de garde, également appelée signataire dépositaire, peut autoriser les paires de clés d'autres signataires délégués. Contrairement aux signataires réglementaires, les signataires délégués sont uniquement autorisés à publier des informations hors chaîne et ne peuvent effectuer aucune opération en chaîne.

Les signataires Escrow génèrent des signatures ECDSA sur la courbe secp256k1 et peuvent uniquement publier les informations d'autorisation du signataire. Tous les autres types de messages doivent être signés par un signataire délégué qui crée la signature EdDSA sur la courbe255194. Les signataires délégués peuvent être utilisés pour autoriser de nouveaux appareils ou même des services tiers à signer des messages pour un compte. Si un signataire délégué est compromis, il peut être révoqué par lui-même, par ses ancêtres dans la chaîne de confiance ou par tout signataire délégué. Lorsqu'un signataire est révoqué, Hubs supprime toutes ses informations de signature car il n'existe aucun moyen de distinguer les informations de l'utilisateur de celles de l'attaquant.

Les utilisateurs peuvent également transférer un identifiant vers une nouvelle adresse de dépôt en raison d'une récupération de clé ou d'un changement de portefeuille. Il est souvent souhaitable de conserver l'historique afin que les deux adresses de dépôt fiduciaire deviennent des signataires de dépôt fiduciaire valides. L'ensemble des signataires valides pour un identifiant forme une série d'arbres différents. La racine de chaque arbre est une adresse de garde historique et les feuilles sont des signataires délégués.

L'ensemble de signataires est un ensemble modifié en deux phases avec une sémantique de suppression-gagnant et de dernière-écriture-gagnant. De nouvelles informations sont ajoutées à la collection si elles sont signées par un directeur ou un tuteur valide. Les suppressions sont acceptées si elles sont signées par vous-même ou par un ancêtre. Une fois qu'un signataire est supprimé, il ne peut pas être ajouté et tous ses descendants et messages sont supprimés.

Si deux signataires valides autorisent respectivement le même signataire délégué, un conflit d'ensemble se produit, qui détruit la structure arborescente des données. Si cela se produit, la collection conservera dans l’ordre le message avec l’horodatage et le hachage lexicographique les plus élevés.

Partage

Les hubs peuvent copier uniquement les données de comptes spécifiques, ce qui constitue une propriété utile pour faire évoluer les réseaux. Si Farcaster devient suffisamment grand pour qu'un seul serveur ne puisse pas prendre en charge la réplication de l'intégralité du réseau de hubs, la charge de travail peut être répartie sur plusieurs hubs. Les opérateurs de hub peuvent également éviter de synchroniser les données des utilisateurs qui se comportent de manière malveillante ou ne sont pas affiliés à l'opérateur.

La réplication sélective ne fournit qu'une vue partielle du réseau. Si un Hub synchronise les données d'Alice, il saura qu'elle a répondu et aimé l'un des messages de Bob. Cependant, il ne connaîtra pas le contenu du message de Bob, ni le fait que Bob a aimé sa réponse et a ensuite continué à répondre. Une application qui vise à fournir un nombre précis de likes et à fournir toutes les informations de réponse doit reproduire autant d'utilisateurs que possible.