106 lines
7.4 KiB
Markdown
106 lines
7.4 KiB
Markdown
# Сессионные 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-а".
|
||
|
||
## Что нужно сделать при возврате к задаче
|
||
|
||
1. Согласовать финальный бинарный формат записи сессии в PDA пользователя.
|
||
2. Проверить, не меняет ли это уже опубликованный формат пользовательской PDA-записи.
|
||
3. Если формат PDA меняется, заранее предупредить пользователя и получить отдельное подтверждение.
|
||
4. Решить, где именно хранится массив сессий:
|
||
- в основной записи пользователя;
|
||
- в отдельной PDA-структуре расширения;
|
||
- или в смешанной схеме с базовой записью и внешними индексами.
|
||
5. Зафиксировать ограничения:
|
||
- максимальное число сессий;
|
||
- максимальную длину `sessionName`;
|
||
- правила удаления и обновления записи;
|
||
- правила ротации `sessionPubKey`.
|
||
6. Продумать, как UI и сервер будут отличать тип `1` и тип `100`.
|
||
7. Определить, какие внутренние сообщения homeserver-а останутся полностью прозрачными для SHiNE-сервера, а какие потребуют только технической маршрутизации.
|
||
8. Добавить API/операции чтения и обновления списка сессий, если для этого не хватит существующих механизмов.
|
||
9. После реализации обязательно обновить документацию.
|
||
|
||
## Что нужно обновить при реализации
|
||
|
||
- `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 "на всякий случай".
|
||
|
||
## С какого места продолжать
|
||
|
||
Продолжать после завершения первой части:
|
||
|
||
1. описать минимальный формат записи пользовательской сессии;
|
||
2. отдельно решить, живут ли homeserver-ы в том же списке, что и обычные сессии;
|
||
3. затем уже проектировать операции регистрации, обновления и отключения таких сессий.
|