[В порядке бреда] Новая концепция работы сервера (а возможно и всего проекта)

[stepanskryabin]

Контекст-Вводная

• У проектов типа Signal, Telegram, Discord, WhatsApp, Slack есть большая проблема в отсутствии децентрализации. Но у них есть большой плюс в присутствии огромного количества пользователей.
• У проектов типа Matrix, Yggdrasill, ActivityPub есть большая проблема с количеством пользователей. Но у них большой плюс в децентрализации.
• У проекта MoreliaTalk нет децентрализации и нет пользователей. 😞

Сегодня интернет невозможно представить без свободного общения между людьми, с возможностью озвучить разные мнения на окружающие нас вещи и события или координировать свою деятельность. Для некоторых представителей организаций/государств такая свобода является раздражителем, им иногда хочется все это хотя бы контролировать, а в особых случаях контролировать "жёсткой рукой" или вообще заблокировать. К сожалению, большая часть работы инфраструктуры (сервера, приложения) очень часто и достаточно сильно зависят от решения его собственника или регулятора (правительства) страны в котором находится собственник. Если процесс блокировки сети интернет отдельной страны (т.н. чебурнетизация) всё-таки сложная процедура, несущая огромные риски для самого регулятора, то процесс блокировки отдельной компании которая предоставляет услугу (например WhatsApp, Facebook, Instagram, Telegram) или процесс блокировки компанией своего пользователя представляет менее рисковую операцию и более результативно. Такое вмешательство разрушает концепцию интернета, и является грубым актом цензуры.

Со временем у пользователей появляется все больше и больше желания избежать самой возможности цензуры. Многие представители IT уже давно работают над инструментами которые смогут в этом помочь, и один из подходов называется децентрализация. С помощью децентрализованных программ и сервисов можно будет избежать цензуры и строить между людьми более надёжные каналы коммуникации. Основная проблема сейчас, это нежелание "массового" пользователя использовать инструменты децентрализации, в связи с их неразвитостью, а так же малой популярностью. По сути, сейчас децентрализованным сервисами пользуются те кто их создаёт, около itшное сообщество и политические активисты.

Что нужно поменять?

Проекту нужна бОльшая децентрализация и бОльшая аудитория.
Для лучшей децентрализации morelia_server должен уметь общаться не только с клиентами (пользователями) но и с другими morelia_server.
Для лучшего охвата аудитории morelia_server должен уметь связывать между собой разные протоколы (MTP, Matrix, telegram и т.п.).
Ещё проекту нужна киллер-фича, отличающая его от других, такой киллер-фичей может стать использование протокола MQTT как для общения людей так и для общения и управления IoT-устройствами.
Таким образом morelia_server может стать центральным элементом связующим между собой IoT устройства и общение между собой людей.

Предложение

Предлагаю обсудить новый вариант работы morelia_server в результате чего:

1. Не нужна будет БД.
2. Код сервера будет упрощен (можно будет отказаться от FastAPI, uvicorn, jinja2, aiofiles, sqlobject, fastapi-login).
3. Потенциально можно будет отказаться от email-validator, pydantic, loguru, websocket-client, click.
4. Снизится общее требование к железу сервера.
5. Появится совместимость с другими проектами использующими MQTT.

при этом morelia_server всё так же будет работать через websocket и так же поддерживать родной протокол MTP (и в будущем Matrix) с шифрованием и прочими плюшками.

Подробнее

Идея в следующем: перевести morelia_server на работу по протоколу MQTT (который работает как через TCP, так и через websocket). Таким образом morelia_server превращается в промежуточное (в терминалогии MQTT - брокер) звено между клиентами и, не храня данные, отвечает только за передачу сообщений по принципу "один-ко-многим". При этом MQTT-протокол позволяет внутри передавать JSON-объекты в полном соответствии с протоколом (MTP/Matrix/etc).

MQTT

Что такое MQTT можно почитать здесь. Кратко, в протоколе MQTT есть две сущности:

1. topic - внутренний адрес (расположение) данных - в виде пути к файлу, например: /workspace/MoreliaTalk
2. payload - объект данных привязанный к конкретному topic, например строка, JSON, bytes и т.п.
   Все клиенты подписываются на необходимые им topic через брокера и получают/отправляют payload только в этот topic. Брокер получив payload в определённый topic отправляет этот payload всем клиентам которые подписались на этот же topic.

Функционал morelia_server

• маршрутизация "один-ко-многим" сообщений.
• проверка на версию и тип протокола используемого клиентами.
• трансляция "перевод" из одного протокола в другой.

Плюсы

• меньше зависимостей от cтороних проектов.
• меньше требований к железу сервера, запуск возможен на простецких роутерах.
• больший охват (клиентом может быть не только человек но и IoT-устройство).
• не ломает текущую совместимость с протоколом MTP.

Минусы

• дополнительные затраты чел.часов на доработку сервера и клиентов
• вынос панели управления (панели администратора) в отдельный репозиторий
• вынос тестового клиента в отдельный репозиторий

[NekrodNIK]

Я предлагаю другую концепцию - рой серверов. У нас есть группа серверов, дублирующая данные между собой. Клиент общается только с одним из них. В случае отключения этого сервера клиент просто подключается к другому и продолжает общение. Этот подход позволяет не менять ничего существенно в клиенте и просто обеспечить устойчивость сервера, теперь имеющий больше, чем одну точку отказа.

Концепция связи серверов

Допустим, мы хотим поднять сервер в качестве части сети других серверов. В конфиге мы указываем либо адрес одного сервера из этого роя(далее - сервер-пчела), либо доменное имя роя(например, morelia.main.org). При указании доменного имени наш сервер связывается с информационным сервером, сидящем на этом домене, и тот возвращает нам список серверов роя. В случае указания адреса сервера-пчелы, мы подключаемся к нему, и уже от него узнаем о других серверах. Наш сервер, при получении сообщения от пользователя сначала перешлёт его другому серверу, и затем запишет в свою бд новые данные, после чего вернёт клиенту ответ. В случае отключения сервера на время, а затем его включения, сервер сверяет свою бд с бд других серверов, и при наличии обновлений - пишет их в свою бд. В случае расхождения данных серверов, всегда выбираются данные, которые имеет у себя большинство из роя.

Концепция работы клиента

Клиент общается с одним сервером как и ранее, тут всё без изменений. Для подключения мы выбираем либо доменое имя роя, либо один сервер из него. Затем, клиент сам автоматически выбирает более подходящие и близкорасположенные сервера и общается с ними.

Одиночный сервер

Также возможен запуск сервера вне сети, в автономном режиме

В общем, если обобщить - то надо распилить наш сервер на кучу зеркальных, для обеспечения устойчивости сети

Плюсы

• повышение устойчивости сети
• текущий код будет в дальнейшем использован, а не выкинут за борт
• никаких внешних изменений в общении с сервером у клиента

Минусы

• дополнительные затраты чел.часов на доработку сервера и клиентов)))
• отсутствие подлинной peer-to-peer децентрализации

[stepanskryabin]

1. MQTT для создания т.н. "роя" лучше всего подходит.
2. Рой только дополняет мою концепцию, так как одно другому не мешает.
3. На счёт централизованной БД, тут 50/50 если делаем БД то нет децентрализации, и наоборот.