« Dans les communautés humaines, les relations survivent grâce à la réciprocité. Tu te souviens de mes histoires ; je me souviens des tiennes. Les relations à sens unique se dégradent. »

Le protocole formalise cela sous forme de pactes de stockage : des accords bilatéraux où les deux parties stockent les événements de l'autre, équilibrés en volume de données à 30 % près. Un auteur prolifique associé à un lecteur silencieux crée une obligation asymétrique qui incite à la défection — tout comme les amitiés asymétriques se dégradent dans les réseaux sociaux réels.

« La réputation humaine n'est pas un nombre. C'est l'agrégat des comportements observés, pondéré par la confiance de l'observateur en chaque source. »

Chaque nœud maintient des scores de fiabilité par pair sur une fenêtre glissante de 30 jours de résultats défi-réponse. Les scores sont privés — chaque nœud calcule sa propre évaluation. Il n'y a pas de score de réputation global. La topologie du réseau est la structure d'incitation.

« Chaque communauté a ses patrons — des membres établis qui se portent garants de nouveaux venus qu'ils ne connaissent pas personnellement. »

Le protocole formalise cela sous forme de pactes Guardian : un utilisateur établi stocke volontairement les données d'un nouveau venu non reconnu par son Web of Trust. Le cadrage « donnant-donnant différé » est délibéré : la graine d'aujourd'hui sera le Guardian de demain.

« Dans une communauté, tout le monde n'est pas également présent. Certains amis sont toujours là — ils se souviennent de tout, ce sont les premiers qu'on appelle. D'autres vont et viennent, mais ils comptent tout autant. »

Cette variance naturelle se projette directement sur les deux types de nœuds du protocole. Les Keepers — nœuds complets — sont les amis toujours disponibles : un ordinateur de bureau laissé allumé, un serveur domestique, un petit VPS. Ils stockent l'intégralité de votre historique et doivent être en ligne 95 % du temps. Environ 25 % des participants endossent naturellement ce rôle — des personnes qui disposent déjà de matériel connecté en permanence. Les Witnesses — nœuds légers — sont les amis qui donnent des nouvelles quand ils peuvent : un téléphone qui se synchronise à l'ouverture, un ordinateur portable utilisé quelques heures par jour. Ils conservent vos 30 derniers jours et sont attendus en ligne 30 % du temps. Le protocole n'impose aucun rôle. Il observe le temps de fonctionnement de votre appareil et classe automatiquement : 90 % et plus devient Keeper, en dessous devient Witness. Tout comme les cercles sociaux s'organisent autour des disponibilités naturelles de chacun, la topologie de stockage du réseau émerge de la façon dont les gens utilisent réellement leurs appareils.

Pactes de stockage

Un pacte de stockage est un accord bilatéral entre deux nœuds pour stocker mutuellement leurs événements. La formation suit une négociation en trois phases : Requête, Offre, Acceptation. Les partenaires de pacte sont vérifiés par des échanges périodiques de défi-réponse — les défis de hachage prouvent la possession sans transférer les événements complets. Chaque nœud maintient 20 pactes actifs et 3 pactes en attente pour un basculement instantané.

Récupération par niveaux

Quand un nœud doit récupérer les événements d'un auteur suivi, le protocole tente la livraison à travers une cascade de chemins de coût croissant : maillage BLE (proximité, sans internet), cache local (coût zéro), cached endpoints (~60ms), gossip WoT avec requêtes masquées (TTL=3), et enfin les relais en dernier recours. Chaque niveau n'est tenté que si le précédent échoue, créant un gradient de coût naturel qui maintient la majeure partie du trafic au sein du graphe social.

Routage par gossip

La transmission filtrée par WoT du protocole reproduit la façon dont les humains partagent sélectivement : les partenaires de pacte actifs ont la priorité la plus haute, puis les pairs à 1 saut dans le WoT, puis ceux à 2 sauts si la capacité le permet. Les sources inconnues ne sont jamais relayées — les ragots des inconnus s'arrêtent à votre porte. Les requêtes de données utilisent des clés publiques masquées à rotation quotidienne, de sorte que les pairs de stockage savent que quelqu'un a demandé des données, mais pas qui.

