Публичное бета-тестирование Matrix Spaces18.05.2021 11:05

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

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