Reticulum est une pile réseau fondée sur la cryptographie, créée par Mark Qvist, qui permet à quiconque de construire des réseaux locaux et étendus sur presque n’importe quel support — radio LoRa, packet radio, câbles série, TCP/IP ou I2P — sans adresses IP, sans DNS et sans infrastructure centrale. Chaque node génère ses propres clés Ed25519 et X25519, de sorte que l’adressage et le chiffrement de bout en bout sont auto-émis plutôt qu’accordés par une autorité, et le réseau se configure et se régénère de lui-même sur plusieurs hops. Pour les Bitcoiners souverains, c’est un moyen de maintenir la messagerie et la coordination quand l’internet est censuré, bridé ou tout simplement absent.
Ce qu’est Reticulum, et pourquoi il existe
La Reticulum Network Stack (RNS) se décrit comme “la pile réseau fondée sur la cryptographie pour construire des réseaux locaux et étendus avec du matériel facilement disponible.” Elle est conçue pour continuer de fonctionner “dans des conditions adverses, comme une bande passante extrêmement faible et une latence très élevée” — les conditions exactes que l’on rencontre sur une liaison radio longue portée ou un réseau dégradé. L’objectif déclaré du projet est de permettre à “quiconque d’exploiter ses propres réseaux de communication souverains” qui “ne peuvent être soumis à un contrôle, une manipulation ou une censure externes.”
Cette mission fait écho à celle de Bitcoin. Là où Bitcoin supprime le besoin d’un tiers de confiance pour détenir et déplacer de la valeur, Reticulum supprime le besoin d’un tiers de confiance pour détenir et déplacer l’adressage et la confiance sur un réseau. Il n’y a ni registraire, ni allocation d’un FAI, ni autorité de certification dans la boucle. Comme le dit la documentation, “il n’y a pas de contrôle central sur l’espace d’adresses dans Reticulum — quiconque peut allouer autant d’adresses qu’il en a besoin, quand il en a besoin.” Si vous voulez le tableau d’ensemble de pourquoi cela compte, notre hub de souveraineté numérique situe le mesh networking aux côtés de l’auto-conservation, de l’identité privée et de l’alimentation hors réseau.
Reticulum est écrit en Python 3 et s’exécute entièrement en espace utilisateur — pas de modules noyau, pas de root, pas de pilotes spéciaux. Cela le rend pratique à faire tourner sur un Raspberry Pi, un vieil ordinateur portable, un téléphone Android ou un ordinateur monocarte relié à une radio. C’est un logiciel de référence publié sous licence permissive, et c’est l’œuvre du développeur indépendant Mark Qvist, qui rédige aussi l’essentiel de l’écosystème applicatif et matériel environnant. Nous devons toute la pile à cet effort open source.
Concepts fondamentaux : comment RNS fonctionne réellement
Reticulum est petit mais inhabituel. Une poignée de primitives portent tout le travail lourd, et les comprendre est le moyen le plus rapide de raisonner sur ce que le réseau peut et ne peut pas faire.
Identités
Tout commence par une Identity : un jeu de clés auto-généré contenant une clé Ed25519 pour les signatures et une clé X25519 pour l’échange de clés ECDH. Une Identity n’est pas nécessairement une personne — la documentation la décrit comme “une abstraction qui peut représenter n’importe quel type d’entité vérifiable,” par exemple un capteur, un relay ou un compte de clavardage. Vous en créez une hors ligne, en quelques millisecondes, sans inscription et sans permission. C’est la même posture qui rend un portefeuille Bitcoin ou une paire de clés Nostr souveraine : la clé est le compte.
Destinations et adressage
Une Destination est l’endroit où les packets sont adressés. Reticulum dérive l’adresse d’une destination en hachant un chemin d’« aspect » lisible par l’humain (par exemple, messenger.user.inbox) avec la clé publique de l’Identity propriétaire, puis en tronquant à une valeur de 16 octets (128 bits). La documentation appelle 16 octets “un compromis raisonnable entre l’espace d’adresses et le surcoût des packets.” Parce que l’adresse est dérivée cryptographiquement plutôt qu’assignée, deux parties ne peuvent pas entrer en collision et aucune autorité ne garde l’espace de noms.
Annonces et découverte de chemins
Lorsqu’un node veut être joignable, il diffuse une announce — un petit packet signé qui annonce une destination. Les announces se propagent hop par hop à travers les transport nodes selon des règles prévisibles (limites de hops et un plafond de bande passante par interface) de sorte qu’« une announce se propagera dans tout le réseau de façon prévisible, et rendra la destination annoncée joignable en peu de temps. » Les autres nodes apprennent le prochain hop vers cette destination sans jamais avoir besoin d’une table de routage globale ni d’une résolution DNS.
Links, chiffrement et forward secrecy
Pour une conversation, deux nodes établissent un Link : un canal éphémère chiffré de bout en bout. Reticulum utilise X25519 ECDH pour dériver des clés éphémères, AES-256 en mode CBC (avec remplissage PKCS7) pour le chiffrement symétrique, et HMAC-SHA256 pour l’authentification. Parce que les clés de session sont éphémères, la forward secrecy est le comportement par défaut — une clé à long terme compromise ne peut pas déchiffrer rétroactivement le trafic passé. Établir un link coûte seulement “3 packets totalisant 297 octets,” et le maintenir ouvert coûte moins d’un demi-bit par seconde, ce qui explique pourquoi RNS survit sur des liaisons qui affameraient presque tout le reste.
Deux autres propriétés comptent pour la résistance à la censure. Le chiffrement de bout en bout est automatique pour les destinations normales et ne peut pas être désactivé par accident pour la messagerie (Reticulum définit bien un type de destination PLAIN, mais il est réservé aux cas spéciaux, pas au trafic ordinaire). Et Reticulum “n’utilise pas d’adresses source” : les packets ne portent aucune information sur la machine ou la personne qui les a originés, ce qui confère à l’initiateur un degré significatif d’anonymat par conception.
Transport nodes, routage auto-régénérant et Resources
Tout node peut être promu en transport node qui relaie le trafic pour les autres. Fait crucial, un transport node ne connaît jamais que le prochain hop le plus direct vers une destination — jamais le chemin de bout en bout complet — et le réseau redérive automatiquement les chemins lorsqu’une liaison tombe, rendant le routage auto-configurant et auto-régénérant. Pour les payloads plus grands qu’un seul packet, le mécanisme Resource gère “le découpage des données en packets individuels, le séquençage du transfert, la vérification d’intégrité et le réassemblage” du résultat. La MTU minimale utilisable de couche physique est de 500 octets, et RNS reste fonctionnel sur tout support offrant plus d’environ 5 bits par seconde de throughput.
Transports et interfaces : le faire tourner sur n’importe quoi
La ruse définissante de Reticulum est qu’il est agnostique au support. La même Identity et le même Link chiffré fonctionnent que le porteur sous-jacent soit une radio, un câble ou l’internet public. La pile est livrée avec un large éventail d’interfaces, notamment :
- RNodeInterface — pilote un émetteur-récepteur LoRa (un “RNode”) avec gestion complète des paramètres ; la principale façon de faire tourner RNS sur la radio longue portée sans licence.
- KISSInterface et AX25KISSInterface — modems packet-radio et TNC, y compris l’encapsulation radioamateur AX.25 pour les opérateurs titulaires de licence.
- SerialInterface et PipeInterface — liaisons série directes et interfaces virtuelles pilotées par programme.
- TCPClientInterface, TCPServerInterface et UDPInterface — font passer Reticulum en tunnel à travers l’internet existant pour relier des poches distantes de mesh.
- I2PInterface — transporte RNS sur l’Invisible Internet Protocol pour une couche supplémentaire de confidentialité réseau.
- AutoInterface et BackboneInterface — découverte zéro-configuration sur Ethernet/Wi-Fi local, et backhaul à haut débit entre sites.
Parce que les interfaces peuvent être mélangées librement, un déploiement réaliste pourrait relier un mesh LoRa de quartier au node d’un ami de l’autre côté du pays via TCP, puis vers une liaison packet-radio dans une zone morte — le tout de façon transparente, entièrement chiffré, sans qu’aucun gateway ne détienne le texte en clair.
La couche applicative : LXMF, Sideband et Nomad Network
RNS est de la plomberie ; on parle aux gens par des applications construites par-dessus. La plus importante est LXMF (le Lightweight Extensible Message Format), un protocole de messagerie que le projet décrit comme “un format de messagerie et un protocole de livraison simples et flexibles… utilisant le moins de bande passante possible.” LXMF hérite du routage zéro-configuration de Reticulum, du chiffrement de bout en bout et de la forward secrecy.
LXMF prend en charge deux styles de livraison. La livraison opportuniste intègre un court message dans un seul packet Reticulum pour un passage direct. Pour les destinataires hors ligne, les LXMF Propagation Nodes “offrent un moyen de stocker et de relayer les messages,” formant un magasin de messages chiffré et distribué que les nodes synchronisent entre eux — la même résilience de stockage et de relais qui permet au courriel de survivre à une boîte hors ligne, mais sans qu’aucune entreprise ne possède les serveurs. Les clients destinés aux utilisateurs construits sur LXMF comprennent :
- Sideband — un messager bureau et Android pour les conversations chiffrées du quotidien sur n’importe quelle interface Reticulum.
- Nomad Network — un environnement en terminal pour la messagerie, les pages et le partage de fichiers à travers le mesh.
- MeshChat — un client web communautaire pour la messagerie LXMF.
C’est là que les cas d’usage voisins de Bitcoin deviennent concrets : coordonner un site de minage distant, relayer une demande de paiement, ou transmettre un message signé quand l’internet est coupé. Si votre objectif est de déplacer de la valeur plutôt que du clavardage, couplez RNS au playbook hors réseau plus large dans envoyer du Bitcoin sur les réseaux mesh et notre guide des dispositifs de signature Bitcoin, qui signent les transactions entièrement hors ligne avant même que vous ne touchiez à une radio.
Réalités du matériel et de la bande passante
La radio la plus populaire pour Reticulum est un RNode — firmware ouvert, aussi de Mark Qvist, qui transforme une carte de développement LoRa peu coûteuse et largement disponible en un émetteur-récepteur natif Reticulum. Vous flashez le firmware, reliez la carte à n’importe quel hôte via USB ou série, et RNS la pilote directement. Les RNodes peuvent aussi fonctionner comme répéteurs autonomes.
Soyez réalistes quant au throughput. LoRa échange la vitesse contre la portée via son spreading factor (7 à 12, “7 étant le plus rapide et 12 ayant la plus longue portée”) et la largeur de canal. En pratique, une liaison LoRa livre de l’ordre de quelques centaines de bits par seconde jusqu’à plusieurs kilobits par seconde — assez pour du texte, des messages signés, des données de capteurs et de petits fichiers, mais pas pour la vidéo ou la navigation web. Notre explication du protocole LoRa couvre les fréquences, les spreading factors et les limites de cycle d’utilisation en profondeur. Reticulum est conçu précisément pour ce régime : le keepalive d’un Link à moins d’un bit par seconde et la MTU de 500 octets font que le surcoût protocolaire se remarque à peine face aux contraintes propres de la radio.
Reticulum vs Meshtastic : une comparaison neutre
Reticulum et Meshtastic sont souvent mentionnés ensemble, et les deux sont d’excellents projets open source qui méritent d’être soutenus. Ils résolvent des problèmes qui se chevauchent avec des architectures différentes, et beaucoup de gens font tourner les deux. Le tableau ci-dessous expose les différences factuelles — pas un verdict.
| Dimension | Reticulum (RNS) | Meshtastic |
|---|---|---|
| Conception de base | Pile réseau polyvalente ; les applications se superposent par-dessus | Messager mesh LoRa et firmware conçus à cet effet |
| Support physique | Agnostique au support : LoRa, packet radio, série, TCP/UDP, I2P, Ethernet/Wi-Fi | LoRa exclusivement |
| Adressage | Hachages de destination de 16 octets auto-émis, dérivés de clés par node ; pas d’adresses source | ID numériques de node (4 octets) organisés en canaux ; champs explicites to/from |
| Chiffrement | De bout en bout par défaut ; X25519 ECDH + AES-256 + HMAC-SHA256 ; forward secrecy | Clé partagée par canal (AES-256-CTR) ; le firmware 2.5+ chiffre aussi les messages directs avec des clés publiques par node (Curve25519) |
| Routage | Routage auto-configurant et auto-régénérant au prochain hop via transport nodes et announces | Inondation gérée avec un compteur hop-limit |
| Matériel | Tourne en Python en espace utilisateur sur un Pi, un PC ou un téléphone ; RNode pour LoRa | Tourne comme firmware directement sur les cartes LoRa prises en charge |
| Usage typique | Réseaux souverains multi-supports, messagerie de stockage et relais, développement d’applications | Messagerie texte de groupe/pair hors réseau clé en main sur radios peu coûteuses |
Une façon utile de garder les deux en tête : Meshtastic est exceptionnellement facile à déployer sur du matériel LoRa dédié, tandis que Reticulum offre un espace d’adresses unifié, chiffré de bout en bout, qui s’étend sur plusieurs supports à la fois. Ils se complètent davantage qu’ils ne se concurrencent. Pour le contexte propre aux Bitcoiners, voir démarrage avec Meshtastic et pourquoi Bitcoin et les réseaux mesh mènent le même combat.
Où Reticulum s’inscrit dans une pile de souveraineté Bitcoin
Reticulum ne remplace pas vos autres outils — il se place en dessous d’eux comme transport résistant à la censure. Quelques schémas qui valent la peine d’être pensés :
- Maintenir la coordination quand le FAI tombe. Un mesh RNS adossé à LoRa peut transporter des messages entre votre node à la maison, un mineur distant et un relay hors site même sans aucun internet, comme exploré dans garder votre node et votre mineur en ligne quand le FAI tombe.
- Signer hors ligne, transmettre par radio. Construisez et signez une transaction air-gappée avec un dispositif de signature dédié, puis déplacez le petit payload signé via LXMF pour qu’un pair le diffuse.
- Empiler la confidentialité sur la confidentialité. L’absence d’adresses source de Reticulum s’accorde naturellement avec les systèmes d’identité souveraine ; si vous faites aussi tourner Nostr, notre référence des NIPs Nostr montre où l’identité fondée sur les clés chevauche les clés auto-émises de RNS.
- S’appuyer sur les données ouvertes. La planification matérielle — radios, alimentation, mineurs — peut s’appuyer sur les jeux de données lisibles par machine de notre hub de données ouvertes.
Deux guides compagnons publiés en même temps que celui-ci complètent la pile monétaire hors réseau : Nostr Wallet Connect pour le contrôle Lightning à distance, et Cashu et Fedimint ecash pour les paiements au porteur qui fonctionnent sur des liaisons minces. Reticulum est le transport ; ce sont les couches de paiements et de contrôle qui roulent par-dessus.
Foire aux questions
Reticulum a-t-il besoin d’internet pour fonctionner ?
Non. Reticulum n’a besoin ni d’internet, ni d’adresses IP, ni de DNS. Il peut tourner entièrement sur radio LoRa, packet radio ou liaisons série entre des machines qui n’ont jamais touché l’internet public. Il peut aussi passer en tunnel sur l’internet (via TCP, UDP ou I2P) quand c’est pratique, mais l’internet n’est qu’un support optionnel parmi d’autres.
Le trafic Reticulum est-il chiffré par défaut ?
Oui. Le chiffrement de bout en bout est toujours actif, avec l’échange de clés X25519, le chiffrement symétrique AES-256 et l’authentification HMAC-SHA256, les clés éphémères assurant la forward secrecy. Le chiffrement est automatique pour les destinations normales et ne peut pas être désactivé par accident pour la messagerie, et les packets ne portent aucune adresse source, de sorte que le node d’origine n’est pas identifié dans les données qu’il envoie.
De quel matériel ai-je besoin pour commencer ?
Au minimum, un ordinateur qui exécute Python 3 — un Raspberry Pi, un ordinateur portable de rechange ou un téléphone Android. Pour passer hors réseau par radio, ajoutez un RNode : firmware ouvert flashé sur une carte de développement LoRa courante et peu coûteuse, connectée en USB. Deux nodes à portée radio peuvent alors former un link privé et chiffré sans aucune autre infrastructure.
À quelle vitesse fonctionne un réseau Reticulum ?
Cela dépend entièrement du support le plus lent sur le chemin. Sur TCP ou Wi-Fi local, c’est rapide ; sur LoRa, cela va de quelques centaines de bits par seconde à plusieurs kilobits par seconde, selon le spreading factor et la bande passante. Reticulum reste utilisable sur toute liaison au-dessus d’environ 5 bits par seconde, c’est pourquoi il convient au texte, aux messages signés et aux petits fichiers plutôt qu’au streaming.
En quoi Reticulum diffère-t-il de Meshtastic ?
Meshtastic est un messager LoRa clé en main qui tourne comme firmware sur des radios dédiées ; il sécurise chaque canal avec une clé partagée et, depuis le firmware 2.5, chiffre aussi les messages directs avec des clés publiques par node. Reticulum est une pile réseau polyvalente qui tourne sur plusieurs supports à la fois, donne à chaque node une adresse cryptographique auto-émise, et fournit un chiffrement de bout en bout avec forward secrecy entre points d’extrémité individuels. Beaucoup de configurations souveraines font tourner les deux, et les projets se complètent plutôt qu’ils ne se concurrencent.
Puis-je envoyer du Bitcoin sur Reticulum ?
Reticulum lui-même est un transport, pas un portefeuille. Vous signez une transaction hors ligne sur un dispositif dédié, puis utilisez une application fondée sur LXMF comme Sideband ou Nomad Network pour relayer le petit payload signé à un pair qui le diffuse sur le réseau Bitcoin. La liaison radio déplace des octets ; votre dispositif de signature et votre portefeuille font toujours respecter les règles. Voir nos guides compagnons sur la transmission Bitcoin en mesh pour des schémas qui fonctionnent.



