From c397c28acb1dbe4d3a454bae6eaee7ec03420b99e266023f0692d971932ae3eb Mon Sep 17 00:00:00 2001 From: AidarKC Date: Sun, 28 Jun 2026 10:29:27 +0400 Subject: [PATCH] =?UTF-8?q?=D0=A3=D0=B4=D0=B0=D0=BB=D0=B8=D1=82=D1=8C=20?= =?UTF-8?q?=D1=81=D1=82=D0=B0=D1=80=D1=8B=D0=B9=20=D0=BC=D1=83=D1=81=D0=BE?= =?UTF-8?q?=D1=80=20=D0=B8=D0=B7=20=D0=B4=D0=BE=D0=BA=D1=83=D0=BC=D0=B5?= =?UTF-8?q?=D0=BD=D1=82=D0=B0=D1=86=D0=B8=D0=B8?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- DAO_запуск/README.md | 255 ------------------ ...ODO что бы не забыть - для после выходных | 62 ----- DOC/TODO то что пока отложенно на будущее.md | 10 - DOC/doc_all_libs.md | 22 -- DOC/Описание БД.md | 209 -------------- DOC/Протокол звонков (MVP).md | 75 ------ DOC/Что недоделано. И потом надо доделать | 9 - Deploy Server/servers-inventory.md | 53 ---- Dev_Docs/Future_Features/README.md | 13 - Dev_Docs/Future_Features/far/README.md | 8 - .../2026-06-20_1839_registration_faq_and_12_words.md | 0 .../2026-06-20_2350_test_free_avatar_upload.md | 0 ...2026-06-24_1825_unified_channels_list_without_stories.md | 0 .../2026-06-26_1500_addblock_tmp_bch_recovery.md | 0 .../2026-06-26_1745_proverka_avariynykh_ostanovok.md | 0 ...аботка_персональных_сообщений_для_агентов.md | 42 --- VERSION.properties | 4 +- 17 files changed, 2 insertions(+), 760 deletions(-) delete mode 100644 DAO_запуск/README.md delete mode 100644 DOC/!!! TODO что бы не забыть - для после выходных delete mode 100644 DOC/TODO то что пока отложенно на будущее.md delete mode 100644 DOC/doc_all_libs.md delete mode 100644 DOC/Описание БД.md delete mode 100644 DOC/Протокол звонков (MVP).md delete mode 100644 DOC/Что недоделано. И потом надо доделать delete mode 100644 Deploy Server/servers-inventory.md delete mode 100644 Dev_Docs/Future_Features/README.md delete mode 100644 Dev_Docs/Future_Features/far/README.md rename Dev_Docs/Pending_Features/{ => вроде сделанное}/2026-06-20_1839_registration_faq_and_12_words.md (100%) rename Dev_Docs/Pending_Features/{ => вроде сделанное}/2026-06-20_2350_test_free_avatar_upload.md (100%) rename Dev_Docs/Pending_Features/{ => вроде сделанное}/2026-06-24_1825_unified_channels_list_without_stories.md (100%) rename Dev_Docs/Pending_Features/{ => вроде сделанное}/2026-06-26_1500_addblock_tmp_bch_recovery.md (100%) rename Dev_Docs/Pending_Features/{ => вроде сделанное}/2026-06-26_1745_proverka_avariynykh_ostanovok.md (100%) delete mode 100644 Dev_Docs/Personal_Messages/TODO_доработка_персональных_сообщений_для_агентов.md diff --git a/DAO_запуск/README.md b/DAO_запуск/README.md deleted file mode 100644 index 6969f65..0000000 --- a/DAO_запуск/README.md +++ /dev/null @@ -1,255 +0,0 @@ -# DAO_запуск - -Рабочий документ по тому, что ещё нужно сделать для первого запуска DAO-сценария SHiNE. - -Логика документа: - -- `этап1` — то, без чего нельзя считать сценарий первого запуска собранным даже в тестовом виде; -- `этап2` — то, что полезно и, вероятно, потребуется дальше, но это можно делать после старта `этап1` или параллельно без блокировки первого результата. - -Базовая среда первого прохода: - -- сеть `Solana devnet`; -- модель синхронизации: `server-to-server`; -- `Solana + Arweave` используются как якорь и архив; -- DAO понимается как стандартный governance/smart-contract контур, который управляет отдельными программами SHiNE, приносящими деньги. - -## Краткий вывод - -Для первого запуска DAO в тестовом виде текущего списка в целом хватает, но только если понимать запуск как: - -- можно развернуть и проверить базовый DAO-контур; -- можно зарегистрировать пользователей и ключевые сущности; -- можно провести тестовую покупку билета через smart contract; -- можно завести тестовый денежный поток в программы, управляемые DAO; -- можно проверить опорную межсерверную синхронизацию и фиксацию состояния в архивный слой. - -Если же под "запуском" понимать уже полностью устойчивую production-схему с ротацией ключей, восстановлением любого сервера из архива, железными устройствами подписи и полным циклом администрирования, то текущий список нужно будет ещё расширять. - -## Этап1 - -Цель этапа: собрать минимально жизнеспособный DAO-сценарий в `devnet`, который можно пройти руками от регистрации до базовой экономики и проверки архитектуры. - -### 1. Переписать и стабилизировать регистрацию пользователей без Anchor - -Что сделать: - -- довести `shine_users` в чистом Rust/Solana SDK до рабочего и проверенного состояния; -- убедиться, что `shine_login_guard` и связанный сценарий регистрации совместимы с новым ABI; -- проверить создание и чтение `user_pda`; -- проверить update пользовательской записи и связанные экономические параметры; -- синхронизировать сервер, UI и lazy-import с новым форматом и seed'ами. - -Почему это в `этап1`: - -- без стабильной пользовательской регистрации дальше нельзя строить ни DAO-сценарий, ни привязку устройств, ни платёжные сценарии. - -### 2. Проверить полный сценарий регистрации и базовой Solana-интеграции - -Что сделать: - -- руками прогнать регистрацию нового пользователя; -- руками прогнать создание и update server PDA там, где это требуется текущему сценарию; -- убедиться, что сервер читает новые PDA без anchor-зависимостей и без старых discriminator'ов; -- зафиксировать, какие именно части сценария уже подтверждены руками, а какие ещё нет. - -Почему это в `этап1`: - -- сейчас в проекте уже есть признаки перехода на pure Rust, но без ручной проверки это нельзя считать завершённым. - -### 3. Создать стандартный DAO smart contract / governance-контур - -Что сделать: - -- определить и реализовать стандартный DAO-контур, который будет управлять программами SHiNE; -- зафиксировать, какие права сразу передаются DAO, а какие временно остаются на отдельных ключах; -- подготовить тестовую DAO-структуру в `devnet`. - -Минимум для первого запуска: - -- DAO существует как управляемая сущность; -- DAO может владеть или контролировать ключевые права управления денежными программами; -- есть понятный путь, как DAO влияет на доходные программы SHiNE. - -Почему это в `этап1`: - -- без этого "DAO-запуск" будет только запуском отдельных Solana-программ, но не запуском управляемой DAO-системы. - -### 4. Доработать смарт-контракт выплат с третьей очередью - -Что сделать: - -- добавить в `shine_payments` третью очередь, о которой уже принято решение; -- проверить совместимость с текущей моделью тикетов, выплат и DAO-управления; -- убедиться, что логика очередей соответствует ожидаемой экономике проекта. - -Почему это в `этап1`: - -- по текущей постановке это нужно именно для сценария регистрации DAO и дальнейшей экономики. - -### 5. Сделать UI для покупки билетов и просмотра очереди - -Что сделать: - -- добавить UI-сценарий покупки билетов через smart contract; -- показать пользователю, сколько перед ним человек в очереди; -- убедиться, что UI отражает актуальное состояние контрактной логики, а не локальные предположения. - -Почему это в `этап1`: - -- покупка билетов у тебя обозначена как часть DAO-сценария, а не как побочная функция; -- без UI можно тестировать контракт вручную, но нельзя считать сценарий запуска достаточно собранным для нормальной проверки. - -### 6. Реализовать базовую синхронизацию серверов - -Что сделать: - -- сделать обмен состоянием между серверами по модели `server-to-server`; -- определить минимальный набор данных, который обязан синхронизироваться; -- предусмотреть фиксацию синхронизированного состояния в `Arweave`, а `Solana` использовать как якорь и ссылочный слой; -- описать, какой сервер считается источником истины в спорных случаях или как решается конфликт. - -Почему это в `этап1`: - -- без межсерверной синхронизации трудно обосновать архитектуру сети как воспроизводимую и переносимую; -- это напрямую связано с идеей, что любой сможет поднять свой сервер. - -### 7. Подготовить базовый сценарий архивирования и восстановления - -Что сделать: - -- описать и частично реализовать схему: серверы синхронизируются между собой, архив состояния уходит в `Arweave`, ссылка/якорь фиксируется через `Solana`; -- определить минимальный сценарий восстановления блоков или состояния из архивного слоя; -- подтвердить, что новый сервер может получить достаточно данных для старта. - -Почему это в `этап1`: - -- это один из ключевых признаков независимой и воспроизводимой DAO-инфраструктуры. - -## Этап2 - -Цель этапа: усилить безопасность, автономность и удобство системы после того, как минимальный DAO-сценарий уже запустился и проверен в `devnet`. - -### 1. Смена ключей цифровой подписи - -Что сделать: - -- продумать и реализовать смену `root key`, `client key`, `blockchain key`; -- описать ограничения, кто и в каком сценарии может менять каждый тип ключа; -- продумать, как не потерять доступ и как обновлять доверие к новым ключам. - -Почему это в `этап2`: - -- для production это очень важно; -- для первого тестового запуска можно временно использовать фиксированный набор ключей. - -### 2. Полная повторная перепроверка всех сценариев - -Что сделать: - -- повторно прогнать регистрацию, DAO, выплаты, билеты, синхронизацию и архивирование после стабилизации `этап1`; -- оформить итоговый чек-лист ручной проверки; -- отдельно проверить пограничные сценарии и восстановление после ошибок. - -Почему это в `этап2`: - -- это обязательный шаг перед переходом от "собрали" к "доверяем". - -### 3. Устройство на ESP32 как homeserver с ключами - -Что сделать: - -- дописать прошивку, чтобы устройство могло выступать homeserver с ключами; -- дать ему возможность регистрироваться и подключаться к серверу; -- определить, какие операции устройство подписывает и где хранит ключевой материал. - -Почему это в `этап2`: - -- это очень сильное развитие архитектуры, но оно не должно блокировать первый DAO-запуск. - -### 4. Логин и подпись через коробочки / устройства - -Что сделать: - -- реализовать сценарий входа через устройство или хотя бы сценарий подписи сообщений и ключей через устройство; -- определить, как это встраивается в регистрацию DAO и подтверждение действий; -- проверить, можно ли через это безопасно регистрировать DAO или подписывать критичные команды. - -Почему это в `этап2`: - -- это следующий уровень безопасности и UX, но не минимальный блокер первого старта. - -### 5. Создание тестового DAO с использованием устройств подписи - -Что сделать: - -- после готовности устройств собрать тестовый DAO-сценарий уже с аппаратным участием; -- проверить, где устройство достаточно, а где всё ещё нужен обычный кошелёк или управляющий ключ. - -Почему это в `этап2`: - -- это проверка усиленной модели, а не базового старта. - -### 6. Расписание синхронизации серверов - -Что сделать: - -- определить периодичность и правила фоновой синхронизации; -- продумать ручной и автоматический режим; -- решить, как часто публиковать архивные снимки и якоря. - -Почему это в `этап2`: - -- сначала важнее добиться самой работающей синхронизации, а потом уже делать её регулярной и автономной. - -### 7. Полное восстановление блоков из Solana/Arweave - -Что сделать: - -- довести процедуру восстановления до сценария "любой может поднять свой сервер"; -- определить минимальный bootstrap-набор; -- проверить восстановление на чистом окружении. - -Почему это в `этап2`: - -- для концепции сети это критично, но как полноценная задача обычно идёт после появления базового архива и первичной синхронизации. - -## Что блокирует первый запуск сильнее всего - -Если расставить приоритет внутри `этап1`, то самый жёсткий порядок сейчас выглядит так: - -1. pure Rust регистрация пользователей и ручная проверка сценария; -2. DAO/gov-контур и его права управления; -3. доработка выплат с третьей очередью; -4. покупка билетов через smart contract и UI-проверка очереди; -5. межсерверная синхронизация; -6. архивирование в `Arweave` с якорем в `Solana`; -7. минимальное восстановление состояния новым сервером. - -## Что уже частично похоже на готовое - -По текущим документам и следам в проекте уже видно, что: - -- переход `shine_users` и `shine_login_guard` на pure Rust уже начат и в значительной степени сделан; -- архитектура DAO, `shine_users` и `shine_payments` уже описана; -- часть Solana-структуры и PDA-форматов уже формализована; -- тема ESP32 уже отдельно присутствует в проекте как направление. - -Это хорошо, потому что документ получается не "с нуля", а как сборка того, что уже назрело в коде и планах. - -## Вопросы, которые всё ещё стоит уточнить - -1. Какой именно стандарт DAO планируется использовать в первом проходе: готовый governance-стек Solana или собственная минимальная обвязка вокруг управляющих кошельков? -2. Третья очередь в `shine_payments` уже точно определена по смыслу, или пока есть только решение "она нужна", но без финальной экономики? -3. Что именно считается единицей синхронизации между серверами: блоки SHiNE, агрегированные снапшоты, PDA-состояния, или смесь этих вариантов? -4. Нужен ли для `этап1` уже полноценный автоматический recovery нового сервера, или достаточно доказать это в полу-ручном сценарии? -5. Покупка билетов должна в первом проходе работать только через web/UI, или также нужен отдельный сценарий из серверного UI или скриптов? - -## Рекомендуемый следующий практический шаг - -Если идти без распыления, то следующим рабочим фокусом стоит считать: - -1. закрыть ручную проверку pure Rust регистрации; -2. после этого формализовать минимальный DAO-контур; -3. затем переходить к третьей очереди выплат и к UI покупки билетов; -4. после этого делать синхронизацию, архив и восстановление. diff --git a/DOC/!!! TODO что бы не забыть - для после выходных b/DOC/!!! TODO что бы не забыть - для после выходных deleted file mode 100644 index af96b91..0000000 --- a/DOC/!!! TODO что бы не забыть - для после выходных +++ /dev/null @@ -1,62 +0,0 @@ -0. ПЕРЕДЕЛАТЬ ВСЁ НА НОВЫЙ ФОРМАТ!! - -ВЫНЕСТИ ЭТИ ТРИ ВЕЩИ В ОБЩИЙ ПАРСЕР - * [2] type - тип соощения - * [2] Sиbtype - субтип сообщения - * [2] version - версия формата соощения - -А ОСТАЛЬНОЕ В РЕАЛИЗАЦИЮ - - -ПЕРЕДЕЛАЕМ БД - -1. СДЕЛАЕМ ЛИНИЮ ТОЛЬКО ДЛЯ ТЕХ ТИПОВ КОМУ НАДО (ЛАЙКАМ И ОТВЕТАМ НЕ НАДО) - (НОМЕР СООБЩЕНИЯ В ЛИНИИ ХРАНИТЬ В БЛОКАХ ВРОДЕ И НЕ НАДО ТЕМ БОЛЕЕ ЕГО ПОТОМ ПЕРЕПРОВЕРЯТЬ ВСЁ РАВНО) - А МОЖЕТ И НАДО ТК КАК ПО ОДНОМУ БЛОКУ ( ИЛИ ЧАСТИ БЛОКОВ ПОНЯТЬ КАКАЯ ЭТО ЧАСТЬ ПЕРЕПИСКИ - ВЕДЬ ГЛОБАЛ НОМЕР ВООБЩЕ НЕ ПОКАЗАТЕЛЬ) - - В БД ПОМЕЧАТЬ ЧТО БЛОК ИЗ ЭТОЙ ЛИНИИ (ДЛЯ БЫСТРОГО ПОИСКА) - -А УНИКАЛЬНЫЙ НОМЕР ЛИНИИ ЭТО ПО СУТИ НОМЕР СООБЩЕНИЯ СОЗДАВШЕГО ЛИНИЮ КАНАЛ (НУ И ФОРМАТ СООБЩЕНИЯ НАЧАЛА ЛИНИИ - КАНАЛА) - - - - - - - - - - - - -3. СООТВЕТСТВЕННО удалить НАПИСАТЬ/ПЕРОВЕРИТЬ НОРМАЛЬНЫЙ SubscriptionsDAO - ТК СТАРЫЙ РАБОТАЛ НО НА ДРУГОМ ФОРМАТЕ И ТИПО КРИВО - -и дальше: -ЗДЕЛАТЬ ТРИ ЗАПРОСА: - СПИСОК КАНАЛОВ НА КОГО ПОДПИСАН И ПО СКОЛЬКО СООБЩЕНИЙ И ПОСЛДНИЙ ТЕКСТ - ДОДЕЛАТЬ И СВЯЗ ПОДПИСАН УЖЕ НЕ ТОЛЬКО НА ЧЕЛА НО И НА КАНАЛ. (И ПОЛУЧАЕТСЯ ЕСТЬ ОБЩИЙ КАНАЛЛ ПОСТОВ (НО НЕКОТОРЫЕ ПОСТЫ В НИКУДА- - А НЕКОТОРЫЕ ПОСТЫ ОБЪЯВЛЕНИЕ КАНАЛА - - СПИСОК СООБЩЕНИЙ В КАНАЛЕ - - ОПСИСАНИЕ ОДНОГО СОООБЩЕНИЯ (С ИСТОРИЕЙ ДО НАЧАЛА ВЕТКИ И СО ВСЕМИ ОТВЕТАМИ НА НЕГО) - - (НУ И В БУДУЩЕМ четвёртый ИСТОРИЮ сообщения ПО ЕДИТУ) - - -И ПОМЯТКА - ВСЕГДА СЧИТАЕМ ПО ПОСЛЕДНЕМУ БЛОКЧЕЙНУ ДОСТУПНОМУ ПОЛЬЗОВАТЕЛЮ - ХОТЯ ССЫЛКА ПО НОМЕРУ БЛОКЧЕЙНА КУДА ДОБАВИЛИ - - ЛАЙКИ И ОТВЕТЫ ПИШЕМ НА НОМЕР СООБЩЕНИЯ ЕДИТА - (СЧИТАЕМ ТРИГЕРОМ И НА ОРИГИНАЛЬНЫЙ СУМАРНОЕ И ОТДЕЛЬНО НА НЕГО, И НА КАЖДЫЙ ЕДИТ ОТДЕЛЬНО) - - ОТВЕТЫ ПОКАЗЫВАЕМ ВСЕ ВРАЗ - - - - - - - - diff --git a/DOC/TODO то что пока отложенно на будущее.md b/DOC/TODO то что пока отложенно на будущее.md deleted file mode 100644 index 7eb9828..0000000 --- a/DOC/TODO то что пока отложенно на будущее.md +++ /dev/null @@ -1,10 +0,0 @@ -Сделать возможность убрать свой лайк. (пока не надо а сложность что надо больше проверок) - хотя можно и без проверки, просто за двойной лайк или за снятие двойное лайка. Будет двойное проникновение :)) тому кто изменил код клиента и убрал проверку на клиенте - и блокчейн заблокируется и всё. -поэтому просто на каждую реакцию добавиться убрать эту ракцию . -- это просто - -сделатьпотом что бы в солану_юзерс хранилось имя текущего блокчейна пользователя. Что бы потом можно было грузить именно актуальный ТО ЕСТЬ потом можно будет менять блокченый! - - - - -сделать сессион пасворд тоже ключём подписи устройства!! \ No newline at end of file diff --git a/DOC/doc_all_libs.md b/DOC/doc_all_libs.md deleted file mode 100644 index 12d8aa3..0000000 --- a/DOC/doc_all_libs.md +++ /dev/null @@ -1,22 +0,0 @@ -Перечень библиотек и их краткое описание - -shine-server-log -Статический “сиренный” метод для максимально заметного критического лога администратору - -shine-server-config -Минимальный конфиг-лоадер, который один раз читает application.properties и даёт доступ к параметрам. - -shine-server-geo -Утилиты, которые вытаскивают IP/язык/UA из Jetty WebSocket и (опционально) резолвят гео по IP с кэшем в БД. - -shine-server-crypto -Базовые крипто-утилиты для SHA-256 и Ed25519 (BouncyCastle) + проверка подписи/хэша для .bch сущностей и маленький self-test. - -shine-server-bd -Библиотека реалезующая всю работу с БД: - -shine-server-blockchain -Библиотека, которая задаёт единый бинарный формат блоков (RAW+signature+hash), парсит/валидирует “тело” блока по type/version, и проверяет целостность/подпись цепочки через SHA-256 + Ed25519 с привязкой к login и предыдущим хэшам. - -shine-server-protocol -Библиотека JSON-протокол поверх WebSocket для взаимодействия с клиентами. diff --git a/DOC/Описание БД.md b/DOC/Описание БД.md deleted file mode 100644 index 684098a..0000000 --- a/DOC/Описание БД.md +++ /dev/null @@ -1,209 +0,0 @@ -SHiNE — структура БД (актуальная версия) - -Перечень таблиц и назначение - -solana_users -Справочник пользователей: логин + ключ устройства + (опционально) Solana-ключ. -Базовая таблица, используется как FK почти везде. - -active_sessions -Активные сессии авторизации/работы клиента: секреты, тайминги, WebPush-данные, IP и информация о клиенте. - -users_params -Хранилище актуальных параметров пользователя. -Для каждой пары (login, param) хранится только самая новая версия по time_ms. - -ip_geo_cache -Кеш геолокации по IP для снижения нагрузки на внешние сервисы. - -blockchain_state -Агрегированное состояние блокчейна по blockchain_name: -лимиты, текущий размер, последний глобальный блок и состояние линий 0..7. - -blocks -Журнал всех блоков и сообщений. -Содержит историю событий: тексты, реакции, ответы, связи. -PRIMARY KEY намеренно отсутствует. - -connections_state ⭐ -Актуальное состояние связей между пользователями -(друг / контакт / подписка). -Обновляется автоматически на основе событий из blocks. - -message_stats ⭐ -Агрегированные счётчики лайков и ответов на конкретные сообщения. -Поддерживается триггерами из blocks. - -Таблицы подробно - -solana_users -login — TEXT PK — уникальный логин пользователя -client_key — TEXT NOT NULL — публичный ключ устройства (Base64(32) / HEX(64)) -solana_key — TEXT NULL — публичный ключ Solana-аккаунта - -active_sessions -session_id — TEXT PK — идентификатор сессии -login — TEXT NOT NULL, FK → solana_users(login) -session_pwd — TEXT NOT NULL — секрет сессии -storage_pwd — TEXT NOT NULL — секрет storage -session_created_at_ms — INTEGER NOT NULL -last_authirificated_at_ms — INTEGER NOT NULL -push_endpoint — TEXT NULL -push_p256dh_key — TEXT NULL -push_auth_key — TEXT NULL -client_ip — TEXT NULL -client_info_from_client — TEXT NULL -client_info_from_request — TEXT NULL -user_language — TEXT NULL - -users_params -login — TEXT NOT NULL, FK → solana_users(login) -param — TEXT NOT NULL -time_ms — INTEGER NOT NULL -value — TEXT NOT NULL -client_key — TEXT NULL -signature — TEXT NULL - -Ограничение: -UNIQUE(login, param) - -Логика: -обновление принимается только если excluded.time_ms > users_params.time_ms - -ip_geo_cache -ip — TEXT PK -geo — TEXT NULL -updated_at_ms — INTEGER NOT NULL - -blockchain_state -blockchain_name — TEXT PK -login — TEXT NOT NULL, FK → solana_users(login) -blockchain_key — TEXT NOT NULL -size_limit — INTEGER NOT NULL -file_size_bytes — INTEGER NOT NULL -last_global_number — INTEGER NOT NULL (-1 = genesis) -last_global_hash — TEXT NOT NULL -updated_at_ms — INTEGER NOT NULL - -Линии 0..7: -для каждой линии: -lineX_last_number -lineX_last_hash - -blocks -login — TEXT NOT NULL -bch_name — TEXT NOT NULL -block_global_number — INTEGER NOT NULL -block_global_pre_hash — TEXT NOT NULL -block_line_index — INTEGER NOT NULL -block_line_number — INTEGER NOT NULL -block_line_pre_hash — TEXT NOT NULL -msg_type — INTEGER NOT NULL -msg_sub_type — INTEGER NOT NULL -block_bytes — BLOB NULL - -Ссылка на другой блок (nullable): -to_login -to_bch_name -to_block_global_number -to_block_hash - -connections_state ⭐ -Текущее агрегированное состояние связей. - -login — TEXT NOT NULL -rel_type — INTEGER NOT NULL -10 = FRIEND -20 = CONTACT -30 = FOLLOW -to_login — TEXT NOT NULL -to_bch_name — TEXT NOT NULL -to_block_global_number — INTEGER NULL -to_block_hash — TEXT NULL - -Ограничение: -UNIQUE(login, rel_type, to_login) - -message_stats ⭐ -Счётчики активности по целевому сообщению. - -to_login — TEXT NOT NULL -to_bch_name — TEXT NOT NULL -to_block_global_number — INTEGER NOT NULL -to_block_hash — TEXT NOT NULL -likes_count — INTEGER NOT NULL DEFAULT 0 -replies_count — INTEGER NOT NULL DEFAULT 0 - -UNIQUE: -(to_login, to_bch_name, to_block_global_number, to_block_hash) - -Триггеры БД (полная логика) - -3.1 Связи пользователей -trg_blocks_connection_state_ai -AFTER INSERT ON blocks - -Условие: -msg_type = 3 (connection) - -Добавление / обновление связи -msg_sub_type IN (10,20,30) -выполняется UPSERT в connections_state - -Удаление связи -msg_sub_type IN (11,21,31) -удаляется соответствующая связь: -11 → 10 -21 → 20 -31 → 30 - -Итог: -blocks — журнал событий -connections_state — всегда актуальное состояние - -3.2 Подсчёт лайков ⭐ -trg_blocks_message_stats_like_ai -AFTER INSERT ON blocks - -Условие: -msg_type = 2 (reaction) -msg_sub_type = 1 (like) - -Действие: -определяется цель по to_bch_name, to_block_global_number, to_block_hash -to_login вычисляется как -substr(to_bch_name, 1, length(to_bch_name) - 3) -выполняется UPSERT в message_stats -likes_count += 1 - -3.3 Подсчёт ответов ⭐ -trg_blocks_message_stats_reply_ai -AFTER INSERT ON blocks - -Условие: -msg_type = 1 (text) -msg_sub_type = 2 (reply) - -Действие: -цель определяется аналогично лайкам -выполняется UPSERT в message_stats -replies_count += 1 - -Индексы (смысл) - -idx_solana_users_login — поиск пользователя -idx_active_sessions_login — сессии пользователя -idx_users_params_login — параметры пользователя -idx_ip_geo_cache_updated_at — чистка кеша -idx_blockchain_state_login — блокчейны пользователя -idx_blockchain_state_updated_at — обслуживание -idx_blocks_chain_global — чтение цепочки -idx_blocks_to_target — реакции / ответы -idx_message_stats_target — быстрый доступ к счётчикам - -Итоговая модель мышления - -blocks — неизменяемый журнал событий -connections_state — проекция связей -message_stats — проекция активности -всё вычисляется детерминированно через триггеры \ No newline at end of file diff --git a/DOC/Протокол звонков (MVP).md b/DOC/Протокол звонков (MVP).md deleted file mode 100644 index d826d95..0000000 --- a/DOC/Протокол звонков (MVP).md +++ /dev/null @@ -1,75 +0,0 @@ -# Протокол звонков (MVP) - -Версия: browser-to-browser, runtime-only signaling. - -## Цели -- Технические сообщения звонка не сохраняются в БД direct_messages. -- Первый INVITE рассылается всем активным сессиям получателя и дублируется web push. -- Последующие сигналы идут только в конкретную sessionId и не дублируются в push. - -## Операции API - -### 1) CallInviteBroadcast -Отправляет общий вызов пользователю. - -Запрос payload: -- `toLogin: string` -- `callId: string` -- `type: 100` (INVITE) - -Поведение сервера: -- Рассылает `IncomingCallInvite` во все активные WS-сессии `toLogin`. -- В payload события передаёт: - - `fromLogin` - - `fromSessionId` (session инициатора) - - `toLogin` - - `callId` - - `type=100` - - `timeMs` -- Отправляет web push уведомление о входящем вызове. - -Ответ payload: -- `callId` -- `deliveredWsSessions` -- `deliveredFcmSessions` - -### 2) CallSignalToSession -Отправляет технический сигнал в конкретную сессию. - -Запрос payload: -- `toLogin: string` -- `targetSessionId: string` -- `callId: string` -- `type: int` -- `data: string` (для SDP/ICE/служебных строк) - -Поведение сервера: -- Ищет только `targetSessionId`. -- Проверяет, что сессия принадлежит `toLogin`. -- Отправляет `IncomingCallSignal` только в эту сессию. -- В БД ничего не сохраняет. -- Push не отправляет. - -Ответ payload: -- `delivered: boolean` - -## Коды type -- `100` INVITE -- `110` RINGING -- `120` ACCEPT -- `130` DECLINE_BUSY -- `140` TIMEOUT -- `150` HANGUP -- `200` OFFER -- `210` ANSWER -- `220` ICE - -## Правила UI/логики -- Если уже есть активный звонок и пришел новый INVITE -> автоответ `DECLINE_BUSY` без UI. -- После ACCEPT `callId` остаётся во всех OFFER/ANSWER/ICE сообщениях до конца звонка. -- При параллельных звонках A<->B допускается детерминированное правило, кто создаёт OFFER. - -## Тайминги MVP -- Ожидание подтверждения/реакции после INVITE: до 5с (у инициатора). -- Ожидание принятия у входящего звонка: 20с. -- Общий лимит ожидания до соединения: 22с. diff --git a/DOC/Что недоделано. И потом надо доделать b/DOC/Что недоделано. И потом надо доделать deleted file mode 100644 index d54ccd4..0000000 --- a/DOC/Что недоделано. И потом надо доделать +++ /dev/null @@ -1,9 +0,0 @@ - - -Дальше делать: -Описание форматов. -Запросы клиент-сервер. -Промт на клиента. - ---- -Потом в сервак дописать синхронизацию серверов. \ No newline at end of file diff --git a/Deploy Server/servers-inventory.md b/Deploy Server/servers-inventory.md deleted file mode 100644 index a7fa20c..0000000 --- a/Deploy Server/servers-inventory.md +++ /dev/null @@ -1,53 +0,0 @@ -# SHiNE Deployment Servers Inventory - -## Scope -This folder contains all deployment-related notes and server records for SHiNE. - -## Legacy Production Server -- Name: `VPS-02` (legacy) -- Access: `root@194.87.0.247` -- Current role: old production server -- Confirmed services: - - `coturn` is installed and active (`systemd: active/running`) - - `caddy` is installed (reported by project context; verify version on host if needed) -- TURN configuration observed on host: - - `listening-port=3478` - - `external-ip=194.87.0.247` - - `relay-ip=194.87.0.247` - - auth mode: `use-auth-secret` + `static-auth-secret` -- SHiNE deployment note: - - This host is used as current/legacy runtime for SHiNE. - - Gradle-based deployment is used in this project (see repository deploy tasks and scripts). - -## Target Production Server (Migration) -- Name: `VPS-05` (new) -- Access: `root@45.136.124.227` -- Planned role: new primary production server for gradual migration -- Baseline setup done: - - `ripgrep` installed - - user `player` created - - user `player` added to `sudo` group - - deployment directory created: `/home/player/SHiNE` -- Rule: - - All SHiNE-related runtime files and deployments on VPS-05 should be placed under `/home/player/SHiNE`. - -## Additional TURN Node -- Name: `promo-node-93` -- Access: `ubuntu@93.170.12.154` (and `player` user for SHiNE operations) -- Role: additional TURN node for SHiNE calls -- TURN setup: - - `coturn` installed and active - - `listening-port=3478` - - `tls-listening-port=5349` - - `use-auth-secret` + shared `static-auth-secret` - - relay UDP port range: `49152-50152` -- Runtime files: - - `/etc/turnserver.conf` - - `/home/player/SHiNE/coturn/turnserver.conf` -- Cleanup done: - - Disabled old reverse SSH tunnel (`reverse-ssh.service`) that exposed `0.0.0.0:1200 -> localhost:22` to `194.87.0.247`. - -## Next Migration Steps (recommended) -1. Install and configure runtime dependencies (JDK, Caddy, DB, TURN if required). -2. Mirror SHiNE deployment process from VPS-02 using existing Gradle deployment flow. -3. Move traffic gradually and validate logs/metrics before final cutover. diff --git a/Dev_Docs/Future_Features/README.md b/Dev_Docs/Future_Features/README.md deleted file mode 100644 index c95e6d5..0000000 --- a/Dev_Docs/Future_Features/README.md +++ /dev/null @@ -1,13 +0,0 @@ -# Будущие фичи - -Эта папка оставлена как архивный указатель. Активный backlog теперь ведётся в корневой папке `TODO/`. - -## Что здесь осталось - -- `README.md` - краткое объяснение, что раньше хранилось в `Future_Features/`. -- `far/README.md` - архивное описание дальнего горизонта. - -## Куда смотреть теперь - -- Ближайшие и среднесрочные планы перенесены в `TODO/`. -- Если нужен список следующих шагов, читать сначала `TODO/README.md`. diff --git a/Dev_Docs/Future_Features/far/README.md b/Dev_Docs/Future_Features/far/README.md deleted file mode 100644 index 26b132b..0000000 --- a/Dev_Docs/Future_Features/far/README.md +++ /dev/null @@ -1,8 +0,0 @@ -# Дальнее будущее - -Архивный файл. Раньше здесь лежали задачи дальнего горизонта, но теперь активный backlog перенесён в `TODO/`. - -## Что делать дальше - -- смотреть `TODO/README.md`; -- если потребуется вернуть этот горизонт отдельно, обновить соответствующий список задач в `TODO/`. diff --git a/Dev_Docs/Pending_Features/2026-06-20_1839_registration_faq_and_12_words.md b/Dev_Docs/Pending_Features/вроде сделанное/2026-06-20_1839_registration_faq_and_12_words.md similarity index 100% rename from Dev_Docs/Pending_Features/2026-06-20_1839_registration_faq_and_12_words.md rename to Dev_Docs/Pending_Features/вроде сделанное/2026-06-20_1839_registration_faq_and_12_words.md diff --git a/Dev_Docs/Pending_Features/2026-06-20_2350_test_free_avatar_upload.md b/Dev_Docs/Pending_Features/вроде сделанное/2026-06-20_2350_test_free_avatar_upload.md similarity index 100% rename from Dev_Docs/Pending_Features/2026-06-20_2350_test_free_avatar_upload.md rename to Dev_Docs/Pending_Features/вроде сделанное/2026-06-20_2350_test_free_avatar_upload.md diff --git a/Dev_Docs/Pending_Features/2026-06-24_1825_unified_channels_list_without_stories.md b/Dev_Docs/Pending_Features/вроде сделанное/2026-06-24_1825_unified_channels_list_without_stories.md similarity index 100% rename from Dev_Docs/Pending_Features/2026-06-24_1825_unified_channels_list_without_stories.md rename to Dev_Docs/Pending_Features/вроде сделанное/2026-06-24_1825_unified_channels_list_without_stories.md diff --git a/Dev_Docs/Pending_Features/2026-06-26_1500_addblock_tmp_bch_recovery.md b/Dev_Docs/Pending_Features/вроде сделанное/2026-06-26_1500_addblock_tmp_bch_recovery.md similarity index 100% rename from Dev_Docs/Pending_Features/2026-06-26_1500_addblock_tmp_bch_recovery.md rename to Dev_Docs/Pending_Features/вроде сделанное/2026-06-26_1500_addblock_tmp_bch_recovery.md diff --git a/Dev_Docs/Pending_Features/2026-06-26_1745_proverka_avariynykh_ostanovok.md b/Dev_Docs/Pending_Features/вроде сделанное/2026-06-26_1745_proverka_avariynykh_ostanovok.md similarity index 100% rename from Dev_Docs/Pending_Features/2026-06-26_1745_proverka_avariynykh_ostanovok.md rename to Dev_Docs/Pending_Features/вроде сделанное/2026-06-26_1745_proverka_avariynykh_ostanovok.md diff --git a/Dev_Docs/Personal_Messages/TODO_доработка_персональных_сообщений_для_агентов.md b/Dev_Docs/Personal_Messages/TODO_доработка_персональных_сообщений_для_агентов.md deleted file mode 100644 index 20b27cf..0000000 --- a/Dev_Docs/Personal_Messages/TODO_доработка_персональных_сообщений_для_агентов.md +++ /dev/null @@ -1,42 +0,0 @@ -# TODO: доработка персональных сообщений для агентов - -Статус: отложено. - -## Что хотели сделать - -Добавить упрощённую маршрутизацию персональных сообщений через служебную инструкцию в начале текстового payload (внутри подписанного DM-блока), чтобы: - -- отличать сообщения человеку от сообщений агенту; -- отличать сообщения от человека и от агента; -- скрывать в обычном UI сообщения, адресованные агенту (`target=agent`); -- поддержать сценарий «сообщения самому себе между своими клиентами/устройствами», где один клиент/агент пишет другому в рамках одного логина. - -## Базовая идея формата (черновик) - -Пример префикса: - -```text -@shine:pm:v1 {"target":"agent","agentId":"assistant","author":"human"} -Текст сообщения... -``` - -Пример ответа агента: - -```text -@shine:pm:v1 {"target":"user","author":"agent","agentId":"assistant","agentLabel":"My Bot"} -Ответ агента... -``` - -## Почему отложено - -- нужно отдельно согласовать финальный формат инструкции; -- нужно определить строгие правила UI-фильтрации и fallback; -- нужно определить, нужен ли позднее отдельный серверный роутинг для agent-сессий. - -## Что сделать при возвращении к задаче - -1. Зафиксировать окончательный формат префикса и JSON-полей. -2. Описать правила парсинга/валидации (включая битые/неполные префиксы). -3. Добавить UI-логику показа/скрытия agent-сообщений. -4. Добавить маркировку «ответ агента» в диалоге. -5. Продумать режим self-chat (между своими клиентами/агентом) в рамках одного логина. diff --git a/VERSION.properties b/VERSION.properties index 8933de5..70595d8 100644 --- a/VERSION.properties +++ b/VERSION.properties @@ -1,2 +1,2 @@ -client.version=1.2.281 -server.version=1.2.261 +client.version=1.2.282 +server.version=1.2.262