DEV Community: Matthieu Amoros

MycelK — Fase 1: NodeId, distancia XOR y Kbuckets

Matthieu Amoros — Tue, 10 Mar 2026 15:52:20 +0000

Vamos a crear crates separados para manejar:

Kademlia: Solo el algoritmo, así podemos hacer tests estáticos fácilmente
Transport: Manejo de UDP/Tokio etc.
Node: El nodo en sí, que usará los crates anteriores

Organizamos las carpetas, scaffoldeamos los crates y configuramos el crate "Node".
"Node" es el crate central, le cambiamos el Cargo.toml para definir las dependencias.

Un pequeño cargo build para asegurarnos de no haber roto la config del Node.

Disclaimer

Normalmente uso Claude Code para acelerar ciertas implementaciones. Sé que si estás leyendo este blog vas a pensar: "Una IA programa esto en 15 minutos, eres un completo inútil".
Como dice el filósofo, la aventura es el camino recorrido, no el destino (o algo así).

Acá no vamos a usar IA para programar. La uso para formatear el blog, realizar investigaciones (best practices, documentación de las libs utilizadas, etc.) pero no va a escribir ni una línea de código en este proyecto. Así que les propongo código 100% orgánico y de vez en cuando no del todo optimizado.

No me juzguen, simplemente tengo ganas de programar y de romperme la cabeza a la antigua.

Empezamos con Kademlia

Primero lo primero: ¿cómo almacenamos el identificador de nodo? No hay u256 en Rust. Vamos a crear nuestra propia estructura [u8; 32] (32x8 = 256):

pub struct NodeId([u8; 32]); // 256 bits, nos pegamos a la spec

Tests y más tests

Ya sé que no soy un gurú del TDD, pero los tests no hacen daño. Vamos a cubrir las mecánicas básicas y le pediremos al amigo Claude que genere tests adicionales para desafiar mi código (dado que no tengo a nadie a mano para hacer peer review).

Me gusta mucho usar IA para generar tests unitarios adicionales, me permite matar dos pájaros de un tiro:

Si no logra generar tests coherentes sin más explicación que "Generate unittests for class/struct/mod XXXX", generalmente es porque el código no está suficientemente documentado
A veces encuentra ángulos de tests que yo no había considerado

Condición de salida fase 1

Le pedí a Claude que organizara el roadmap que había escrito y que le agregara condiciones de salida para cada fase. Le pedí que fuera exigente y me tiró una condición entretenida para la primera fase:
voz de robot: Criterio de salida: routing table correcta sobre 1000 nodos simulados en memoria.
Nada menos.

Entonces vamos, acá está mi función para determinar los nodos más cercanos:

    pub fn get_closest_nodes(&self, searched_node: &NodeId, node_count: usize) -> Vec<NodeId> {
        let center = self.get_bucket_index(searched_node);
        let mut closest_nodes: Vec<NodeId> = Vec::new();

        //Vamos a ver si tenemos suficientes nodes en el bucket objetivo, sino nos moveremos haciendo +/- 1
        closest_nodes.extend_from_slice(&self.routing_table[center]);

        let mut extension = 1usize;
        //Condiciones de parada cuando hayamos dado la vuelta
        let max_extension: usize = 255 - center;

        while closest_nodes.len() < node_count
            && (extension < max_extension)
        {
            if center >= extension {
                closest_nodes.extend_from_slice(&self.routing_table[center - extension]);
            }
            if center + extension <= 255 {
                closest_nodes.extend_from_slice(&self.routing_table[center + extension]);
            }
            extension += 1;
        }

        //Hay que ordenarlos de nuevo si tenemos más que node_count para retornar los más cercanos
        if closest_nodes.len() > node_count {
            closest_nodes.sort_by_cached_key(|n| searched_node.distance(n));
            closest_nodes.truncate(node_count);
        }

        closest_nodes
    }

Todos los tests pasan en verde de primera, excepto el terrible get_closest_nodes_correctness_1000_nodes.
Durante mi análisis me di cuenta de que con una cantidad de nodos inferior a 20, el sort funcionaba y el test pasaba.
Tenemos entonces un problema en el manejo de n > 20, lo que corresponde a un routing map con más de 1 índice lleno.
Mirando un poco la lógica, tengo un error de razonamiento en el sort final.

