Я устал от бесконечных списков чатов и написал свой приватный мессенджер на гексагональных сотах (Kotlin + Go)

[zgwerby]

Концепт интересный, но не более чем. Тезисно:
- Агрегация большого количества нод и сама фрактальная структура: есть возможность плоского агрегированного отображения, допустим 15 непрочитанных веток или нужно постоянно бегать по веткам вглубь? Есть возможность агрегации с ранжированием по чатам?
- Возможность обзора всего дерева чатов на одном экране или бегай по интерфейсу, пока не найдёшь нужный или задействуй неестественную строку поиска? Возможность автоматического ранжирования чатов, ранжированного просмотра на одном экране и прыжки с опусканием неважных промежуточных нод?
- Будет ли возможность адаптивного перестроения дерева нод в зависимости от набора параметров? Хотя бы минимальная самоорганизующаяся система на основе "весов" и "расстояний" для чатов, чтобы важное выносить в первую очередь?
- Т.е. теперь приложение изначально требует от устройства быстрый большой сенсорный экран, время отклика на котором мгновенно? Что делать с устройствами, где основное управление идет кнопками/джойстиком/внешними несенсорными устройчствами? Что делать с устройствами, с небольшими несенсорными экранами, где рисовать гексы нерационально с точки зрения затрат энергии и места?
- Остальное стандартно, Е2Е/без пушей. Насколько оно сможет жить не на "толстой" сети, а в условиях изначально "плохой" пакетной радиосвязи при постоянном хендовере? Или при работе сети "на излёте"? Вопрос про БС я намеренно выношу за скобки. Вебсокет вообще как живет в условиях городской сети с резкими перепадами подключения мобильной сети и очень негарантированной доставкой, особенно в зонах с большими переотражениями? Как-то скомпенсировать будут попытки или на откуп системному радиомодему?
- Работает только поверх интернета/лан или есть возможность задействовать другие виды пакетной радиосвязи (при условии что у неё есть выход в инет/нет выхода в инет)?

[jetnet]

Пока не буду устанавливать, подожду форк:

Novus ordo

img

[Synthesis0100]

Спасибо за такой глубокие и интересные вопросы! Вы абсолютно правы: ОРДО, а по-русски ПОРЯДОК — это в первую очередь рабочий концепт, манифест альтернативного взгляда на интерфейсы и приватность, и мне очень ценно обсудить его ограничения.

Постараюсь ответить на ваши тезисы, объединив техническую часть и философию проекта.

1. Про навигацию, мышечную память и «анти-поиск» (Тезисы 1 и 2)

Идея навигации в ОРДО построена на двух принципах: она должна быть очевидной, а спустя короткое время — становиться буквально рефлекторной (на уровне мышечной памяти). Рефлекторный свайп: Например, чтобы спуститься на 5-й уровень глубины фрактала, пользователю нужно сделать всего 6 коротких свайпов пальцем в угле не более 90 градусов. Пальцы сами запоминают этот «рисунок» движения. Маячки вместо слепого блуждания: Навигация не будет слепой. Логика «маячков» реализуется через пульсацию «хлебных крошек». Если глубоко в ветви дерева есть непрочитанный чат или входящий пинг, то все родительские узлы по пути к этой ветви будут мягко пульсировать. Пользователь видит этот светящийся след и точно знает, куда ведет дорожка.

Отсутствие строки поиска — это фича, а не баг:) Я намеренно не планировал делать строку поиска, так как она идет вразрез с философией приложения. ПОРЯДОК создавался как место общения «для своих», для тех, с кем действительно есть о чем поговорить. Это пространство не для сиюминутных диалогов в стиле «открыл / закрыл / ответил раз в 10 минут». Существуют прекрасные и привычные нам всем мессенджеры, где можно быстро скинуть список покупок или узнать дежурное «как дела». ПОРЯДОК — это другая история, это пространство для глубоких, осознанных диалогов, которые имеют смысл, так это было задумано изначально.

2. Про адаптивное перестроение дерева (Тезис 3)

Идея автоматического смещения ячеек на основе их «веса» (частоты общения) заманчива, но она полностью разрушает пространственную память. Если соты будут постоянно менять свои места на основе алгоритмов, рефлекторная навигация станет невозможной. Это как если бы в вашей квартире дверь в кухню постоянно менялась местами с дверью в спальню просто потому, что сегодня вы чаще ходили в спальню. Статичность сетки позволяет выработать автоматический жест. Перестроение сетки должно быть исключительно ручным, под личным контролем пользователя.

3. Главная фича: Бесшовный суверенный мультисервер

Эта история началась, когда пошла вся эта возня с блокировками, цензурой, замедлениями и навязыванием конкретных платформ для общения. Мне захотелось создать систему, в которой люди смогут общаться при любом раскладе. В ПОРЯДКЕ любой пользователь может поднять свой собственный сервер Go Relay и пригласить туда друзей. При этом в одном приложении у вас на экране могут одновременно находиться соты-чаты, физически расположенные на десятке разных серверов (включая ваш личный). Но самое главное — при переходе между диалогами, завязанными на разные серверы, вы как пользователь этого даже не замечаете. Приложение бесшовно переподключает сокеты под капотом, сохраняя единую картину вашего персонального пространства. Эта механика уже на финишной прямой.

4. Требования к экрану и кнопочные устройства (Тезис 4)

Да, этот концепт изначально проектировался исключительно под современные смартфоны с сенсорными экранами. Пытаться адаптировать гексагональную сотовую навигацию под кнопочные телефоны (типа KaiOS) или джойстики — нерационально. Для кнопочных и несенсорных устройств классический текстовый список или CLI-интерфейс (командная строка) всегда были и будут на порядок эффективнее и экономичнее. ПОРЯДОК — это Touch-First концепт.

5. Работа WebSocket в условиях плохой связи (Тезис 5)

Это самый сложный вопрос для любого TCP-подключения в условиях застройки, хендоверов и потерь пакетов. Как это компенсируется сейчас: 1. Пакеты пингов и сообщений у нас весят всего по несколько байт (сырой зашифрованный массив). 2. На клиенте реализован быстрый цикл переподключения, а на сервере — временный почтовый ящик в оперативной памяти (pingMailbox). Если связь пропала во время перехода между вышками, сервер сохраняет пинг у себя (до 24 часов). Как только клиент восстанавливает WebSocket-сессию, он мгновенно забирает пропущенные пинги. Вектор развития: Использовать TCP на плохой связи — компромисс. В идеале транспортный уровень нужно переводить на QUIC / UDP (по аналогии с HTTP/3), чтобы избежать блокировок очереди при потере отдельных пакетов и сделать соединение устойчивым при частых сменах IP.

6. Работа поверх альтернативных сетей связи (Тезис 6)

Сейчас приложение жестко привязано к IP-сетям (интернет / LAN). Однако, благодаря тому, что все данные шифруются сквозным шифрованием (E2EE) на устройствах и превращаются в сырой массив байт, теоретически нет никаких препятствий для передачи этих пакетов через альтернативные виды связи (например, через радиомодемы LoRa, сеть Meshtastic или любительские радиостанции). Как только я опубликую открытый код Go-сервера, сообщество сможет написать транспортные адаптеры для пересылки байтовых пакетов ПОРЯДКА вообще без использования традиционного интернета.

[cmyser]

Да у вас прям очень похоже получилось на https://habr.com/ru/articles/956154/

Только crdt нет, может скооперируемся ? Сделаем веб клиент