22.06.2021

Публичное бета-тестирование Matrix Spaces

Разработчики протокола федеративной сети Matrix рады объявить о готовности всей инфраструктуры проекта (спецификации, клиентов, серверов) для начала бета-тестирования нового способа группирования комнат и пользователей — Spaces, пришедшего на смену представленным в 2017 году Communities.

Протокол Matrix является набором API для синхронизации линейной истории событий (events) в формате JSON внутри ациклического графа событий (DAG): простыми словами, является распределённой базой данных, хранящей полную историю отправленных клиентами сообщений и данные участвующих пользователей, реплицируя эту информацию между участвующими серверами — ближайшей аналогичной по работе технологией может быть Git и блокчейн.

Основной реализацией клиента этой сети является мессенджер с поддержкой сквозного шифрования и VoIP (аудио- и видеозвонков, групповых конференций) — Element, а сервера — Synapse. Эталонные реализации клиентов и серверов разрабатываются одноимённой коммерческой компанией Element, сотрудники которой также возглавляют некоммерческую организацию Matrix.org Foundation, курирующую разработку спецификации протокола Matrix.

Со дня начала своего существования клиент 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. В будущем нас ждут реализации:

Переосмысление архитектуры сообществ также заставило разработчиков посмотреть на комнаты как на универсальный примитив, в котором можно хранить практически любые метаданные для самых разных задач:

Для тестирования Spaces нужен клиент с последними стабильными версиями matrix-react-sdk v3.21.0 и matrix-android-sdk2 v1.1.7 (то есть Element Web и Element Android) и сервер Synapse 1.34.0.

>>> Подробности

Источник.