Привет, Хабр!
Меня, честно говоря, просто утомили современные интерфейсы общения и навигации. Куда ни посмотри — в Telegram, Slack, WhatsApp, на почте — нас везде встречает один и тот же шаблон: бесконечный, давящий вертикальный список чатов. Это превращает общение в какую-то рутину, конвейер, где новые сообщения постоянно вытесняют старые, заставляя нас бесконечно скроллить экран вверх и вниз.
Мне захотелось создать нечто принципиально иное. Что-то более близкое к естественным природным взаимосвязям. При разработке интерфейса я во многом ориентировался на биомиметику и структуру нейронных связей в упрощенном виде. Ведь в живой природе не существует листов, таблиц и списков — она оперирует узлами, ветвями и сетями. Мне хотелось создать среду для общения и структурирования мыслей, которая ощущалась бы интуитивно и естественно.
Так родился проект ПОРЯДОК или ORDO. Идея навигации в нем реализована фрактально-пространственным способом — в виде гексагональных сот (ячеек).
ОРДО — это полностью некоммерческий, бесплатный концепт приватного мессенджера со сквозным шифрованием (E2EE), написанный в одиночку. Я хочу поделиться с вами историей его разработки, показать устройство под капотом и, конечно, получить вашу конструктивную критику.
🌌 Как это выглядит визуально?
Интерфейс приложения построен на концепции трех главных направлений фрактала, в которые можно погружаться бесконечно в глубину:
-
⬢ Я (1.1) … (в процессе): Пространство для формирования личных мыслей (заметки, календарь, сейф и избранное, связанное умным структурированием).
-
⬢ Мы (1.2): Пространство для осознанных личных диалогов и мостов связи. Это самый завершенный блок на данный момент.
-
⬢ Мир / Сообщества (1.3) … (в процессе): Пространство для групп и каналов вещания.
Вы нажимаете центральную соту пальцем и можете плавно скроллить и перемещаться по ветвям фрактала. Каждая сота — это узел связи, внутри которого могут находиться новые узлы или зашифрованные чаты.
Я записал короткие демонстрации работы интерфейса, так как словами это передать сложно:
Демонстрация навигации по сотам (YouTube)
Процесс сопряжения устройств (YouTube)
Как устроены диалоги внутри ОРДО (YouTube)
🛰 Что под капотом у клиента (Android)?
Проект написан полностью на Kotlin с использованием Jetpack Compose для прорисовки интерфейса.
При разработке я придерживался принципа «минимального цифрового следа». Вот как это реализовано технически:
1. Личность без регистрации и паролей
В приложении нет серверов регистрации, логинов, паролей или привязки к номерам телефонов. При первом запуске устройство генерирует пару криптографических ключей Ed25519. Ваш публичный ключ — это ваш единственный паспорт. На его основе генерируется удобный текстовый шорт‑код («ДНК» профиля, например, Gold013189). Вы можете экспортировать свои ключи в виде зашифрованной строки для бэкапа и восстановить свой профиль на любом другом устройстве.
2. Зашифрованная база данных на диске
Вся история сообщений и метаданные хранятся только локально на вашем телефоне. База данных SQLite зашифрована на физическом диске с помощью библиотеки SQLCipher (используется 128-битный ключ). Пароль для расшифровки БД генерируется на основе приватного ключа пользователя, который безопасно хранится в Android Keystore через EncryptedSharedPreferences. Если злоумышленник физически завладеет телефоном, он не сможет прочитать базу без взлома Keystore.
3. Сквозное шифрование (End‑to‑End)
Все сообщения шифруются на устройствах по алгоритму AES-256-GCM. Функция передачи медиафайлов сейчас находится в процессе шлифования и в данный релиз не вошла, но сообщения шифруются полноценно. Ключи шифрования для каждого чата генерируются непосредственно во время сопряжения устройств. Сервер‑ретранслятор никогда не видит ваши сообщения в открытом виде — для него это просто транзит случайного набора байт.
4. Почему WebSocket в Foreground Service вместо Google FCM?
Привычные пуш‑уведомления от Google (FCM) — это удобный инструмент, но он полностью контролируется корпорацией. Google видит, кто, кому и в какое время отправляет сигналы, формируя ваш социальный граф на своих серверах.
Чтобы уйти от этого, я реализовал независимый фоновый сервис (Foreground Service). Он удерживает тонкое, энергоэффективное WebSocket‑соединение с сервером. При отправке «пинга» (вызова к диалогу) сервер находит ваше соединение в оперативной памяти по публичному ключу и мгновенно пересылает пустой зашифрованный пакет размером в несколько байт. Телефон принимает этот «стук в дверь», сопоставляет хэш канала локально и показывает уведомление. Наша фоновая служба спроектирована так, что практически не расходует заряд батареи во сне.
Важный нюанс: Чтобы агрессивные механизмы энергосбережения современных версий Android (начиная с 13–14 версий) принудительно не глушили службу спустя 15 минут после блокировки экрана или при закрытии приложения, пользователю необходимо вручную выдать приложению разрешение на неограниченную работу в фоновом режиме (Unrestricted background execution).
📡 Что под капотом у сервера (Go Relay)?
Серверная часть написана на Go и работает как «слепой» маршрутизатор исключительно в оперативной памяти (RAM).
-
На сервере нет базы данных сообщений. Пакеты пересылаются транзитом напрямую получателю, если он в сети.
-
Если получатель офлайн, пинг временно сохраняется в почтовом ящике в оперативной памяти (
sync.Map) и удаляется сразу же после доставки или по истечении 24 часов. -
Я оптимизировал сервер так, чтобы исключить тяжелые дисковые операции записи на каждый чих. База данных SQLite на сервере используется только один раз — в момент регистрации структуры нового канала при сопряжении.
🤝 Ритуал сопряжения: Роль Секретного Слова
В ОРДО невозможно получить спам от незнакомцев на аппаратном уровне. Чтобы начать общение, нужно пройти «рукопожатие».
Ключевым криптографическим элементом здесь является Секретное Слово. Оно вводится в обоих сценариях сопряжения и выполняет важнейшую роль: на его основе устройства генерируют уникальный идентификатор канала связи ChannelId и растягивают симметричный ключ шифрования AES-256-GCM по алгоритму PBKDF2 (100 000 итераций). Секретное слово никогда не передается на сервер в открытом виде. Без знания этого слова даже владелец сервера не сможет узнать, кто общается на релеях, и тем более не сможет расшифровать трафик.
Локальный ритуал (QR)
При личной встрече вы сканируете одноразовый QR‑код друг друга. Этот код автоматически передает вашему устройству публичный ключ партнера и адрес его ретранслятора, исключая опечатки при вводе. После этого вы оба вводите одинаковое Секретное Слово, чтобы надежно запечатать и зашифровать ваш канал.
Удаленный ритуал (Blind Match по ID)
Если вы далеко друг от друга, вы вручную вводите ID друг друга или отправляете QR‑код, и далее одинаковое Секретное Слово. Телефоны отправляют на сервер не само слово, а его односторонний криптографический хэш (SHA-256). Сервер выступает в роли «слепого коммутатора»: видя два одинаковых хэша в памяти, он на долю секунды соединяет ваши устройства во временный тоннель, где телефоны обмениваются публичными ключами шифрования, генерируют mutual‑соль сессии и прописывают канал связи. Сервер закрывает тоннель и уходит в сторону.
⚠️ Текущий статус проекта и дисклеймер
Проект ОРДО на данном этапе является активным рабочим прототипом. Я делюсь им с сообществом абсолютно бесплатно и без рекламы.
Поскольку кодовая база и структура данных на диске сейчас активно развиваются, обратная совместимость локальных баз данных не гарантируется. Обновление приложения может приводить к полному сбросу локальной истории чатов на вашем устройстве. Пожалуйста, не используйте его для хранения критически важной информации на данном этапе!
Также обратите внимание на безопасность: адрес сервера скрыт в исходном коде и обфусцирован с помощью R8/ProGuard в релизной сборке. Для защиты сервера мы используем проверку подписей Ed25519 на каждый пакет и ограничение частоты запросов. В будущем я опубликую исходный код сервера Go Relay, чтобы каждый мог запустить свой собственный ретранслятор.
Буду рад вашим отзывам, критике архитектуры, предложениям по улучшению интерфейса сот и поиску багов!
ссылка на оригинал статьи https://habr.com/ru/articles/1045002/