# Типы блоков и сообщений 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).

Так получится и удобство, и проверяемость.