Synchronisation multi-appareils sans partage de clés

Chaque appareil reçoit sa propre sous-clé, déléguée depuis votre identité racine. Votre téléphone, votre ordinateur portable et votre extension navigateur signent tous les événements de manière indépendante — pas de copie de clé privée, pas de point de compromission unique. Lorsque les appareils se reconnectent, ils se synchronisent via des points de contrôle : une preuve Merkle légère attestant que chaque appareil a bien vu les derniers événements des autres. La résolution des conflits est automatique. Si deux appareils modifient votre profil simultanément, les champs fusionnent par horodatage le plus récent. Les listes d'abonnements fusionnent par opérations ensemblistes. Les événements s'enchaînent par numéros de séquence propres à chaque appareil, rendant la rétention et la réorganisation détectables en temps réel.

Chiffrement avec hiérarchie de clés dédiée

Votre clé racine reste à froid — dans un portefeuille matériel ou une machine isolée du réseau. À partir d'elle, le protocole dérive des clés à usage spécifique : des clés d'appareil pour les événements quotidiens, une clé DM pour les messages chiffrés, et une clé de gouvernance pour les modifications de profil et d'abonnements. La clé DM effectue une rotation tous les 90 jours pour une confidentialité persistante limitée. Chaque appareil n'a pas besoin d'accéder aux DM — votre ordinateur et votre téléphone peuvent déchiffrer les messages, tandis que votre extension navigateur se contente de publier. Si un appareil est compromis, révoquez sa sous-clé. Votre identité, vos DM, votre graphe social : intacts.

Données portables entre protocoles

Chaque événement est auto-authentifiant — signé par les clés de l'auteur, vérifiable par quiconque. Cela rend le pontage inter-protocoles simple : les événements Nostr se convertissent en activités ActivityPub pour Mastodon, en enregistrements AT Protocol pour Bluesky, et en flux RSS/Atom pour la syndication. Votre identité fait le pont via des attestations signées reliant votre clé publique secp256k1 aux URI d'acteur ActivityPub ou aux DID AT Protocol. Vous pouvez exporter l'intégralité de votre historique sous forme d'archive signée — inviolable, importable dans tout client compatible.

Modèle de flux à trois niveaux

Toutes les relations ne se valent pas, et le protocole le sait. Votre Cercle Intime — les abonnements mutuels avec pactes actifs — bénéficie d'une livraison continue en temps réel. Votre Orbite — les auteurs avec lesquels vous interagissez fréquemment et les découvertes recommandées socialement — fait l'objet d'un sondage périodique. Votre Horizon — le graphe à 2 sauts et les découvertes via relais — est interrogé à la demande. Les niveaux émergent de votre comportement social réel : répondez, repartagez et réagissez suffisamment aux publications de quelqu'un, et cette personne se rapproche. Cessez d'interagir, et elle s'éloigne. Aucun algorithme ne décide à votre place. C'est votre attention qui décide.

Récupération sociale

Vous perdez votre clé racine ? Désignez des contacts de récupération parmi votre Web of Trust. Si le pire survient, la vérification à seuil N-sur-M entre en jeu : vos contacts vérifient votre identité hors bande, publient des attestations de récupération, et après un délai de sécurité de 7 jours — laissant au propriétaire légitime le temps d'annuler — votre nouvelle clé prend le relais. Pas de phrase de récupération à oublier. Pas de service de récupération centralisé. Juste les personnes qui vous connaissent.

Compléter Nostr

