142 lines
5.5 KiB
Markdown
142 lines
5.5 KiB
Markdown
# Типы блоков и сообщений 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 / тех.параметры).
|
||
|
||
Для описаний каналов `USER_PARAM` больше не используется: описание хранится только в `CreateChannelBody v2`.
|
||
|
||
---
|
||
|
||
## 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).
|
||
|
||
Так получится и удобство, и проверяемость.
|