Отключить репосты и добавить Solana-модуль

This commit is contained in:
AidarKC
2026-05-24 12:16:39 +03:00
parent abdce05136
commit 56cd90a197
95 changed files with 24261 additions and 64 deletions
@@ -0,0 +1,93 @@
# Репосты в каналах и тредах
- Статус:
`future`
- Решение от 2026-05-24:
Репосты временно убраны из активной разработки. Фича уже была частично реализована, но не доведена до финальной проверки. Чтобы она не мешала запуску проекта, пользовательский вход в репосты отключён в UI, а сервер больше не принимает новые `TEXT_REPOST` через `AddBlock`.
## Что должна делать фича
Репост должен позволять взять сообщение из канала или треда и опубликовать его в один из своих каналов с комментарием.
Ожидаемый пользовательский сценарий после возврата к задаче:
1. Пользователь открывает сообщение в канале или треде.
2. Нажимает `Репост`.
3. Выбирает один из своих каналов.
4. Добавляет комментарий.
5. Отправляет репост.
6. В целевом канале появляется новый пост-репост.
7. У репоста есть переход к исходному сообщению через действие `Оригинал`.
## Что уже есть в коде
- В блокчейн-формате зарезервирован и описан подтип `TEXT_REPOST (30)`.
- Парсер блокчейна умеет распознавать тело репоста как `TextLineBody`.
- В UI есть функция сборки тела репоста:
`shine-UI/js/services/auth-service.js`, `makeTextRepostBodyBytes`.
- В UI есть клиентская операция:
`shine-UI/js/services/auth-service.js`, `addBlockRepost`.
- В экране канала был обработчик репоста:
`shine-UI/js/pages/channel-view.js`, `onRepost`.
- В экране треда был обработчик репоста:
`shine-UI/js/pages/channel-thread-view.js`, `onRepost`.
- Серверная выдача каналов и тредов частично учитывает `TEXT_REPOST` и target-поля:
`targetBlockchainName`, `targetBlockNumber`, `targetBlockHash`.
- В списке подписок `TEXT_REPOST` считается публикацией канала.
## Что сейчас отключено
- В `shine-UI/js/pages/channel-view.js` кнопка `Репост` больше не создаётся и не добавляется в список действий сообщения.
- В `shine-UI/js/pages/channel-thread-view.js` кнопка `Репост` больше не создаётся и не добавляется в список действий ответа/сообщения треда.
- В `shine-server-net-protocol/src/main/java/server/logic/ws_protocol/JSON/handlers/blockchain/Net_AddBlock_Handler.java` добавлена явная временная блокировка:
если новый блок имеет `type=1` и `subType=TEXT_REPOST (30)`, `AddBlock` возвращает ошибку `repost_disabled`.
## Что осталось активным намеренно
- Константа `TEXT_REPOST (30)` остаётся в коде и документации как зарезервированный формат.
- Парсер блокчейна продолжает знать формат `TEXT_REPOST`, чтобы не потерять уже написанную основу и не ломать потенциальное чтение старых тестовых данных.
- Код формирования репоста в `auth-service.js` не удалён: его можно будет использовать как основу при возвращении к задаче.
- Код отображения target-полей и перехода к оригиналу не удалён: он нужен для будущей проверки и возможной совместимости с уже созданными тестовыми блоками.
## Почему это не лежит в Pending_Features
`Dev_Docs/Pending_Features/` предназначена для фич, которые уже реализованы и ждут ручной проверки.
Репосты сейчас не подходят под этот статус: они не должны проверяться как готовая фича, потому что пользовательский сценарий временно закрыт, а серверная запись новых репостов заблокирована. Поэтому старый pending-файл удалён, а задача перенесена сюда как будущая.
## Что сделать при возврате к реализации
1. Решить, остаётся ли формат `TEXT_REPOST (30)` финальным.
2. Если формат меняется, заранее предупредить пользователя и получить отдельное подтверждение на изменение блокчейн-формата.
3. Вернуть UI-кнопки репоста в:
- `shine-UI/js/pages/channel-view.js`;
- `shine-UI/js/pages/channel-thread-view.js`.
4. Снять временную блокировку `repost_disabled` в:
`shine-server-net-protocol/src/main/java/server/logic/ws_protocol/JSON/handlers/blockchain/Net_AddBlock_Handler.java`.
5. Проверить `auth-service.js`:
- `makeTextRepostBodyBytes`;
- `addBlockRepost`;
- актуализацию вершины блокчейна перед `AddBlock`;
- корректность target-полей исходного сообщения.
6. Проверить серверное чтение:
- `GetChannelMessages`;
- `GetMessageThread`;
- отображение `targetBlockchainName`, `targetBlockNumber`, `targetBlockHash`.
7. Добавить или обновить тесты на успешный репост и отказ некорректных target-полей.
8. Обновить документацию:
- `Dev_Docs/Blockchain/11_TEXT_Blocks.md`;
- `Dev_Docs/Blockchain/CHANGELOG.md`;
- `Dev_Docs/API/04_Add_Block_to_Blockchain_API.md`;
- документы API чтения каналов/тредов, если изменятся поля ответа.
9. После реализации перенести задачу из `Dev_Docs/Future_Features/` в `Dev_Docs/Pending_Features/` как фичу, требующую ручной проверки.
## Минимальный чек-лист ручной проверки в будущем
1. Репост из сообщения канала в свой канал.
2. Репост из ответа в треде в свой канал.
3. Ошибка при попытке репоста в чужой канал.
4. Переход `Оригинал` из репоста к исходному сообщению.
5. Корректное отображение комментария к репосту.
6. Корректная работа после перезагрузки страницы.
7. Отсутствие поломки обычных постов, ответов, лайков и отправки ссылки.
+14
View File
@@ -0,0 +1,14 @@
# Будущие фичи
Эта папка хранит задачи, которые сознательно отложены и сейчас не должны попадать в активную разработку или ручную проверку.
## Как использовать
1. Каждая будущая фича описывается отдельным markdown-файлом.
2. В файле нужно фиксировать:
- зачем нужна фича;
- что уже было сделано в коде;
- что временно отключено или закомментировано;
- какие документы нужно обновить при возврате к задаче;
- с какого места продолжать разработку.
3. Агент не должен начинать реализацию файлов из этой папки без явной просьбы пользователя.