# 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
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é
+ 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
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.