Hay que ejecutar SIEMPRE closest_nodes.sort_by_cached_key(|n| searched_node.distance(n)); dado que dentro de un bucket los nodos no están ordenados por distancia sino por disponibilidad (vía ping, etc.).

La condición de parada del while también está mal pensada (Matthieu por favor...), los buckets están ordenados respecto al owner, no al searched_node. Diferencia importante.

Tenemos entonces dos maneras de resolverlo:

Un fullscan: Recorremos todos los nodos conocidos, sort, truncate, return.
Optimizamos implementando varias etapas de scan:
- Primero el bucket que corresponde al nodo buscado. Si tiene una cantidad de nodos igual o superior a la cantidad buscada, sort, truncate, return.
- Segunda parte: No tenemos la cantidad de nodos pedida en el centro. Miramos los buckets de 0 a centro. Si tenemos la cantidad buscada, sort, truncate, return.
- Tercera parte: Todavía no tenemos lo que necesitamos, hay que explorar los buckets centro + k y paramos cuando tengamos la cantidad deseada o hayamos agotado los buckets. Sort, truncate, return.

Dije al principio que quería aprender, así que no nos vamos a conformar con el full scan.

    pub fn get_closest_nodes(&self, searched_node: &NodeId, node_count: usize) -> Vec<NodeId> {
        let center = self.get_bucket_index(searched_node);
        let mut closest_nodes: Vec<NodeId> = Vec::new();

        //Primera pasada: Si tenemos lo que necesitamos en el bucket objetivo, sort, truncate, return y listo.
        closest_nodes.extend_from_slice(&self.routing_table[center]);

        if closest_nodes.len() < node_count {
            //Segunda pasada: Revisamos los nodos cercanos
            let mut extension = 0usize;
            while extension < center {
                closest_nodes.extend_from_slice(&self.routing_table[extension]);
                extension += 1;
            }

            //Tercera pasada: Chequeamos los siguientes
            extension = center + 1;
            while extension < 255 && closest_nodes.len() < node_count {
                closest_nodes.extend_from_slice(&self.routing_table[extension]);
                extension += 1;
            }
        }

        closest_nodes.sort_by_cached_key(|n| searched_node.distance(n));
        closest_nodes.truncate(node_count);

        closest_nodes
    }

Y ahí tenemos derecho a un bonito output de terminal:

running 17 tests
test k_bucket::tests::add_myself ... ok
test k_bucket::tests::add_node_to_full_bucket_head_responds ... ok
test k_bucket::tests::add_same_node_twice ... ok
test k_bucket::tests::add_same_node_moved_to_tail ... ok
test k_bucket::tests::add_unknown_node_to_bucket ... ok
test k_bucket::tests::get_closest_nodes_returns_all_when_fewer_than_k ... ok
test k_bucket::tests::has_node_returns_none_when_absent ... ok
test k_bucket::tests::has_node_with_explicit_bucket_index ... ok
test node_id::tests::xor_identity ... ok
test node_id::tests::xor_symmetry ... ok
test k_bucket::tests::get_closest_nodes_never_exceeds_k ... ok
test k_bucket::tests::has_node_returns_some_when_present ... ok
test k_bucket::tests::get_bucket_index_basic ... ok
test k_bucket::tests::get_closest_nodes_correctness_1000_nodes ... ok
test node_id::tests::test_node_id_creation ... ok
test k_bucket::tests::get_closest_nodes_owner_never_in_result ... ok
test k_bucket::tests::get_closest_nodes_empty_routing_table ... ok

test result: ok. 17 passed; 0 failed; 0 ignored; 0 filtered out; finished in 0.02s

¡Fase 1 completada!

En el próximo post nos atacaremos a la capa de transporte, ¡a jugar con los sockets!

MycelK — Construyendo una mensajería p2p descentralizada from scratch

Matthieu Amoros — Tue, 10 Mar 2026 15:42:49 +0000

MycelK — Construyendo una mensajería p2p descentralizada from scratch

(Traducción al español desde mi post original en francés)

Post 0 : el porqué

