Groupes décentralisés : le cauchemar technique que personne n'ose mentionner

Le rôle oublié du serveur

Quand tu utilises Signal, WhatsApp ou Matrix, tu crois faire du chiffrement bout-à-bout pur. Techniquement, oui — tes messages sont verrouillés. Mais le serveur ? Il gère tranquillement trois questions qu'un pair ne peut pas :

• ▸Qui est vraiment dans ce groupe maintenant ? (la liste de membres)
• ▸Quelle clé chiffre les messages, et qui la reçoit ?
• ▸Dans quel ordre ça s'est passé ?

Sans serveur, tu n'as aucune "machine de référence". Chaos assuré.

Les approches abandonnées

MLS (RFC 9420) : état de l'art de la crypto de groupe. Les clés sont arrangées en arbre ; quand tu ajoutes ou retires quelqu'un, seule une partie de l'arbre se recalcule. Extensible jusqu'à des milliers de membres.

Problème : MLS exige un "Delivery Service" centralisé pour distribuer les changements de clé. Sur DHT avec des pairs hors ligne ? Trop lourd. Et Kiyeovo plafonne à 10 membres — MLS serait surdimensionné.

Composition sans chef de file : n'importe qui peut ajouter ou retirer. Convergence éventuelle avec logique de fusion.

Problème : deux admins modifient la composition simultanément → deux versions différentes du groupe. Les règles de fusion deviennent un cauchemar. "X a-t-il été exclu avant ou après son dernier message ?" → pas de réponse sans horloge globale.

Composition gelée (à la Briar) : le groupe est figé à la création. Inviter ou exclure ? Impossible.

Problème : trop limitant, même si ça simplifierait 80% des problèmes.

La solution Kiyeovo : bancale mais honnête

Composition : un créateur unique

Chaque groupe a un créateur (clé Ed25519). Lui seul peut inviter ou retirer. Les autres membres gardent sa clé publique pour valider que les mises à jour viennent vraiment de lui.

Avantage : convergence triviale. Une seule source d'autorité = zéro conflit de partition.

Revers : si le créateur perd son téléphone, personne ne peut être ajouté ou retiré. Les membres peuvent partir volontairement (départ signé), mais c'est tout. Point de défaillance unique, assumé.

Clés : rotation par époque

Une époque = une version du groupe. Chaque époque a une clé symétrique de 32 octets, partagée par tous. Le créateur la scelle individuellement à chaque membre (chiffrement asymétrique) dans un message de contrôle signé.

Avantage : renouvellement de clé en O(n). Ultra-léger pour 10 membres.

Revers : zéro rotation de clé en cours d'époque. Si quelqu'un capture la clé, il peut lire tous les messages jusqu'au prochain changement de composition. Pas de confidentialité persistante continue.

Distribution : journal en ajout seul dans la DHT

L'historique du groupe (composition, séquences par émetteur) vit dans la DHT sous deux formes :

• ▸Un pointeur "dernière version" mutable
• ▸Une chaîne immuable d'enregistrements versionnés, chaque entrée signée par le créateur et liée à la précédente par hash (chaîne de Merkle)

Avantage : les membres hors ligne disposent de l'historique vérifiable de l'évolution du groupe.

Revers : le dernier écrit l'emporte. Sûr seulement parce qu'il n'y a qu'un seul rédacteur.

Séquençage et hors ligne : par émetteur, pas par destinataire

Chaque émetteur tient un numéro de séquence par (groupe, époque). Les destinataires détectent les trous.

Quand tu reviens en ligne, tu scannes les espaces DHT des autres : un espace par émetteur par époque, pas un par destinataire.

Pourquoi pas l'inverse ? Envoyer à N destinataires via N espaces individuels coûte N fois plus d'écritures DHT. Une inefficacité difficile à justifier.

Ce qu'on retiendra

Aucune approche n'est parfaite. Décentraliser vraiment, c'est accepter des compromis douloureux : un créateur goulet d'étranglement, zéro rotation de clé fine, groupes restreints. Mais ça marche, c'est honnête, et tu sais où ça va casser.