Каналы: новый роутинг, поиск, вход-возврат, удаление просмотров и документация

2026-05-08 01:15:54 +03:00
parent 6774c26ea1
commit acdd6c928b
18 changed files with 657 additions and 458 deletions
@@ -0,0 +1,141 @@
+# Типы блоков и сообщений SHiNE (карта протокола)
+
+## 1) Главный принцип
+
+В блокчейн попадают только записи `AddBlock` (подписанные бинарные блоки).  
+Все остальное (например, call signaling, push-события, служебные JSON-операции) — не блокчейн-данные.
+
+---
+
+## 2) Базовые `msg_type`
+
+## `msg_type=0` — TECH
+
+- `subType=0` — `HEADER_COMPAT` (техническая совместимость);
+- `subType=1` — `TECH_CREATE_CHANNEL` (создание канала).
+
+Используется для структуры каналов.
+
+## `msg_type=1` — TEXT
+
+- `10` — `TEXT_POST` (пост в линии канала);
+- `11` — `TEXT_EDIT_POST` (правка поста);
+- `20` — `TEXT_REPLY` (ответ на сообщение через target);
+- `21` — `TEXT_EDIT_REPLY` (правка ответа).
+
+Это основной контент каналов и тредов.
+
+## `msg_type=2` — REACTION
+
+- `1` — `REACTION_LIKE`;
+- `2` — `REACTION_UNLIKE`.
+
+Лайки/снятие лайка, считаются через state-триггеры и/или агрегации.
+
+## `msg_type=3` — CONNECTION
+
+Связи между пользователями (friend/contact/follow/spouse/parent/child/sibling + обратные UN*).
+
+Используется для соцграфа и подписок:
+
+- `FOLLOW/UNFOLLOW` — подписки на авторов/каналы.
+
+## `msg_type=4` — USER_PARAM
+
+Ключ-значение параметра пользователя (profile / тех.параметры / fallback-метаданные).
+
+Пример для каналов: fallback-описание `channel_desc:...`.
+
+---
+
+## 3) Что **не** является блокчейн-типом
+
+Ниже операции есть в протоколе, но не через `AddBlock`:
+
+- `CallInviteBroadcast`, `CallSignalToSession` (сигналинг звонков),
+- `SendDirectMessage`, `ReceiveIncomingMessage`, `ReceiveOutcomingMessage`,
+- `AckSessionDelivery`, `UpsertPushToken`, `SendTestWebPush`,
+- системные `Ping`, `GetServerInfo`, логи и т.п.
+
+Это JSON-операции поверх WS/серверной логики.
+
+---
+
+## 4) Формат блока (высокоуровнево)
+
+Блок включает:
+
+1. preimage (header + body),
+2. `sigMarker`,
+3. `signature64`.
+
+`hash32 = SHA-256(preimage)`, подпись Ed25519 проверяется сервером при `AddBlock`.
+
+Ключевые проверки на сервере:
+
+- `blockNumber == last + 1`,
+- `prevHash` совпадает с последним хэшем цепочки,
+- body валиден по типу/версии/subtype,
+- подпись корректна.
+
+---
+
+## 5) Где и как это используется в UI
+
+## Уже активно
+
+- создание канала (`TECH_CREATE_CHANNEL`);
+- пост в канал (`TEXT_POST`);
+- ответ (`TEXT_REPLY`);
+- лайк/анлайк (`REACTION_*`);
+- follow/unfollow через connection-блоки.
+
+## Частично готово на API, но не доведено в UI
+
+- отображение полной истории правок (`versions[]` есть в API, но UI показывает не полностью как отдельный workflow);
+- редактирование поста/ответа (типы в протоколе есть, UI-сценарий не завершен);
+- удаление сообщений отсутствует как тип.
+
+---
+
+## 6) Про “AI сообщения”
+
+Отдельного `msg_type/subType` “AI message” в текущем протоколе нет.  
+Если нужно, это обычно делают либо:
+
+- как новый `TEXT_*` subtype (если это контент канала),
+- либо как отдельный новый `msg_type` (если нужна независимая семантика/правила).
+
+---
+
+## 7) Почему в UI виден JSON, а не “сырой блок”
+
+Текущий read-path сделан так:
+
+- сервер читает блоки из БД;
+- парсит и собирает удобное JSON-представление;
+- UI рендерит его как сообщения/треды.
+
+Плюсы:
+
+- проще и быстрее для интерфейса;
+- не дублируется сложная логика парсинга блоков на клиенте.
+
+Минусы:
+
+- клиент не делает локальную крипто-верификацию каждого прочитанного элемента.
+
+При необходимости можно добавить режим “raw block view” и верификацию на клиенте как отдельный экспертный экран.
+
+---
+
+## 8) Рекомендация по UX/протоколу
+
+Для обычного пользователя лучше оставить “UI-сообщения” (читаемо и быстро).  
+Для аудита/доверия имеет смысл добавить отдельный режим:
+
+- показать `blockNumber/hash/signature`,
+- показать все версии,
+- кнопка “проверить подпись локально” (advanced).
+
+Так получится и удобство, и проверяемость.