Hace unos días tuve el placer de escuchar el podcast de Lex Fridman y su conversación con Pavel Durov (Telegram). Como siempre con los podcasts de Lex, las preguntas son pertinentes, las respuestas profundas, y los temas técnicos complejos suenan como poesia. Dos personas tan inteligentes conversando sobre temas complejos inevitablemente dan ganas de abrir el editor de código favorito y lanzarse en un proyecto utópico de mensajería descentralizada... (al menos ese fue el efecto que tuvo en mí).

Pero al final, de lo que se habla es de encriptación end-to-end, protección de datos, responsabilidad de la empresa en moderar los contenidos compartidos, etc. Nada muy entretenido, y ¿por qué llegamos a eso? Porque los servidores le pertenecen a alguien, y ese alguien es responsable de lo que pasa ahí.

Y ahí pensé: ¿qué pasaría si no hubiera servidores? ¿Sin responsables? Y de hecho, si Matthieu quiere hablar con Alice, ¿por qué necesitaría un intermediario?

Entonces empecé a preguntarme: ¿se podría hacer de otra forma?

La idea

Una mensajería que no dependa de ningún servidor central. Donde cada participante es a la vez cliente y nodo de la red. Donde cortar un servidor no corta las comunicaciones.

No es una idea nueva — BitTorrent, IPFS, y decenas de otros proyectos llevan veinte años explorando este tema. Pero yo quería entender cómo funciona de verdad, no solo usar una librería que abstrae toda la complejidad.

Ahí es donde entra Kademlia.

Por qué Kademlia

Kademlia es un algoritmo publicado en 2002 por Maymounkov y Mazières (otra dupla de cabezas brillantes). Es la base de BitTorrent, de una parte de IPFS, y de muchas redes distribuidas/p2p. Su rol: permitir que cualquier nodo de la red encuentre cualquier otra información sin servidor central.

El concepto clave es la definición de la distancia entre los nodos de la red (vía XOR, pero eso lo veremos después). Una métrica con propiedades matemáticas interesantes que garantizan la convergencia del routing y limitan la complejidad algorítmica de las búsquedas.

No voy a explicar Kademlia en este post. Eso será el objeto de un artículo dedicado. Lo que quiero decir acá es que podría haber usado una lib que ya lo implementa. No lo hice. Lo implemento from scratch, porque así es como se aprende de verdad.

Por qué Rust y Tauri

Desarrollo soluciones ERP para la agroindustria. Mi día a día es SQL Server, Python, integración con equipos industriales. Poco espacio para mis utopías de geek.

Rust me llama la atención desde hace un rato por sus garantías de seguridad de memoria y su rendimiento. Un proyecto de red p2p — con concurrencia, timeouts, conexiones UDP — es exactamente el terreno donde esas garantías tienen sentido.

Tauri me permite construir una interfaz desktop con React (el único stack que manejo en frontend) manteniendo el backend en Rust. Un solo binario, multiplataforma, sin Electron y sus 200MB de runtime.

El stack

Kademlia DIY          — el algoritmo, from scratch, sin libs
Tokio                 — runtime async Rust
WebRTC-rs             — p2p entre máquinas detrás de NAT
Ed25519               — identidad criptográfica
ChaCha20-Poly1305     — cifrado E2E (veremos cómo resulta)
Tauri 2 + React + MUI — interfaz desktop

Qué va a cubrir esta serie

Dividí el proyecto en 7 fases:

Core Kademlia — NodeId, distancia XOR, routing table, k-buckets
Transporte UDP + RPC — mensajes, serialización, matching de peticiones/respuestas
Protocolo completo — bootstrap, lookup iterativo, store/republish
Integración WebRTC — conexión p2p real entre dos máquinas
Mensajería — identidad, cifrado E2E, mensajes offline
Tauri + React — interfaz de usuario
Web of Trust — resistencia a ataques Sybil vía firmas Ed25519

Cada fase tendrá uno o más artículos. Voy a documentar las decisiones de arquitectura, los errores, los callejones sin salida. No es un tutorial, es más bien un diario de desarrollo.

MycelK

El proyecto se llama MycelK. Mycel como micelio — esa red subterránea de filamentos fúngicos que conecta los árboles entre sí sin centro, sin jerarquía, de manera resiliente. K como Kademlia.

