SHiNE-server/Dev_Docs/00_INDEX.md
AidarKC 1aabcf4d80 27 03 25
Доделал API функции для авторификации и работы с сессиями сервер и документ для разработчиков по

Авторификациии и серверам

Всё работает
2026-03-27 22:06:19 +03:00

3.2 KiB
Raw Blame History

Dev_Docs — оглавление

Этот набор документов сделан по текущему состоянию кода сервера (/workspace/SHiNE-server) и разбит по темам.

Список документов

  1. API/00_Common_API_Format.md
    Общий формат JSON-запросов и JSON-ответов по всему API: op, requestId, status, ok, payload, единые правила успеха и ошибок.

  2. API/01_User_Registration_API.md
    Временная глава API по регистрации пользователя: AddUser и временный GetUser, с пометкой о будущем переходе проверки identity напрямую через Solana.

  3. API/02_Authentication_API.md
    Глава API по авторизации: AuthChallenge, CreateAuthSession, SessionChallenge, SessionLogin, подписи, deviceKey, sessionKey.

  4. API/03_Session_Management_API.md
    Глава API по управлению сессиями: ListSessions и CloseActiveSession.

  5. 01_Connection_and_Sessions.md
    Процесс подключения к WebSocket, авторизация (двухшаговая), создание сессии, вход в существующую сессию, просмотр и закрытие сессий.

  6. 02_Blockchain_Structure_and_Block_Types.md
    Архитектура блокчейна, форматы и типы блоков, что уже можно делать каждым типом блока.

  7. 03_Addable_Blocks_Channels_Messages_Connections.md
    Какие блоки добавляются через AddBlock, как делать каналы/подписки/контакты/друзей/лайки/ответы, что уже есть и чего не хватает в API.

  8. 04_Query_Design_for_Subscriptions_Counters_and_Sync.md
    Проектирование новых API-запросов: список подписок с общим/новым числом сообщений, список сообщений канала, граф ответов для сообщения, поток синхронизации online/offline.

  9. 05_Open_Questions_and_TODO.md
    Список открытых вопросов, рисков и приоритетов для доработки сервера.

Почему так разбито

  • Сначала протокол и сессии — это входная точка клиента.
  • Потом блокчейн-слой — какие данные вообще можно выразить блоками.
  • Потом прикладные функции (каналы/сообщения/связи) — что реально можно сделать уже сейчас.
  • Потом проектирование отсутствующих запросов — чтобы закрыть разрыв между текущим сервером и нужной функциональностью клиента.
  • В конце вопросы — чтобы быстро согласовать спорные места.