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