El código será open source en GitHub. El nombre está libre en crates.io.

Este post existe porque escribir me obliga a clarificar mi pensamiento. Y quién sabe, quizás le dé visibilidad a otros proyectos futuros.

Si trabajas en temas similares o tienes preguntas sobre las decisiones de arquitectura, los comentarios están abiertos.

Lo que sigue: una explicación de Kademlia para humanos, y después el código de la Fase 1.

MycelK — Phase 1 : NodeId, XOR distance et Kbuckets

Matthieu Amoros — Tue, 03 Mar 2026 20:46:24 +0000

Post 1 : scaffolding du workspace, NodeId, XOR distance, routing table — Phase 1 complète.

Structure du workspace

On organise le projet en workspace Cargo avec trois crates séparés :

kademlia — l'algo pur, zero I/O, facile à tester en isolation
transport — UDP/Tokio, tout ce qui touche au réseau
node — le nœud à proprement parler, qui consomme les deux autres

node est la crate centrale. On configure son Cargo.toml pour déclarer les dépendances locales, puis un cargo build pour vérifier qu'on n'a rien cassé.

Disclaimer

D'habitude j'utilise Claude Code pour accélérer certaines implémentations. Je sais que si tu lis ce blog tu vas te dire : "Une IA code ça en 15min, t'es vraiment un gros naze".

Comme dit le philosophe, le plus important parfois c'est le chemin parcouru pas la destination.

Ici on n'utilisera pas d'IA pour coder. Je l'utilise pour formater le blog, faire des recherches (best practices, doc des libs, etc.), mais elle n'écrira aucune ligne de code sur ce projet. Du code 100% organique, forcément pas toujours optimisé.

Me jugez pas, j'ai juste envie de programmer et de me prendre la tête à l'ancienne.

NodeId

Premier problème concret : comment stocker un identifiant de nœud en Rust ?

Pas de u256 natif. On crée notre propre structure — un newtype autour d'un tableau de 32 octets (32 × 8 = 256 bits, conforme à la spec Kademlia) :

pub struct NodeId([u8; 32]);

Simple. Ça sérialise bien sur le réseau, ça tient dans une copie, et on garde la porte ouverte pour des implémentations futures sans casser l'interface.

Des tests et encore des tests

Je suis pas un gourou du TDD, mais des tests ça fait pas de mal. On couvre les mécaniques de base, et j'utilise Claude pour générer des tests additionnels qui challengent mon code — vu que j'ai personne sous la main pour faire du peer review.

J'aime beaucoup cette approche pour deux raisons :

Si l'IA n'arrive pas à générer des tests cohérents sans plus d'explications que "Generate unittests for struct NodeId", c'est souvent parce que le code n'est pas assez documenté.
Elle trouve parfois des angles de tests auxquels je n'avais pas pensé.

Condition de sortie Phase 1

J'avais écrit une roadmap, j'ai demandé à Claude de l'organiser et d'y ajouter des critères de sortie exigeants pour chaque phase. Le résultat pour la Phase 1 :

Critère de sortie : routing table correcte sur 1000 nœuds simulés en mémoire.

Rien que ça. On y va.

get_closest_nodes — première tentative

Voici ma première implémentation pour trouver les nœuds les plus proches d'un NodeId cible :

pub fn get_closest_nodes(&self, searched_node: &NodeId, node_count: usize) -> Vec<NodeId> {
    let center = self.get_bucket_index(searched_node);
    let mut closest_nodes: Vec<NodeId> = Vec::new();

    // On regarde d'abord le bucket cible, puis on s'étend par +/- 1
    closest_nodes.extend_from_slice(&self.routing_table[center]);

    let mut extension = 1usize;
    let max_extension: usize = 255 - center;

    while closest_nodes.len() < node_count && (extension < max_extension) {
        if center >= extension {
            closest_nodes.extend_from_slice(&self.routing_table[center - extension]);
        }
        if center + extension <= 255 {
            closest_nodes.extend_from_slice(&self.routing_table[center + extension]);
        }
        extension += 1;
    }

    if closest_nodes.len() > node_count {
        closest_nodes.sort_by_cached_key(|n| searched_node.distance(n));
        closest_nodes.truncate(node_count);
    }

    closest_nodes
}

