SHiNE-server/Типы_блоков_и_сообщений_SHiNE.md

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

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