SHA256
AidarKC
8a0275d962
Что сделано: вычистили неиспользуемый user-settings sync/DM sync хвост, сохранили сборку, обновили bundle.sh так, чтобы gradle-wrapper.jar всегда попадал в архив. Проверено: compileJava и deploy на t2 (server + UI). Не проверяли: полные интеграционные сценарии, ручные UI-флоу и продовый деплой.
Документация блокчейна SHiNE (MVP)
Этот каталог описывает только текущий рабочий формат протокола для MVP.
Основные документы
- 01_Common_Block_Format.md Единый бинарный формат блока (Frame v0), подпись, базовые проверки.
- 02_Blockchain_Kinds_and_Lines.md Виды цепочек и правила line-полей.
- 10_TECH_Blocks.md
Системные блоки (
msg_type=0). - 11_TEXT_Blocks.md
Текстовые блоки (
msg_type=1). - 12_REACTION_Blocks.md
Реакции (
msg_type=2). - 13_CONNECTION_Blocks.md
Социальные связи (
msg_type=3). - 14_USER_PARAM_Blocks.md
Параметры пользователя (
msg_type=4). - 15_STATUS_ACTION_Blocks.md
Статусные действия пользователя (
msg_type=5). - 16_TEXT_Attachments.md
Вложения в TEXT-сообщениях через
S:att v=1, включая опциональныеpreAr/preSha256для видео и крупных изображений. - 16_TEXT_Channel_Meta.md
Скрытый
TEXT_CHANNEL_METAдля профиля канала. - 01_Channel_Types_and_CreateChannel.md
Типы каналов и формат
CreateChannelBody. - 02_Channel_Commands.md Команды в текстовых сообщениях каналов.
- CHANGELOG.md Журнал изменений документации.
Смежная документация
- ../ИТХ/README.md — ежедневное закрытие блокчейна (ИТХ): краткий обзор.
- ../ИТХ/Спецификация_ИТХ_v1.md — точная спецификация чекпоинтов (Arweave/Solana/канал закрытий).
- sync-between-servers.md — живая межсерверная синхронизация блокчейна и доставка DM на единственный сервер получателя.
Важные ограничения MVP
- Каналы
type=100иtype=200присутствуют в формате, но сейчас не используются в UI. - Поддерживаемый рабочий сценарий UI на текущем этапе:
stories (type=0)иpublic (type=1).
Обязательное сопровождение
- При любом изменении формата/правил блокчейна в коде документы этого каталога обновляются в том же наборе изменений.
- Обычный
AddBlockсейчас пишет через<blockchainName>.tmp_bch,<blockchainName>.write_checkи<blockchainName>.write_pending; эта схема иBlockchainTmpRecoveryOnStartupдолжны быть описаны в актуальной документации по синхронизации и recovery. - Для runtime-агрегатов статистики
user_stats_stateиchannel_stats_stateдействует тот же принцип derived state: они обновляются вместе сAddBlockи полностью пересобираются при full resync. - Если в старых данных есть канал владельца, которого ещё нет в
solana_user_pda_current, сервер не падает:channel_stats_stateвсё равно обновляется, аuser_stats_stateсоздаётся только после появления пользователя в Solana PDA. - Каждое обновление документов фиксируется в
CHANGELOG.mdс датой/временем и хэшем коммита-основания.