# Protocole Jiyu : fonctionnement conceptuel > Ce document explique le **fonctionnement** du protocole : comment les concepts > s'articulent et ce qui se passe à chaque étape de la vie d'une place. Les décisions > normatives (axiomes, paramètres, maturité des mécanismes) sont dans > [project.md](./project.md) §1 ; la stack et les transports dans les §2-7. --- ## 1. Vue d'ensemble Jiyu est un réseau social décentralisé où **tout est une place** : une communauté publique, un petit groupe privé et un DM sont le même objet, à des tailles différentes. Une place est simultanément : - une **unité de contenu** (des rooms contenant des posts), - une **unité de gouvernance** (des tokens répartis entre ses membres), - une **unité cryptographique** (ses propres clés, son propre pseudonymat), - une **unité de réplication** (ses membres portent ses données). Il n'existe ni serveur central, ni annuaire, ni identité globale visible. Le réseau fonctionne avec ou sans Internet : les données se propagent de membre en membre par le meilleur transport disponible (Internet, LAN, BLE, ultrasons…). ```mermaid graph TD U[User] -->|possède 1..N| N[Node / appareil physique] U -->|un pseudonyme distinct par place| P[Place] P -->|contient| R[Rooms] R -->|contiennent| PO[Posts texte] PO --> RE[Réactions emoji] P -->|gouvernée par| T[Tokens] P -->|protégée par| K[Deux clés : découverte + messages] ``` --- ## 2. Identité et pseudonymat Chaque user détient une **identité maîtresse** (paire de clés) qui n'apparaît jamais sur le réseau. Tout ce que les autres voient est **dérivé** : - **Pseudonyme par place** : dérivation déterministe (identité maîtresse + ID de la place). Il est stable au sein d'une place (le même user y revient toujours sous le même pseudonyme, ce qui rend la blacklist d'exclusion effective), mais **incorrélable entre places** : rien ne relie vos pseudonymes de deux places différentes. - **Multi-device** : tous les appareils d'un user partagent l'identité maîtresse. Rejoindre une place depuis un appareil donne l'accès à tous. - **Récupération** : la perte de tous les appareils vaut perte de l'identité, sauf backup personnel chiffré (le backup et sa passphrase sont tous deux requis pour restaurer ; le réseau, lui, ne restaure jamais rien). ```mermaid graph TD M[Identité maîtresse<br/>jamais visible sur le réseau] --> D1[Appareil 1] M --> D2[Appareil 2] M -->|dérivation avec ID place A| PA[Pseudonyme dans A] M -->|dérivation avec ID place B| PB[Pseudonyme dans B] PA -.incorrélables.- PB M --> BK[Backup chiffré<br/>+ passphrase hors-ligne] ``` --- ## 3. Les deux clés d'une place | Clé | Nature | Rôle | Qui l'a | | --- | --- | --- | --- | | **Secret de découverte** | Stable (rotatable par le top holder) | Calculer les tags d'époque, trouver la place, prouver qu'on a une invitation | Toute personne ayant eu un QR | | **Clés de message** | Rotation périodique | Chiffrer le contenu | Membres actuels uniquement | Cette séparation fait fonctionner à la fois le QR statique (imprimable et diffusable, car il contient le secret de découverte) et l'exclusion (qui ne touche que les clés de message). Conséquence assumée : un exclu ou le détenteur d'un QR fuité peut encore *suivre l'activité* de la place (tags), sans plus rien lire. Si c'est un problème, le top holder fait tourner le secret de découverte : tous les QR en circulation deviennent caducs. ### Rotation des clés de message ```mermaid sequenceDiagram participant P as Clés de message de la place Note over P: génération k en cours P->>P: rotation périodique → génération k+1 P->>P: exclusion ou révocation d'appareil → rotation immédiate → k+2 Note over P: partition réseau : deux lignées divergentes k+3a et k+3b P->>P: fusion des partitions → re-rotation automatique → k+4 ``` La rotation est **périodique** ; une exclusion ou une révocation d'appareil avance simplement le timer à maintenant (un seul mécanisme, aucune fenêtre où l'exclu lit encore). La distribution des nouvelles clés suit un schéma type MLS/TreeKEM (coût O(log N)). Deux lignées divergentes créées en partition déclenchent une re-rotation à la fusion, car re-chiffrer en trop est toujours sûr. --- ## 4. Cycle de vie d'un membre ```mermaid stateDiagram-v2 [*] --> Invite : scan d'un QR ou invitation directe Invite --> Membre : join, pseudonyme dérivé, 0 token Membre --> Membre : posts, réactions, réception ou envoi de tokens Membre --> Parti : départ volontaire, tokens brûlés Membre --> Sequestre : exclusion, tokens sous séquestre Sequestre --> Membre : réintégration sous T par un détenteur supérieur Sequestre --> Banni : délai T écoulé, brûlage définitif et blacklist Parti --> Invite : peut revenir librement Banni --> [*] : même pseudonyme bloqué à vie ``` ### Rejoindre une place ```mermaid sequenceDiagram participant N as Nouvel arrivant participant M as Un membre joignable N->>N: scan du QR, qui contient le secret de découverte et la signature de l'inviteur N->>M: contact via le tag d'époque courant M->>M: vérifie blacklist, throttle de joins, validité du QR M->>N: chaîne des clés de message + accès à l'historique N->>M: join signé du pseudonyme dérivé M->>M: inscription dans l'arbre comme enfant de l'émetteur du QR ``` - Le **QR est une invitation signée par un membre précis** ; l'arrivant devient son enfant dans l'arbre de cooptation. Un QR peut circuler publiquement (place ouverte) ou rester privé (petit groupe). - L'arrivant a **accès à tout l'historique** (droit de récupération, pas obligation de tout stocker). - Les joins sont **throttlés** par QR et par époque (anti-botnet) ; l'émetteur peut **invalider** son QR à tout moment (sans effet sur ceux déjà entrés). - Un **DM** est une place à deux membres, créée par **invitation directe** : un payload scellé (illisible des autres) envoyé à un pseudonyme rencontré dans une place commune. TTL des deux côtés ; refus ou silence → la place s'auto-supprime. Chaque user peut désactiver les invitations entrantes. --- ## 5. Gouvernance par tokens Chaque place a une **offre fixe** de tokens (fractionnables en 10⁸ unités). Le créateur part avec 100 % et distribue comme il l'entend, les tokens étant transférables entre membres. Le pouvoir est strictement relatif au solde : | Pouvoir | Condition | | --- | --- | | Lire, poster, réagir, inviter | Être membre (0 token suffit) | | Exclure quelqu'un | Détenir **strictement plus** que la cible | | Réintégrer un exclu | Détenir strictement plus que l'excluant | | Créer/supprimer des rooms, éditer nom/description, faire tourner le secret de découverte | Être le (ou l'un des) plus gros détenteur(s) | L'égalité fige : deux détenteurs à égalité ne peuvent pas s'exclure mutuellement (statu quo assumé : l'exit des membres est le régulateur ultime d'une mauvaise gouvernance). ### L'arbre de cooptation et la cascade Chaque membre est l'enfant de qui l'a invité. L'exclusion emporte **toute la branche** de l'exclu (à la Lobsters), moins le sous-arbre de l'excluant s'il en fait partie (re-parenté au parent de l'exclu, pas d'auto-exclusion paradoxale). Un départ volontaire ne cascade pas : les enfants sont re-parentés au grand-parent. ```mermaid graph TD C[Créateur · 55] --> A[Alice · 30] C --> B[Bob · 10] A --> E[Eve · 5] A --> D[Dave · 0] E --> F[Fred · 0] B --> G[Gus · 0] style E fill:#c62828,color:#fff style F fill:#c62828,color:#fff ``` *Exemple : Bob (10) exclut Eve (5) → Eve et Fred (sa branche) sortent, leurs tokens passent sous séquestre. Alice (30 > 10) peut les réintégrer pendant T ; sinon brûlage.* ### Pourquoi brûler les tokens Les tokens des partants et des exclus sont **brûlés** : les ratios entre les membres restants sont mathématiquement inchangés, donc **personne ne gagne rien à exclure** ; la purge n'a aucune incitation économique. Le séquestre de T jours avant brûlage définitif est la fenêtre de recours ; toutes les exclusions sont des événements auditables du log. --- ## 6. Le registre : une mini-blockchain par place Le contenu (posts) fusionne sans conflit (CRDT). Les opérations de gouvernance (transferts, exclusions), elles, exigent un ordre : c'est le rôle du registre. - Chaque opération = un **bloc signé** par son auteur, chaîné par hash (~200-300 o). - **Finalité** = contre-signatures de détenteurs représentant **plus de 50 % des tokens en circulation**. Les validateurs *sont* les détenteurs : pas de mineurs, pas de chaîne globale. Dans un DM, le quorum c'est les deux membres. - Un double-spend est une fourche signée du même compte : détectée mécaniquement à la fusion, résolue par premier-finalisé-gagne. - En partition sans quorum, les opérations **attendent** (le contenu, lui, circule). Une exclusion ne s'appuie que sur des soldes finalisés. - **Dormance** : un détenteur muet depuis 90 jours sort du dénominateur du quorum (il garde ses tokens et réintègre le quorum à sa première signature) : un disparu ne peut pas geler une place. ```mermaid sequenceDiagram participant A as Alice · 30 pct participant B as Bob · 25 pct participant C as Carol · 45 pct A->>A: bloc signé, transfert de 10 tokens vers Bob A-->>B: propagation du bloc A-->>C: propagation du bloc B->>A: contre-signature, 30 + 25 = 55 pct Note over A,B: seuil de 50 pct franchi → transfert FINALISÉ C-->>A: contre-signature tardive, redondante ``` --- ## 7. Propagation : de membre en membre, avec des couriers Le contenu d'une place ne transite **que par ses membres** (modèle Briar) : un relais connaît déjà la place, donc aucune fuite et aucun déchiffrement d'essai. Le routage suit le graphe social, pas une table d'adresses. Le **pseudonymat de place** rend ça routable sans rien révéler : chaque époque, la place a un **tag** dérivé du secret de découverte, recalculable par les membres, opaque pour les autres, incorrélable d'une époque à l'autre. Les nodes annoncent à leurs voisins les tags qu'ils portent ou cherchent (pub/sub). Pour combler les trous géographiques, un non-membre peut devenir **courier** : les membres lui remettent un laissez-passer de k époques de tags, et il porte des bundles chiffrés qu'il ne peut pas lire. Le mode courier est **activé par défaut** : utiliser le réseau, c'est le soutenir. ```mermaid graph LR subgraph Quartier 1 A[Membre A] ---|sync directe| B[Membre B] end subgraph Quartier 2 D[Membre D] ---|sync directe| E[Membre E] end B ---|laissez-passer k époques| K[Courier non-membre<br/>porte sans lire] K --- D A -.Internet quand disponible.- E ``` - **Internet** : abolit la distance quand il existe. Des serveurs de rendez-vous **fédérés et optionnels** (n'importe qui peut en héberger) facilitent la mise en relation ; le réseau n'en dépend jamais : si Internet disparaît, tout continue de proche en proche. Les PWA ont besoin d'un natif ou d'un serveur pour entrer ; un natif coupé d'Internet peut inversement passer par une PWA connectée (le pont marche dans les deux sens). - **Anti-spam** : seuls les membres injectent du contenu dans une place (un spammeur est un membre, donc excluable) ; le volume relayé est borné par des quotas par lien de voisinage. - **Temps** : les époques supposent des horloges vaguement justes, d'où une tolérance de ±1-2 époques et un gossip d'horloge à chaque rencontre (médiane des contacts récents). --- ## 8. Qui voit quoi | Observateur | Contenu | Existence de la place | Activité (tags) | Membres | | --- | --- | --- | --- | --- | | **Membre** | Tout (+ historique) | Oui | Oui | Pseudonymes de tous | | **Courier** | Rien | Non, juste un tag opaque | Volume/timing sur k époques | Non | | **Voisin réseau** | Rien | Non | Annonces de tags opaques | Non | | **Détenteur d'un QR non entré** | Rien | Oui | Oui (calcule les tags) | Non | | **Exclu** | Son ancienne copie, rien de neuf | Oui | Oui, jusqu'à rotation du secret de découverte | Ceux qu'il connaissait | | **Inconnu** | Rien | Non | Non | Non | --- ## 9. Limites assumées - **Pas d'effacement cryptographique** : la suppression de posts, les tombstones et la mort d'une place sont des conventions respectées par les clients honnêtes ; quiconque a déjà copié des données peut les conserver. - **Lire n'est pas anonyme** : rejoindre une place expose son pseudonyme aux autres membres (parité Discord). - **L'évasion de ban** exige une identité maîtresse neuve (parité Discord). - **Les tags fuient** volume et timing par époque, et le co-abonnement entre voisins. - **La gouvernance gèle sans quorum** (partitions longues) ; le contenu, lui, ne gèle jamais. - **La PWA fait confiance à son serveur d'origine** pour le code qu'elle exécute. - La **gouvernance par tokens** est un système social expérimental. Le protocole garantit que les règles (transferts, exclusions, quorums) s'appliquent correctement, mais il ne garantit pas que les détenteurs de tokens gouverneront intelligemment ou équitablement. Face à une mauvaise gouvernance, la protection des membres reste la même que dans la vraie vie : quitter la place et aller ailleurs.