Checkpoint: первая рабочая версия звонков, сигналинг будет переделан

2026-05-02 18:13:22 +03:00
parent b05da86197
commit 310863faec
20 changed files with 572 additions and 37 deletions
@@ -0,0 +1,105 @@
+Дата: 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-блоков.