DEV Community

Cover image for MycelK — Construire une messagerie p2p décentralisée from scratch
Matthieu Amoros
Matthieu Amoros

Posted on • Edited on

MycelK — Construire une messagerie p2p décentralisée from scratch

Post 0 : le pourquoi


J'ai eu le plaisir d'écouter il y a quelques jours le podcast de Lex Fridman et sa conversation avec Pavel Durov (Telegram). Comme d'habitude avec les podcasts de Lex, les questions sont pertinentes, les réponses profondes et les sujets techniques complexes sonnent comme de la prose. Deux personnes aussi intelligentes qui discutent de sujets complexes, ça donne forcément envie d'ouvrir son éditeur de code favori et de se lancer dans un projet utopique de messagerie décentralisée... (En tout cas c'est l'effet que ça a eu sur moi).

Mais du coup on parle de l'encryption end-to-end, de la protection des données, la responsabilité de l'entreprise de modérer les contenus partagés etc. Rien de bien fun et au final pourquoi on doit en arriver là ? Parce que les serveurs appartiennent à quelqu'un, et ce quelqu'un en est responsable.

Et là boum, l'idée : et si il n'y avait pas de serveurs ? Pas de responsables ? Et d'ailleurs si Matthieu veut parler à Alice, pourquoi il aurait besoin d'un intermédiaire ?

Alors j'ai commencé à me demander : est-ce qu'on pourrait faire autrement ?


L'idée

Une messagerie qui ne dépend d'aucun serveur central. Où chaque participant est à la fois client et nœud du réseau. Où couper un serveur ne coupe pas les communications.

Ce n'est pas une idée nouvelle — BitTorrent, IPFS, et des dizaines d'autres projets explorent ce sujet depuis vingt ans. Mais je voulais comprendre comment ça fonctionne vraiment, pas juste utiliser une bibliothèque qui abstrait toute la complexité.

C'est là que Kademlia entre en jeu.


Pourquoi Kademlia

Kademlia est un algorithme publié en 2002 par Maymounkov et Mazières (encore des sacrés cerveaux). C'est la fondation de BitTorrent, d'une partie d'IPFS, et de nombreux réseaux distribués/p2p. Son rôle : permettre à n'importe quel nœud du réseau de trouver n'importe quelle autre information sans serveur central.

Le concept clé est la définition de la distance entre les nœuds du réseau (via un XOR, mais bref on en parlera plus tard). Une métrique qui a des propriétés mathématiques sympas garantissant la convergence du routing et limitant la complexité algorithmique des recherches.

Je ne vais pas expliquer Kademlia dans ce post. Ce sera l'objet d'un article dédié. Ce que je veux dire ici, c'est que j'aurais pu utiliser une lib qui l'implémente déjà. Je ne l'ai pas fait. Je l'implémente from scratch, parce que c'est comme ça qu'on apprend vraiment.


Pourquoi Rust et Tauri

Je développe des solutions ERP pour l'agroindustrie. Mon quotidien c'est SQL Server, Python, de l'intégration avec des équipements industriels. Pas trop d'espace pour mes utopies de geek du coup.

Rust m'intéresse depuis un moment pour ses garanties de sécurité mémoire et ses performances. Un projet réseau p2p — avec de la concurrence, des timeouts, des connexions UDP — est exactement le terrain où ces garanties ont du sens.

Tauri me permet de construire une interface desktop avec React (la seule stack que je maîtrise en frontend) tout en gardant le backend en Rust. Un seul binaire, multiplateforme, sans Electron et ses 200MB de runtime.


La stack

Kademlia DIY          — l'algo, from scratch, zero lib
Tokio                 — runtime async Rust
WebRTC-rs             — p2p entre machines derrière NAT
Ed25519               — identité cryptographique
ChaCha20-Poly1305     — chiffrement E2E (on va voir ce que ça donne)
Tauri 2 + React + MUI — interface desktop
Enter fullscreen mode Exit fullscreen mode

Ce que cette série va couvrir

J'ai découpé le projet en 7 phases :

  1. Core Kademlia — NodeId, XOR distance, routing table, k-buckets

  2. Transport UDP + RPC — messages, sérialisation, matching requêtes/réponses

  3. Protocole complet — bootstrap, lookup itératif, store/republish

  4. Intégration WebRTC — connexion p2p réelle entre deux machines

  5. Messagerie — identité, chiffrement E2E, messages offline

  6. Tauri + React — interface utilisateur

  7. Web of Trust — résistance aux attaques Sybil via signatures Ed25519

Chaque phase fera l'objet d'un ou plusieurs articles. Je documenterai les décisions d'architecture, les erreurs, les dead ends. Pas un tutoriel mais plutot un journal de bord.


MycelK

Le projet s'appelle MycelK. Mycel comme mycélium — ce réseau souterrain de filaments fongiques qui connecte les arbres entre eux sans centre, sans hiérarchie, de manière résiliente. K comme Kademlia.

Le code sera open source sur GitHub. Le nom est libre sur crates.io.


Ce post existe parce qu'écrire me force à clarifier ma pensée. Et puis qui sait, peut-être que ça donnera de la visibilité à d'autres futurs projets.

Si tu travailles sur des sujets similaires ou si tu as des questions sur les choix d'architecture, les commentaires sont ouverts.

La suite : une explication de Kademlia pour des humains, puis le code de la Phase 1.

Top comments (0)