Tous les tests passent au vert sauf un : get_closest_nodes_correctness_1000_nodes.

En analysant, je remarque que le test passe avec moins de 20 nœuds. Le bug se manifeste dès qu'on a plusieurs buckets non vides. Deux erreurs de raisonnement dans le code :

Erreur 1 — Le tri final est conditionnel (if closest_nodes.len() > node_count). Mais dans un bucket, les nœuds sont ordonnés par disponibilité (via ping), pas par distance XOR. Le tri doit être toujours exécuté.

Erreur 2 — La condition d'arrêt du while est fausse. Les buckets sont indexés par rapport au owner du nœud local, pas par rapport au searched_node. L'expansion symétrique autour de center ne correspond pas à une expansion par distance XOR croissante.

get_closest_nodes — version corrigée

Deux approches possibles :

Fullscan — parcourir tous les nœuds connus, trier, truncate, return.
Scan en plusieurs passes — optimiser en explorant d'abord le bucket cible, puis les buckets inférieurs, puis les supérieurs.

J'aurais pu prendre le fullscan. Mais on est là pour apprendre, donc :

pub fn get_closest_nodes(&self, searched_node: &NodeId, node_count: usize) -> Vec<NodeId> {
    let center = self.get_bucket_index(searched_node);
    let mut closest_nodes: Vec<NodeId> = Vec::new();

    // Première passe : bucket cible
    closest_nodes.extend_from_slice(&self.routing_table[center]);

    if closest_nodes.len() < node_count {
        // Deuxième passe : buckets 0..center
        let mut extension = 0usize;
        while extension < center {
            closest_nodes.extend_from_slice(&self.routing_table[extension]);
            extension += 1;
        }

        // Troisième passe : buckets center+1..255
        extension = center + 1;
        while extension < 255 && closest_nodes.len() < node_count {
            closest_nodes.extend_from_slice(&self.routing_table[extension]);
            extension += 1;
        }
    }

    // Tri XOR + truncate — toujours, sans condition
    closest_nodes.sort_by_cached_key(|n| searched_node.distance(n));
    closest_nodes.truncate(node_count);

    closest_nodes
}

Résultat

running 17 tests
test k_bucket::tests::add_myself ... ok
test k_bucket::tests::add_node_to_full_bucket_head_responds ... ok
test k_bucket::tests::add_same_node_twice ... ok
test k_bucket::tests::add_same_node_moved_to_tail ... ok
test k_bucket::tests::add_unknown_node_to_bucket ... ok
test k_bucket::tests::get_closest_nodes_returns_all_when_fewer_than_k ... ok
test k_bucket::tests::has_node_returns_none_when_absent ... ok
test k_bucket::tests::has_node_with_explicit_bucket_index ... ok
test node_id::tests::xor_identity ... ok
test node_id::tests::xor_symmetry ... ok
test k_bucket::tests::get_closest_nodes_never_exceeds_k ... ok
test k_bucket::tests::has_node_returns_some_when_present ... ok
test k_bucket::tests::get_bucket_index_basic ... ok
test k_bucket::tests::get_closest_nodes_correctness_1000_nodes ... ok
test node_id::tests::test_node_id_creation ... ok
test k_bucket::tests::get_closest_nodes_owner_never_in_result ... ok
test k_bucket::tests::get_closest_nodes_empty_routing_table ... ok

test result: ok. 17 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.02s

17/17. Phase 1 terminée.

La suite : couche transport UDP avec Tokio. À nous les sockets.

Venez voir, c'est bien.

Matthieu Amoros — Sun, 01 Mar 2026 02:50:42 +0000

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

Matthieu Amoros ・ Feb 28

#p2p #rust #tauri #programming

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

Matthieu Amoros — Sat, 28 Feb 2026 22:57:04 +0000

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

Ce que cette série va couvrir

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

Core Kademlia — NodeId, XOR distance, routing table, k-buckets
Transport UDP + RPC — messages, sérialisation, matching requêtes/réponses
Protocole complet — bootstrap, lookup itératif, store/republish
Intégration WebRTC — connexion p2p réelle entre deux machines
Messagerie — identité, chiffrement E2E, messages offline
Tauri + React — interface utilisateur
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.