Как я НЕ влюбился в Reticulum
Есть такие сущности, которые на расстоянии выглядят просто чудесно. Для себя я называю такое "хочется в это влюбиться". Но при ближайшем рассмотрении оказывается, что "не моё". Для меня список подобных примеров пополнила сеть Reticulum [1].
Что за зверь?
Reticulum это стек для построения сетей, основанный на криптографии. Ключевые особенности:
- возможность как построения частной изолированной сети, так и присоединения к глобальной сети;
- сеть может строиться на основе широкого спектра аппаратного обеспечения, включая радиоканалы c низкой пропускной способностью;
- есть противодействие внешнему контролю (цензуре).
Сеть использует криптографические примитивы в качестве адресов. Никаких IP-адресов, никакого DNS, только собственные "велосипеды". Работы тут много, ведь нет простого подхода переписать существующие сетевые приложения для работы в сети Reticulum. И это (по своему) здорово ;)
Предпосылки
Reticulum попался мне на глаза где-то в 2025-ом. Я тогда не стал разбираться с ним, просто отметив в своей голове сам факт его существования.
Затем (в декабре 2025-го) Олег @R1CBU [2] выступал с докладом "Reticulum Network Stack: вчера, сегодня, завтра" в хакспейсе Бэкспейс [3]. Я с удовольствием посетил это мероприятие (в телеге, кстати, можно найти запись). Меня вдохновило выступление Олега и я решил, что стоит попробовать поковырять Reticulum своими руками.
Весна. 2026 год. Белые списки суверенного интернета РФ. В какой-то момент приходит желание построения отдельной сети. Отдельной от государства, от коммерческих провайдеров интернета и от операторов сотовой связи. На своём железе по своим правилам. И, глядя на Reticulum со стороны документации, кажется: так вот же оно!
Что уже есть
Начинать знакомиться с чем-то новым удобнее, когда уже что-то работает. В моём случае я решил "пощупать" Reticulum через NomanNet:
- Reticulum предоставляет транспортный уровень сети.
- Над транспортным уровнем есть две библиотеки: LXMF, отвечающая за пересылку отдельных сообщений, и LXST, отвечающая за передачу непрерывных потоков данных.
- А уже над LXMF построена NomadNet, которая организует простенький мессенждер и динамические сайты на собственном языке разметки micron.
Клиент к NomadNet реализован в виде TUI (сurses). Сначала было немного непривычно, но я освоился довольно быстро.
Клиент NomadNet это воплощение принципов дзена проекта Reticulum:
Consider:
The Old Way: Connect() -> Send() -> Wait() -> Crash if timeout.
The Zen Way: Send() -> Continue living. -> Receive() when it arrives.
This changes the user experience profoundly. It removes the anxiety of the loading bar. It creates a sense of continuity. The user is not “waiting for the network”; they are interacting with a persistent log of communication that lives in the network itself.
Всё асинхронное: события происходят параллельно с использованием приложения. Не то, что бы это было чем-то кардинально новым, но ощущается, действительно, как-то непривычно.
Моя попытка
Глядя на весь этот стек захотелось отбросить все "лишнее". Изучив документацию к Reticulum я пришёл к выводу, что там есть всё, что мне нужно.
Я люблю gemtext и подумал, что было здорово хостить свою капсулу ещё и в сети Reticulum. Хотелось поменьше зависимостей, поэтому я отбросил библиотеки вокруг Reticulum. Внутри уже реализуется абстракция Resource, которая позволяет передавать буфер произвольной длины.
Мне нравится протокол Spartan, поэтому я решил взять за основу именно его. Из Spartan я взял возможность загружать на сервер произвольные данные. Соответственно протокол состоит из запроса (когда клиент пересылает Resource с запросом на сервер) и ответа (когда сервер шлёт Resource с содержимым ответа обратно клиенту).
Я набросал клиента и сервер в сотню строк на Python каждый и проверил базовые концепции. Пару моментов из документации я понял не совсем верно, но в общем и целом проблем не возникло.
И я начал писать реализация сервера статики, отдающего gemtext документы с файловой системы. В итоге я добрался до исходного когда Reticulum. Ох, вот тут вся влюблённость в проект прошла. Для примера предлагаю посмотреть листинг конструктора объекта Resource [4]. Простыня на (более чем) двести строк. Ух...
Я понимаю, что стиль кодирования это чистая "вкусовщина". Но мне кажется исходный код Reticulum каким-то неаккуратным. В качестве примера возьмём из документации утилиту Filetransfer.py, реализующую передачу файла через объект Resource. И попробуем передать файл размером 0 байт:
Ошибка вызвана тем, что строке 331 проверка локальной переменной resource_data не учитывает размер файла 0. На мой вкус код Resource нужно было разбить на более мелкие, но аккуратные куски кода.
Reticulum это большой проект. И чем глубже я вникал в его внутренности, тем меньше мне хотелось с ним работать.
Плюс довольно странный статус репозитория на github:
This repository is a public mirror. All potential future development is happening elsewhere.
I am stepping back from all public-facing interaction with this project. Reticulum has always been primarily my work, and continuing in the current public, internet-facing model is no longer sustainable.
...
To the small group of people who has actually been here, and understood what this work was and what it cost - you already know where to find me if it actually matters.
To everyone else: This is where we part ways. No hard feelings. It's just time.
Хотя релизы на github продолжают публиковаться.
Вместо заключения
Я не хочу дальше погружаться в Reticulum. Но важно подчеркнуть: это моё личное отношение.
Это не делает проект плохим. Я искренне желаю, что бы такая правильная (с идеологической точки зрения) инициатива продолжала развиваться и находила своих пользователей.