Aidar/SHiNE-server
SHA256
2
0
Fork 0
Code Issues Pull Requests 1 Actions Packages Projects Releases Wiki Activity
74df7e2645
SHiNE-server/docs/Ответ_на_вопрос_о_блокчейне_каналах_и_расширяемости.md

6.7 KiB
Raw Blame History

Дата: 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-блоков.