SHiNE-server/docs/Ответ_на_вопрос_о_блокчейне_каналах_и_расширяемости.md

Дата: 27.04.2026

Ответ по блокчейну, форматам, каналам и расширяемости

Короткий итог: текущую систему можно запускать и развивать дальше. Архитектура уже в целом готова к расширению версиями, но расширять нужно по строгим правилам совместимости.

1) Что важно зафиксировать про эволюцию форматов

Да, ваш подход верный:

• новые возможности добавляем через новые type/subType/version и/или новый frameCode;
• старые блоки не переписываем и не «переподписываем»;
• делаем конвертер/адаптер чтения: старые блоки читаются и приводятся к новой внутренней модели.

Это и есть правильная схема «старое автоматически читается и представляется в новом формате».

2) Есть ли в коде узкие места, где нельзя расширять

Критичных тупиков не видно, но есть важные ограничения:

• Парсер сейчас строгий: неизвестные type/subType/version и неизвестный frame отклоняются.
• Значит новые форматы нужно явно добавлять в парсер и серверную валидацию.
• Старые блоки без нужных полей не проблема, если новый код умеет читать их как legacy-ветку.

Вывод: расширение возможно, но только через явную поддержку версий, а не «само появится».

3) Про канал 0

Зафиксировано правило:

• канал 0 оставляем как технический root;
• контент-посты туда пока не публикуем.

Это теперь отмечено в коде комментариями и проверками:

• на клиенте (UI) пост в lineCode=0 блокируется с понятной ошибкой;
• на сервере добавлена валидация, которая тоже отклоняет TEXT_POST в канал 0.

4) Формат аватара (ava) — обновлено

Раньше:

• AR:<txId>

Теперь поддерживается составной формат:

• SHA256:<hash>,AR:<txId>

Что сделано:

• парсер и сборщик формата в UI обновлены;
• при загрузке нового аватара считается SHA-256 оптимизированного файла и сохраняется вместе с AR;
• при выборе существующего txId сначала качается файл, считается SHA-256, и только потом пишется ava;
• серверный граф связей теперь умеет извлекать AR из составной строки (включая fallback для legacy/кривых значений).

Это улучшает целостность: у вас есть не только адрес файла, но и контрольный хэш.

5) Как устроены ответы в каналах и насколько это надёжно

Ответы (REPLY / EDIT_REPLY) сделаны отдельно от линейных постов:

• REPLY хранит ссылку на цель (toBlockchainName + blockNumber + hash32) и текст;
• EDIT_REPLY хранит ссылку на оригинальный reply (blockNumber + hash32) и новый текст.

Сильные стороны:

• ссылка идёт по номеру + хэшу (устойчиво к подмене цели);
• редактирование отделено от оригинала и может агрегироваться в чтении.

Для будущего это расширяемо:

• можно добавить TEXT_REPLY_V2 с новым payload, сохранив V1 для старых клиентов.

6) Вложенные файлы и «мини-разметка» внутри сообщения

Идея рабочая, но лучше делать аккуратно.

Вариант A: «теги в тексте» (ваша идея)

Плюсы:

• быстро внедрить;
• стандартно для пользователей (похоже на HTML/Markdown).

Риски:

• экранирование < > и безопасность рендера;
• сложнее валидировать и безопасно отображать (XSS/инъекции).

Если идти этим путём, лучше:

• разрешить только whitelist-теги (img/file/h1/h2/h3/b/i и т.д.);
• хранить метаданные файла явно: type,size,sha256,ar;
• рендерить через безопасный парсер, а не через «сырой HTML».

Вариант B: структурированный payload (рекомендуется как основной)

Сделать TEXT_POST_V2:

• массив сегментов: text, image, file, heading, style;
• для файла хранить kind, mime, size, sha256, storage, address.

Плюс:

• надёжная валидация и безопасный рендер.

Оптимальная стратегия:

1. В UI можно дать «мини-разметку» для ввода.
2. На запись преобразовывать её в структурированный payload V2.
3. Для старых клиентов отдавать fallback plain text.

7) Практический roadmap без остановки разработки

1. Оставить текущий blockchain running.
2. Формально описать versioning policy (что считается breaking/non-breaking).
3. Зафиксировать channel 0 как технический root-only.
4. Использовать ava = SHA256 + AR как новый стандарт.
5. Запланировать TEXT_*_V2 для вложений и форматирования.

Итог: стартовать и развивать можно уже сейчас. Основа хорошая, если строго держать версионирование и адаптеры чтения для legacy-блоков.