Разработчики протокола федеративной сети Matrix рады объявить о готовности всей инфраструктуры проекта (спецификации, клиентов, серверов) для начала бета-тестирования нового способа группирования комнат и пользователей — Spaces, пришедшего на смену представленным в 2017 году Communities.
Matrix
Протокол Matrix является набором API для синхронизации линейной истории событий (events) в формате JSON внутри ациклического графа событий (DAG): простыми словами, является распределённой базой данных, хранящей полную историю отправленных клиентами сообщений и данные участвующих пользователей, реплицируя эту информацию между участвующими серверами — ближайшей аналогичной по работе технологией может быть Git и блокчейн.
Основной реализацией клиента этой сети является мессенджер с поддержкой сквозного шифрования и VoIP (аудио- и видеозвонков, групповых конференций) — Element, а сервера — Synapse. Эталонные реализации клиентов и серверов разрабатываются одноимённой коммерческой компанией Element, сотрудники которой также возглавляют некоммерческую организацию Matrix.org Foundation, курирующую разработку спецификации протокола Matrix.
Spaces
Со дня начала своего существования клиент Element (ранее известный как Riot, и ещё раньше как Vector) позиционировался как средство для коммуникаций команд и бизнеса, заимствуя принципы работы и дизайна у тогда уже закрепившего свои позиции на рынке Slack. Но функциональность клиента на тот момент была сильно ограниченной и не могла конкурировать без какого-нибудь механизма группировки пространств и контактов, в которых находится пользователь. Это большая проблема, ведь навигация по чатам в таких условиях очень усложнена. Когда Slack уже мог предложить Workspaces для группировки каналов и раздачи прав пользователям с помощью ролей, решение для Matrix не существовало даже «на бумаге» — не говоря уже о какой-либо реализации.
Первая попытка решения этой проблемы была предпринята с введением Communities в 2017 году: у пользователей появилась боковая панель, аналогичная Workspaces в Slack, на которой располагались созданные сообщества. Они могли быть как публичными, так и по приглашению. Администратор сообщества мог добавлять в него уже созданные комнаты: при выборе сообщества в боковой панели, в списке комнат отображались только те комнаты и контакты, которые добавлены в сообщество — это служило фильтром для облегчения навигации между чатами. Также появилась интересная опция — «flairs»: маленькая иконка с изображением сообщества, в котором состоит пользователь, отображающаяся возле его ника, включаемая по усмотрению администратора комнаты. У сообществ, как и у комнат, был свой формат адресов: +community:server.tld.
Хоть реализация Communities и просуществовала 4 года, она бесславна своим количеством недостатков, делающим её практически бесполезной:
- сообщества были централизованными и доступными только с одного сервера — в отличие от децентрализованных комнат, реплицирующихся между всеми участвующими серверами;
- производительность оставляла желать лучшего и для отображения совершённых изменений по федерации требовалось некоторое время, вплоть до нескольких минут;
- невозможность приглашений пользователей по 3PID, типа электронной почты и номера телефона;
- отсутствие системы «power levels», то есть невозможность назначения новых администраторов и модераторов сообщества;
- отсутствие системы ACL для гибкой настройки прав пользователя, учитывая его членство в сообществе;
- в общем, архитектура сообществ была «переизобретением велосипеда», потому что для них был создан новый отдельный пласт API, дублирующий уже существующий API комнат, но несовместимый с ними и работающий гораздо хуже.
Проблемность Communities никто не отрицал и план по рефакторингу не заставил себя долго ждать: появилось предложение отказаться от дублирующего слоя API для сообществ в пользу уже работающего API для комнат, то есть появилась инициатива Communities as Rooms, а с ней и вторая попытка решения проблемы группировки комнат под названием Spaces. Переход на использование API от комнат кардинально упростил архитектуру сообществ и дал дорогу экспериментам и новой функциональности:
- теперь каждая комната может превратиться в сообщество и хранить в себе информацию о других комнатах;
- главной особенностью нового типа сообществ является появление иерархии: одно сообщество может быть вставлено в другое, другое в третье, третье в четвёртое…
- при этом возможно «спрятать» сообщество, доступное только по приглашениям, в публичное сообщество, и оно будет отображаться только для тех, кто в нём состоит;
- одна и та же комната может появляться несколько раз в этой структуре иерархии сообществ;
- администратор сообщества может указать флаг «suggested» для какой-нибудь комнаты — рекомендацию войти в эту комнату для пользователей;
- так как сообщества теперь являются обычными комнатами, вам доступны те же механизмы «power levels», ACL, и настройки приватности.
В рамках бета-тестирования проверяется работоспособность только базовой части спецификации Spaces. В будущем нас ждут реализации:
- наследуемых «power levels» между комнатами в зависимости от того, какой у пользователя уровень в сообществе (например, если пользователь модератор в сообществе, то он так же и модератор во всех комнатах, добавленных в сообщество);
- ограничения доступности комнаты в зависимости от того, состоит ли пользователь в сообществе;
- удалённых «flairs».
Переосмысление архитектуры сообществ также заставило разработчиков посмотреть на комнаты как на универсальный примитив, в котором можно хранить практически любые метаданные для самых разных задач:
- структурированного хранения файлов (Matrix как файловая система!);
- репутации пользователей;
- нитей обсуждения (threads);
- расширяемых профилей пользователей;
- …
Для тестирования Spaces нужен клиент с последними стабильными версиями matrix-react-sdk v3.21.0 и matrix-android-sdk2 v1.1.7 (то есть Element Web и Element Android) и сервер Synapse 1.34.0.
>>> Подробности
