Сессионные homeserver-ы в PDA пользователя

Статус: future
Горизонт: medium
Ориентир: после завершения первого этапа по пользовательским сессиям
Основание: Идея зафиксирована после обсуждения архитектуры пользовательских сессий и внутренних homeserver-ов. Сейчас задача сознательно отложена: сначала нужно аккуратно ввести базовую модель сессий, а затем возвращаться к расширенной серверной роли.

Зачем нужна фича

У одного пользователя может быть несколько доверенных внутренних homeserver-ов, и каждый из них должен жить как отдельная пользовательская сессия, а не как отдельная особая сущность вне общей модели.

Это нужно, чтобы:

хранить несколько homeserver-ов у одного пользователя одновременно;
различать обычные клиентские сессии и серверные сессии по явному типу;
дать расширяемый формат записи с версией;
использовать единый подход для DM, звонков и внутренних команд между сессиями.

Целевая идея

В пользовательском PDA должен появиться список записей сессий, где каждая запись содержит как минимум:

sessionType (u8);
sessionVersion (u8);
sessionName;
sessionPubKey.

Предварительные значения:

тип 1 - обычная пользовательская сессия;
тип 100 - homeserver пользователя;
версия 1 - первая рабочая версия формата записи сессии.

На текущем этапе под это уже зарезервирован отдельный блок SessionsBlock с block_type = 55, а TrustedStateBlock остаётся на 50.

Важно: homeserver-ов у одного пользователя может быть несколько.

Архитектурный принцип

Внутренний протокол взаимодействия должен оставаться транспортным.

То есть SHiNE-сервер не должен разбирать прикладной смысл внутренней нагрузки homeserver-а, а должен:

доставлять сообщения между сессиями;
доставлять сигналы звонков между сессиями;
хранить и маршрутизировать адресацию;
не принимать на себя бизнес-логику содержимого внутренних команд.

Что уже подтверждается текущим кодом

Личные сообщения уже доставляются по всем сессиям целевого пользователя с отдельным учётом доставки на каждую сессию.
Подтверждение доставки DM уже идёт отдельно по каждой сессии.
Вызов звонка уже рассылается по нескольким активным сессиям пользователя.
Сигналы звонка уже адресуются конкретной сессии, а stop-сигналы дублируются на остальные сессии того же пользователя.

Иными словами, текущая серверная логика ближе к модели "сервер доставляет между сессиями", чем к модели "сервер понимает внутренний протокол homeserver-а".

Что нужно сделать при возврате к задаче

Согласовать финальный бинарный формат записи сессии в PDA пользователя.
Проверить, не меняет ли это уже опубликованный формат пользовательской PDA-записи.
Если формат PDA меняется, заранее предупредить пользователя и получить отдельное подтверждение.
Решить, где именно хранится массив сессий:
- в основной записи пользователя;
- в отдельной PDA-структуре расширения;
- или в смешанной схеме с базовой записью и внешними индексами.
Зафиксировать ограничения:
- максимальное число сессий;
- максимальную длину sessionName;
- правила удаления и обновления записи;
- правила ротации sessionPubKey.
Продумать, как UI и сервер будут отличать тип 1 и тип 100.
Определить, какие внутренние сообщения homeserver-а останутся полностью прозрачными для SHiNE-сервера, а какие потребуют только технической маршрутизации.
Добавить API/операции чтения и обновления списка сессий, если для этого не хватит существующих механизмов.
После реализации обязательно обновить документацию.

Что нужно обновить при реализации

shine-solana/shine/doc/formats/shine-user-pda-format-v.1.0.md
Dev_Docs/Solana_Architecture/README.md
Dev_Docs/Инициализация_Solana_регистрации/README.md
Dev_Docs/Keys/README.md
Dev_Docs/Personal_Messages/README.md, если изменится адресация DM по типам сессий
Dev_Docs/API/, если появятся новые серверные операции или изменятся ответы

Что пока не делать

Не включать это автоматически в основной deploy сервера.
Не менять сейчас Solana PDA-формат без отдельного подтверждения.
Не добавлять временные поля в публичный API "на всякий случай".

С какого места продолжать

Продолжать после завершения первой части:

описать минимальный формат записи пользовательской сессии;
отдельно решить, живут ли homeserver-ы в том же списке, что и обычные сессии;
затем уже проектировать операции регистрации, обновления и отключения таких сессий.

7.4 KiB Raw Blame History Unescape Escape