Nostr a apporté au monde décentralisé quelque chose de fondamental : un protocole simple à base de relais où l'identité est une paire de clés et les événements sont auto-authentifiants. Mais le modèle de relais de Nostr implique que vos données vivent sur des serveurs que vous ne contrôlez pas, sans garantie de persistance. Gozzip ajoute la couche de stockage : des pactes bilatéraux entre pairs qui se connaissent, vérifiés par des défis cryptographiques, avec une réciprocité équilibrée en volume. Votre identité Nostr fonctionne directement — mêmes clés secp256k1, même format d'événement. Gozzip ne forke pas Nostr. Il offre aux utilisateurs de Nostr un moyen de posséder leurs données sans dépendre des opérateurs de relais.

Compléter BitChat

BitChat résout un problème différent : la messagerie chiffrée pair-à-pair sur Bluetooth Low Energy, avec des poignées de main Noise Protocol, un cadrage binaire compact et un relais multi-sauts jusqu'à 7 appareils. Il excelle comme couche maillée temps réel — éphémère, locale, conçue pour les situations où il n'y a pas d'internet. Gozzip ajoute la persistance par-dessus : des pactes de stockage qui maintiennent vos données en vie quand vous vous déconnectez, un Web of Trust qui filtre ce qui se propage, et un graphe social qui sert d'infrastructure à long terme. BitChat gère « envoyer un message à quelqu'un de proche, maintenant. » Gozzip gère « posséder sa vie sociale de manière permanente. » Ensemble, ils forment une pile complète, du signal radio Bluetooth au réseau social souverain.

Ce que Scuttlebutt a bien fait — et où il s'est arrêté

Secure Scuttlebutt a été le pionnier de l'idée que les réseaux sociaux pouvaient fonctionner sur du gossip pair-à-pair sans serveurs centralisés. Gozzip a une dette conceptuelle envers ce travail. Mais les architectures divergent sur trois points critiques. Premièrement, l'identité : SSB lie les flux ed25519 à un seul appareil — perdez l'appareil, perdez l'identité. Gozzip utilise secp256k1 avec une hiérarchie de délégation, de sorte que votre clé racine reste à froid tandis que des sous-clés d'appareil gèrent les opérations quotidiennes. Deuxièmement, la réplication : les serveurs pub SSB répliquent les données de manière unilatérale — ils stockent ce qu'ils veulent, pour qui ils veulent, sans obligation. Gozzip impose des pactes de stockage bilatéraux avec des défis de preuve de possession, rendant le parasitage structurellement impossible. Troisièmement, les limites du gossip : SSB n'a pas de frontière de confiance explicite — le gossip se propage indéfiniment à travers le réseau. Gozzip restreint la retransmission à un Web of Trust à 2 sauts, empêchant la croissance non bornée des données qui a fait s'effondrer les pubs SSB sous leur propre poids.

Résilience d'urgence

L'intégration avec BitChat permet également l'effacement d'urgence : un déclencheur configurable — triple appui, geste, ou code PIN leurre — qui détruit toutes les clés locales, les événements en cache et l'état de l'application. Vos données publiées survivent chez vos partenaires de pacte et sur les relais. Votre identité survit en stockage à froid. La récupération se résume à : accéder à la clé racine, publier une nouvelle délégation d'appareil, récupérer les données auprès des pairs de stockage, et vous revoilà. Le mode leurre optionnel efface vers un profil anodin. L'adversaire voit une application normale avec du contenu inoffensif.

FIPS : au-delà de la couche transport

BitChat prouve que le transport maillé fonctionne localement. FIPS (Free Internetworking Peering System) étend le principe à tout type de réseau : un transport routé par identité où votre clé publique est votre adresse réseau. Pas de DNS, pas d'IP statiques, pas de casse-tête de traversée NAT. Un partenaire de pacte de stockage est simultanément un pair de routage maillé. Les sessions survivent aux changements de transport — du WiFi au cellulaire au BLE — sans coupure. Une fois que le graphe social est l'infrastructure de stockage et que le réseau de confiance est le système de livraison, la dernière dépendance restante est le système d'adressage. FIPS l'élimine aussi.