NNNet/docs/ARCHITECTURE.md

Архитектура NNNet

Слои

• BLE Transport: сканирование, реклама, соединения, обмен пакетами.
• Mesh Layer: маршрутизация, TTL, дедупликация, ACK, ретрансляция профильных пакетов.
• Messaging Layer: список чатов, отдельный экран диалога, статусы доставки, история.
• Storage Layer: Room для локального хранения сообщений, очереди и профилей.
• Diagnostics Layer: карта сети и журнал пакетов, построенные на данных Room.
• Delivery Layer: retry queue, ACK timeout, повторные отправки из фонового сервиса.
• Update Layer: version.json, changelog и ручная/автоматическая проверка обновлений клиента.
• Profile Layer: локальный профиль пользователя, username как основной идентификатор, кэш профилей из mesh-сети, разрешение username <-> peerId, lease на 14 дней и recovery bundle для переноса идентичности.

Пользовательский сценарий

• Главный экран показывает список чатов в стиле Telegram.
• Верхний статусный блок переключает mesh-сеть между состояниями В сети и Не в сети.
• Слева в шапке показывается общее количество известных устройств в mesh.
• В меню три точки доступны Карта сети, Пакеты и Настройки, отдельный debug-лог из пользовательского интерфейса убран.
• Отправка сообщений доступна только из экрана конкретного диалога.
• В настройках пользователь редактирует свой профиль, ищет другие профили по username, имени, фамилии, полному имени и peerId, а также может экспортировать или импортировать recovery bundle.
• В настройках доступны режим карты сети и экран журнала пакетов.
• Поток обновления: version.json -> скачивание APK в cache/updates -> остановка mesh -> запуск системной установки через FileProvider и Intent.ACTION_VIEW.

Топология сети

• Выделенный сервер или хост для работы mesh не нужен.
• Все узлы равноправны: каждый телефон может быть источником, получателем и ретранслятором.
• Сеть не рассчитана на бесконечное число пользователей. Масштаб ограничивается радиусом BLE, количеством соседних соединений, частотой ретрансляции и ограничениями Android по энергии и фону.
• Профильные данные передаются отдельными mesh-пакетами и кэшируются на устройствах. Это даёт распределённый каталог пользователей без центрального сервера, но актуальность данных зависит от распространения пакетов по сети.
• Каждый профильный пакет содержит подписанный claim владельца: username, имя, описание, peerId, updatedAt, leaseExpiresAt, publicKey, signature.
• Захват чужого username блокируется проверкой подписи и активного lease. Если владелец не появляется в сети 14 дней, claim считается протухшим и username можно занять заново.
• Перенос на новый телефон делается через recovery bundle с ключами владельца: после импорта тот же пользователь может опубликовать прежний username уже с новым peerId.
• Карта сети строится как относительная топология связей, а не как GPS/геометрическая карта здания. Высота этажей пока не моделируется.

Сетевой пакет (черновик)

{
  "messageId": "uuid",
  "senderId": "device-or-user-id",
  "targetId": "user-or-group-id",
  "ttl": 6,
  "timestamp": 0,
  "type": "message|ack|presence|profile",
  "payload": "base64-or-json"
}

Ближайшие шаги

1. Укрепить transport: фрагментация крупных пакетов и более надёжный reconnect.
2. Ввести шифрование payload и подпись уже не только профильных, но и message-пакетов.
3. Добавить инструментальные BLE-тесты на нескольких устройствах и полевой прогон.