Протокол и имя матрицы уже используются

Matrix — замечательный, но недооценённый децентрализованный протокол обмена сообщениями с прилагающимся к нему клиентом Element, который я считаю достойной и жизнеспособной альтернативой Telegram.

Протокол и имя матрицы уже используются

Рассказываю, почему я использую Matrix вместо Telegram, как присоединиться к сети Matrix и настроить свой сервер.

Итак, почему?

Я считаю, что протоколу Matrix нужна большая огласка: чем больше людей о нём узнает и начнёт его использовать — тем лучше как для протокола, так и для айти-тусовки.

Matrix — это открытый и децентрализованный протокол мгновенного обмена сообщениями, разрабатываемый энтузиастами из Matrix.org Foundation.

Спецификации протокола, равно как и клиент-серверная часть (Synapse как сервер и Element как клиент) находятся в открытом доступе — в отличие от Telegram, который в настоящее время в открытом доступе держит только свой клиент, что вызывает немало вопросов по поводу безопасности использования протокола MTProto.

У протокола Matrix существует полноценная реализация федерации, которая позволяет бесшовно общаться, организовывать общие комнаты для общения пользователям разных серверов, совершать видео- и аудиозвонки.

Клиент Element обладает всеми современными функциями, которые присущи другим популярным мессенджерам (за исключением голосовых сообщений).

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

  • Децентрализация — возможность поднять свой сервер для подключения к сети Matrix
  • Приватность — сквозное шифрование
  • Групповые аудио- и видеозвонки для пользователей с разных серверов
  • Отличное API для ботов
  • Полнофункциональный веб-клиент
  • Консольные клиенты

Почему не Jabber?

Потому что протокол XMPP переполнен многочисленными XEP-ами, которые так и не были никогда не реализованы во многих его клиентах. Например, до сих пор не существует ни одного Jabber-клиента c нормальной синхронизацией истории с сервером.

Почему не Signal?

Потому что Signal не поддерживает децентрализацию (в формате федерации).

Почему не Telegram?

Потому что исходные коды протокола MTProto, который используется в Telegram, никогда не были опубликованы.

Конечно, Telegram больше любят за его UI/UX — но Element на данный момент почти ничем не уступает Telegram: там есть и мосты, и комнаты, и боты, и даже стикеры — а вот людей относительно мало. К сожалению, проекту в действительности не хватает хорошего пиара.

Как подключиться к Matrix через чужой сервер

Это очень просто — просто используйте веб-клиент Element или его десктопную версию. Регистрация не займёт у вас больше минуты.

Как подключиться к Matrix через свой сервер

Для этого необходимо настроить свой HomeServer на Synapse — официальном сервере Matrix. Ниже я привёл инструкции, как это можно сделать.

Процесс настройки сервера Synapse мало чем отличается на разных дистрибутивах Linux — основное отличие заключается в том, какую команду необходимо отдать операционной системе, чтобы та поняла, какой пакетный менеджер нужно использовать для установки.

Я буду объяснять на примере дистрибутива Ubuntu Server 20.04.

Шаг 1. Установка сервера Synapse

Подготавливаем нашу рабочую среду к установке сервера Synapse:

Загружаем непосредственно сам Synapse:

sudo apt update
sudo apt install matrix-synapse-py3

В процессе установки пакета будет запрошено название доменного имени, на котором будет располагаться ваш сервер Synapse. Как правило, это домен вида matrix.example.com, где A-запись поддомена matrix указывает непосредственно на ваш сервер с запущенным Synapse.

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

На этом установка сервера Synapse завершена. Теперь необходимо включить Synapse при загрузке операционной системы:

systemctl start matrix-synapse
systemctl enable matrix-synapse

Мы также можем убедиться, как идут дела у сервера и работает ли он в принципе:

systemctl status matrix-synapse
ss -plnt

Шаг 2. Настройка сервера Synapse

Используйте текстовый редактор (например, nano или vim) и откройте файл /etc/matrix-synapse/homeserver.yaml для редактирования.

Найдите строку listeners: и приведите секцию в следующий вид:

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

После сохранения файла с настройками не забудьте перезапустить Synapse:

systemctl restart matrix-synapse

Шаг 3. Настройка Let’s Encrypt

Для начала необходимо установить certbot — программу для выпуска сертификатов:

sudo apt install certbot -y

И выпустить сертификат для вашего доменного имени:

Готово. Ваш сертификат теперь находится по адресу /etc/letsencrypt/live/matrix.example.com/.

Шаг 4. Настройка Nginx в качестве Reverse Proxy

В этой конфигурации мы будем использовать 80 порт для незащищённого соединения, 443 — для защищённого и 8448 для подключения к федерации Matrix.

ssl_certificate /etc/letsencrypt/live/example.com/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;

ssl_certificate /etc/letsencrypt/live/example.com/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;

Не забудьте перезагрузить Nginx после внесения изменений в конфигурацию:

systemctl restart nginx

Шаг 5. Регистрация нового пользователя

Теперь зарегистрируйте нового пользователя, под которым вы будете заходить на сервер:

Мои поздравления, теперь вы — полноценный участник сети Matrix с собственным сервером.

Первый-первый, я второй! Как слышно? Приём!

Можете написать мне, если хотите проверить, правильно ли вы настроили сервер.

Matrix Specification

This repository contains the Matrix Specification. The current release version is rendered at https://spec.matrix.org, while the latest available build of the main branch is at https://spec.matrix.org/unstable.

Developers looking to use Matrix should join #matrix-dev:matrix.org
on Matrix for help.

Spec authors and proposal writers are welcome to join #matrix-spec:matrix.org.
We welcome contributions! See CONTRIBUTING.rst for details.

Structure

  • /assets: assets that need postprocessing using Hugo Pipes.
    For example, Sass files would go here.

  • /content: files that will become pages in the site go here. Typically these are Markdown files with some YAML front
    matter indicating, among other things, what layout should be
    applied to this page. The organization of files under /content determines the organization of pages in the built
    site.

  • /data: this can contain TOML, YAML, or JSON files. Files kept here are directly available to template code as
    data objects, so templates don’t need to load them from a file and
    parse them. This is also where our Swagger/OpenAPI definitions and schemas are.

  • /layouts: this contains Hugo templates. Some templates define the overall layout of
    a page: for example, whether it has header, footer, sidebar, and so on.

    • /layouts/partials: these templates can be called from other templates, so they can be used to factor out
      template code that’s used in more than one template. An obvious example here is something like a sidebar, where
      several different page layouts might all include the sidebar. But also, partial templates can return values: this
      means they can be used like functions, that can be called by multiple templates to do some common processing.
    • /layouts/shortcodes: these templates can be called directly from files in /content.
  • /static: static files which don’t need preprocessing. JS or CSS files could live here.

  • /themes: you can use just Hugo or use it with a theme. Themes primarily provide additional templates, which are
    supplied in a /themes/$theme_name/layouts directory. You can use a theme but customise it by providing your own
    versions of any of the theme layouts in the base /layouts directory. That is, if a theme provides
    /themes/$theme_name/layouts/sidebar.html and you provide /layouts/sidebar.html, then your version of the
    template will be used.

  • config.toml: site-wide configuration settings. Some of these are built-in and you can add your own. Config settings
    defined here are available in templates. All these directories above are configurable via config.toml settings.
  • /attic: Here contains historical sections of specification and legacy drafts for the specification.
  • /changelogs: Various bits of changelog for the specification areas.
  • /data-definitions: Bits of structured data consumable by Matrix implementations.
  • /meta: Documentation relating to the spec’s processes that are otherwise untracked (release instructions, etc).
  • /scripts: Various scripts for generating the spec and validating its contents.

Authoring changes to the spec

Please read CONTRIBUTING.rst before authoring a change to the spec. Note that spec authoring takes
place after an MSC has been accepted, not as part of a proposal itself.

  1. Install the extended version (often the OS default) of Hugo:
    https://gohugo.io/getting-started/installing. Note that at least Hugo
    v0.93.0 is required.

    Alternatively, use the Docker image at
    https://hub.docker.com/r/klakegg/hugo/. (The «extended edition» is required
    to process the SCSS.)

  2. Run npm i to install the dependencies and fetch the docsy git submodule.
    Note that this will require NodeJS to be installed.

  3. Run npm run get-proposals to seed proposal data. This is merely for populating the content of the «Spec Change Proposals»
    page and is not required.

  4. Run hugo serve (or docker run --rm -it -v $(pwd):/src -p 1313:1313 klakegg/hugo:ext serve) to run a local webserver which builds whenever a file
    change is detected. If watching doesn’t appear to be working for you, try
    adding --disableFastRender to the commandline.

  5. Edit the specification 🙂

We use a highly customized Docsy theme for our generated site, which uses Bootstrap and Font
Awesome. If you’re looking at making design-related changes to the spec site, please coordinate with us in
#matrix-docs:matrix.org before opening a PR.

Building the specification

For building the swagger definitions, create a python3 virtualenv and activate it. Then run pip install -r ./scripts/requirements.txt
and finally python ./scripts/dump-swagger.py to generate it to ./scripts/swagger/api-docs.json. To make use of the generated file,
there are a number of options:

  • You can open ./scripts/swagger-preview.html in your browser, and then open the file by clicking on Local JSON File.
  • You can run a local HTTP server by running ./scripts/swagger-http-server.py, and then view the documentation by
    opening ./scripts/swagger-preview.html in your browser.

Issue tracking

Specification issues are tracked on github at https://github.com/matrix-org/matrix-spec/issues.

See meta/github-labels.rst for information on what the labels mean.

Matrix используется тайными агентами и госслужбами для отправки и получения сверхсекретной информации.

Сразу после избрания Эмманюэля Макрона президентом Франции в 2017 году его команда столкнулась с огромной проблемой – их личная переписка была недостаточно защищена от посторонних глаз. На протяжении всей своей предвыборной кампании Macron и его команда полагались на возможности Telegram – приложения для конфиденциального обмена сообщениями, которое было создано российским диссидентом Павлом Дуровым.

Читайте также:  Эффективное меню SH Битрикс для упрощенного управления сайтом

Из множества доступных решений был найден проект с открытым исходным кодом, для которого разработали новый протокол сквозного шифрования. Он получил название Matrix – офисы его разработчиков находятся в Лондоне и Ренн (Франция), что также подходило французскому правительству. «Это редкий случай, когда французам и англичанам удается эффективно сотрудничать», — говорит соучредитель Matrix Мэтью Ходжсон. Он и его коллега Амандин начали вместе работать над данным проектом еще в 2014 году в качестве членов израильской ИТ-компании Amdocs. Они хотели создать систему обмена сообщениями, которая была бы децентрализована, а не управлялась бы одной компанией, что делало бы ее безопасной по умолчанию. Подобная система могла бы потенциально взаимодействовать и с другими платформами для общения.

«Мы, вероятно, совершили успешную попытку создать новый открытый стандарт для подобного рода коммуникаций», — говорит Амандин.

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

На картинке ниже представлены три сервера Matrix, к каждому из которых подключен один клиент.

Протокол и имя матрицы уже используются

Все клиенты участвуют в одной и той же комнате Matrix, которая синхронизируется между тремя участвующими серверами.

Более подробно о том, как это работает вы можете посмотреть в интерактивной демонстрации на официальном сайте https://matrix.org.

Любой желающий может использовать протокол Matrix на своих серверах или участвовать в чатах, размещенных на других серверах. Во Франции специально для государственных переписок правительство разработало систему, ориентированную на несколько отдельных серверов, доступных каждому министерству.

Архитектура Matrix показалась привлекательной по крайней мере еще трем странам, помимо самой Франции, некоторым службам безопасности и военным организациям (включая немецкую армию), а также крупным ИТ-корпорациям, таким как Mozilla. По состоянию на начало 2021 года протокол Matrix использовался для более чем 28 миллионов учетных записей по всему миру.

Протокол и имя матрицы уже используются
Интерфейс мессенджера Element на базе протокола Matrix

В 2017 году Ходжсон и его коллега выпустили приложение на базе Matrix под названием Element. К концу 2021 года они надеются добавить в него функцию, которая позволит пользователям обмениваться P2P-сообщениями без подключения к Интернету, создавая ячеистые сети с поддержкой Bluetooth. «Это будет совершенно новый способ общения – гораздо легче и проще того, который доступен нам сейчас».

По материалам Wired.


Подписывайся на Эксплойт в Telegram, чтобы не пропустить новые компьютерные трюки, хитрости смартфонов и секреты безопасности в интернете.




Welcome! This website aims to be a beginner-friendly guide to Matrix (sometimes mistakenly known as Element). Matrix is an open federated communication protocol that strives to be a viable alternative to various centralized proprietary platforms. But those are very big words, and unfortunately, they do confuse people sometimes, so this guide aims to introduce you to the chatting aspect of it in somewhat simpler terms. We’ll start by the “why” and then the “how.” This part is for people who have never used Matrix before, so if you’re looking for more advanced material, check out the sidebar.

Why Matrix?

  • Freedom. You get to choose how to use the platform and how your data is treated.
    • Conversations can be end-to-end encrypted1. This is enabled by default for direct and group messages2.
    • Automatic collection of data is minimized: no address book syncing3, no “are you human?” checks beyond registration, phone numbers are optional, even email addresses are optional (on select homeservers)!
    • You can host your own server, or you can join an existing public homeserver that suits you. Either way, your access to the Matrix federation is the same4!
    • Bridges allow you to chat with users on other platforms, minimizing the social cost of moving to Matrix!
    • Since Matrix is an open protocol, it is extensible and can be used for purposes beyond just chatting. For example: help desk, social media, real-time collaboration…
  • Trust. You get to actually trust the software you use.
    • Matrix is an open protocol, and most5 of its apps and servers6 are both open source, which you may contribute to!
    • Matrix is federated, just like email: Unlike conventional platforms which are centralized, no single specific entity can control the entirety of the Matrix federation, where homeservers, operated independently from each other, communicate with each other using an agreed-upon protocol.
      • Furthermore, while individual homeservers may experience outage, the entire federation cannot go offline.
    • You are welcomed to improve Matrix by creating new apps around it, or by reviewing or submitting proposals. You can shape your platform towards a better direction!
    • Matrix is backed by the public sector, most notably by the Germans (healthcare, army, universities) as well as the French.

And of course, Matrix has everything that a modern messaging platform offers: cross-platform, real-time, usefulness, etc. But that’s not the point. Matrix shows that it is possible to have a decent chat platform that actually respects you.

If these reasons did not convince you, how about comparing Matrix with other platforms like Discord and Telegram?

Get Started

Ready to try Matrix? Here we go:

Is it Matrix or Element?

  • Matrix is the protocol, developed by the UK-registered non-profit The Matrix.org Foundation C.I.C.. It can also refer to the entire Matrix federation that contains all the users and rooms.
  • Element (previously known as Riot.im) is the flagship app of Matrix, developed by the UK-registered for-profit New Vector Ltd. It can also refer to commercial services that the company offers, such as Element Matrix Services.

As touched upon later, Element is just one of the apps that accesses Matrix. It is therefore correct to refer to the platform as just “Matrix.” Though, nobody is stopping you from calling it The Matrix.

Set up your own homeserver, or join an existing homeserver?

If you have the infrastructure and the technical skills required to host an internet-facing program, then you can try setting up your own homeserver6. The dominant homeserver implementation is Synapse. See installation instructions. It may be possible to run a homeserver for free with Oracle Cloud.

  • Join an existing homeserver by picking one from our public homeserver list, or
  • Reaching out to a friend who hosts a homeserver, or
  • Purchase managed homeserver hosting.

Register an account

This part does not cover cases where a homeserver uses its own authentication tools. In such cases, please consult your homeserver’s instructions.

For simplicity, the guide is prepared in such a way that recommends registration on a PC browser, even though many servers allow you to do so from native PC/mobile apps. Regardless, once registered, you can use the account everywhere!

  1. If you’re using our homeserver list which has provided you with a link to the homeserver’s in-house Element client, then you may use that. Otherwise, use the official Element Web client to register.
  2. Click “Create Account”.
  3. On the top of the registration dialog, verify that you are registering on the correct server. If necessary, click “edit” and enter the appropriate domain (consult your public/private/managed homeserver’s instructions, or the “Registration method” column of the homeserver list). Once verified, note the domain down. You will need it to login7.
  4. Fill out the required information.
  5. If you did not enter an email address, then you’re in. Otherwise, verify your email, after which you will be prompted to login.

Remember to set up key backup!

Log into an existing account

For most apps:

  1. Enter the login dialog, if necessary.
  2. Verify that you are logging onto the correct server. This is usually shown on top of the dialog. If necessary, click “edit” and enter the appropriate domain (see Step 3 of registration).
  3. Enter your login details.

Set up key backup

When you log into a new device, you will be prompted to verify it using your existing device (by scanning a QR code or by comparing emojis). Your new device will then retrieve the room keys from your existing device, thereby enabling it to read your encrypted messages. This prevents anyone else — including your homeserver operator — to read encrypted content1.

However, a Security Key is required to access encrypted messages if:

  • You have logged out of all your sessions prior to this login, or
  • You are unable to verify interactively from another session.
  1. On your first login, a bubble on the top-left will ask you to “set up secure backup”. Click “Continue”. If that is not the case, click your avatar, then “Settings” -> “Security & Privacy” -> “Secure Backup” -> click “Set up”.
  2. “Generate a Security Key” is enough.
  3. Save the generated security key in a safe place (like in a password manager).

A graphic tutorial is available here.

It is strongly recommended to do this step to prevent accidentally losing all of your encrypted messages.

Get Familiar

What app should I use?

There exists many different apps that can access Matrix. Because Matrix is an open protocol, you can even implement Matrix in your own app, if you got the skills. But for most people, here are some recommendations:

Browser

  • Element: The flagship app.
  • Cinny: The app with elegant and modern UI.
  • Hydrogen: Fast and adaptable to mobile browsers, at the cost of missing some optional features.

PC and Mobile

  • Element: The flagship app.
  • FluffyChat: “Cute” Matrix. Recommended to be used on mobile for performance.

For those living on the edge: Commune, Nheko, Spectral, and Syphon.

What rooms can I join?

  • On PC, for Element and SchildiChat, click the “Explore Rooms” button below your username on the top-left.
  • For FluffyChat, and for Element and SchildiChat on phone, click the search button.

In any case mentioned above, you can enter the room address to directly join a room, or you can enter keywords to search for rooms8. However, the directory may be unintuitive to use as it orders rooms by member count9. The author of this guide recommends joining this Space (#offtopic-space:envs.net), which contains a list of active off-topic or no-topic discussion rooms.

Hold on, what’s a Space?

On Element and SchildiChat, Spaces show up on the left of your room list. Selecting one will filter your room list to DMs with members of the Space and joined rooms within the Space. To see rooms that you have not yet joined, click the Explore button (see above).

Читайте также:  Глава 4. Обновление с Debian 11 (bullseye)

Go Deeper

The names of your sessions are public, which enable others to know what OS you’re using (it used to be accurate to devices but that is no longer the case). You can rename them, however (as long as you know which is which):

  • In Element/SchildiChat, go to user settings, then «Security & Privacy.» Rename the sessions as needed.
  • In FluffyChat, go to settings, then «devices.» Click the sessions to rename them.

@matrix-org

Pinned


Repositories

<!— —>
































  • synapse

    Synapse: Matrix homeserver written in Python/Twisted.

  • 934

    766

    2

    209


    Updated Apr 25, 2023


  • thirdroom

    Open, decentralised, immersive worlds built on Matrix

    459

    43

    86

    7


    Updated Apr 25, 2023

  • 425

    137

    437

    23


    Updated Apr 25, 2023

Most used topics

I have some concerns about Matrix (the protocol, not the movie that
came out recently, although I do have concerns about that as
well). I’ve been watching the project for a long time, and it seems
more a promising alternative to many protocols like IRC, XMPP, and
Signal.

This review may sound a bit negative, because it focuses on those
concerns. I am the operator of an IRC network and people keep asking
me to bridge it with Matrix. I have myself considered just giving up
on IRC and converting to Matrix. This space is a living document
exploring my research of that problem space. The TL;DR: is that no,
I’m not setting up a bridge just yet, and I’m still on IRC.

This article was written over the course of the last three months, but
I have been watching the Matrix project for years (my logs seem to say
2016 at least). The article is rather long. It will likely take you
half an hour to read, so copy this over to your ebook reader,
your tablet, or dead trees, and lean back and relax as I show you
around the Matrix. Or, alternatively, just jump to a section that
interest you, most likely the conclusion.

Introduction to Matrix

Matrix is an «open standard for interoperable, decentralised,
real-time communication over IP. It can be used to power Instant
Messaging, VoIP/WebRTC signalling, Internet of Things communication —
or anywhere you need a standard HTTP API for publishing and
subscribing to data whilst tracking the conversation history».

It’s also (when compared with XMPP) «an eventually consistent
global JSON database with an HTTP API and pubsub semantics — whilst
XMPP can be thought of as a message passing protocol.»

Security and privacy

I have some concerns about the security promises of Matrix. It’s
advertised as a «secure» with «E2E [end-to-end] encryption», but how
does it actually work?

Data retention defaults

One of my main concerns with Matrix is data retention, which is a key
part of security in a threat model where (for example) an hostile
state actor wants to surveil your communications and can seize your
devices.

Compare this to Matrix: when you send a message to a Matrix
homeserver, that server first stores it in its internal SQL
database. Then it will transmit that message to all clients connected
to that server and room, and to all other servers that have clients
connected to that room. Those remote servers, in turn, will keep a
copy of that message and all its metadata in their own database, by
default forever. On encrypted rooms those messages are encrypted, but
not their metadata.

There is a mechanism to expire entries in Synapse, but it is not
enabled by default
. So one should generally assume that a message
sent on Matrix is never expired.

In the context of the GDPR, this is really tricky: who is the
responsible party (known as the «data controller») here? It’s
basically any yahoo who fires up a home server and joins a room.

In a federated network, one has to wonder whether GDPR enforcement is
even possible at all. But in Matrix in particular, if you want to
enforce your right to be forgotten in a given room, you would have to:

  1. enumerate all the users that ever joined the room while you were
    there
  2. discover all their home servers
  3. start a GDPR procedure against all those servers

I recognize this is a hard problem to solve while still keeping an
open ecosystem. But I believe that Matrix should have much stricter
defaults towards data retention than right now. Message expiry should
be enforced by default, for example. (Note that there are also
redaction policies that could be used to implement part of the GDPR
automatically, see the privacy policy discussion below on that.)

Also keep in mind that, in the brave new peer-to-peer world that
Matrix is heading towards, the boundary between server and client is
likely to be fuzzier, which would make applying the GDPR even more difficult.

Update: this comment links to this post (in german) which
apparently studied the question and concluded that Matrix is not
GDPR-compliant.

In fact, maybe Synapse should be designed so that there’s no
configurable flag to turn off data retention. A bit like how most
system loggers in UNIX (e.g. syslog) come with a log retention system
that typically rotate logs after a few weeks or month. Historically,
this was designed to keep hard drives from filling up, but it also has
the added benefit of limiting the amount of personal information kept
on disk in this modern day. (Arguably, syslog doesn’t rotate logs on
its own, but, say, Debian GNU/Linux, as an installed system, does have
log retention policies well defined for installed packages, and those
can be discussed. And «no expiry» is definitely a bug.

Matrix. org privacy policy

When I first looked at Matrix, five years ago, Element.io was called
Riot.im and had a rather dubious privacy policy:

We currently use cookies to support our use of Google Analytics on
the Website and Service. Google Analytics collects information about
how you use the Website and Service.

This helps us to provide you with a good experience when you
browse our Website and use our Service and also allows us to improve
our Website and our Service.

When I asked Matrix people about why they were using Google Analytics,
they explained this was for development purposes and they were aiming
for velocity at the time, not privacy (paraphrasing here).

They also included a «free to snitch» clause:

Those are really broad terms, above and beyond what is typically
expected legally.

Notable points of the new privacy policies:

  • 2.3.1.1: the «federation» section actually outlines that
    «Federated homeservers and Matrix clients which respect the Matrix
    protocol are expected to honour these controls and
    redaction/erasure requests, but other federated homeservers are
    outside of the span of control of Element, and we cannot guarantee
    how this data will be processed
    «
  • 2.6: users under the age of 16 should not use the
    matrix.org service
  • 2.10: Upcloud, Mythic Beast, Amazon, and CloudFlare possibly
    have access to your data (it’s nice to at least mention this in the
    privacy policy: many providers don’t even bother admitting to this
    kind of delegation)
  • Element 2.2.1: mentions many more third parties (Twilio,
    Stripe, Quaderno, LinkedIn, Twitter, Google, Outplay,
    PipeDrive, HubSpot, Posthog, Sentry, and Matomo
    (phew!) used when you are paying Matrix.org for hosting

I’m not super happy with all the trackers they have on the Element
platform, but then again you don’t have to use that service. Your
favorite homeserver (assuming you are not on Matrix.org) probably has
their own Element deployment, hopefully without all that garbage.

Overall, this is all a huge improvement over the previous privacy
policy, so hats off to the Matrix people for figuring out a reasonable
policy in such a tricky context. I particularly like this bit:

We will forget your copy of your data upon your request. We will
also forward your request to be forgotten onto federated
homeservers. However — these homeservers are outside our span of
control, so we cannot guarantee they will forget your data.

It’s great they implemented those mechanisms and, after all, if
there’s an hostile party in there, nothing can prevent them from using
screenshots to just exfiltrate your data away from the client side
anyways, even with services typically seen as more secure, like
Signal.

As an aside, I also appreciate that Matrix.org has a fairly decent
code of conduct, based on the TODO CoC which checks all the
boxes in the geekfeminism wiki.

Overall, privacy protections in Matrix mostly concern message
contents, not metadata. In other words, who’s talking with who, when
and from where is not well protected. Compared to a tool like Signal,
which goes through great lengths to anonymize that data with features
like private contact discovery, disappearing messages,
sealed senders, and private groups, Matrix is definitely
behind. (Note: there is an issue open about message lifetimes in
Element
since 2020, but it’s not at even at the MSC stage yet.)

Combine this with the federation: even if you trust your home server
to do the right thing, the second you join a public room with
third-party home servers, those ideas kind of get thrown out because
those servers can do whatever they want with that information. Again,
a problem that is hard to solve in any federation.

Amplification attacks on URL previews

I feel this outlines a security issue, especially because those
sockets would be kept open seemingly forever. I tried to warn the
Matrix security team but somehow, I don’t think this issue was taken
very seriously. Here’s the disclosure timeline:

  • January 18: contacted Matrix security
  • January 19: response: already reported as a bug
  • January 20: response: can’t reproduce
  • January 31: timeout added, considered solved
  • January 31: I respond that I believe the security issue is
    underestimated, ask for clearance to disclose
  • February 1: response: asking for two weeks delay after the next
    release (1.53.0) including another patch, presumably in two
    weeks’ time
  • February 22: Matrix 1.53.0 released
  • April 14: I notice the release, ask for clearance again
  • April 14: response: referred to the public disclosure

There are a couple of problems here:

  1. the bug was publicly disclosed in September 2020, and not
    considered a security issue until I notified them, and even then,
    I had to insist

  2. no clear disclosure policy timeline was proposed or seems
    established in the project (there is a security disclosure
    policy
    but it doesn’t include any predefined timeline)

  3. I wasn’t informed of the disclosure

  4. the actual solution is a size limit (10MB, already implemented), a
    time limit (30 seconds, implemented in PR 11784), and a
    content type allow list (HTML, «media» or JSON, implemented in PR
    11936
    ), and I’m not sure it’s adequate

  5. (pure vanity:) I did not make it to their Hall of fame

I’m not sure those solutions are adequate because they all seem to
assume a single home server will pull that one URL for a little while
then stop. But in a federated network, many (possibly thousands)
home servers may be connected in a single room at once. If an attacker
drops a link into such a room, all those servers would connect to
that link all at once. This is an amplification attack: a small
amount of traffic will generate a lot more traffic to a single
target. It doesn’t matter there are size or time limits: the
amplification is what matters here.

It should also be noted that clients that generate link previews
have more amplification because they are more numerous than
servers. And of course, the default Matrix client (Element) does
generate link previews as well.

That said, this is possibly not a problem specific to Matrix: any
federated service that generates link previews may suffer from this.

I’m honestly not sure what the solution is here. Maybe moderation?
Maybe link previews are just evil? All I know is there was this weird
bug in my Icecast server and I tried to ring the bell about it, and it
feels it was swept under the rug. Somehow I feel this is bound to blow
up again in the future, even with the current mitigation.

Moderation

In Matrix like elsewhere, Moderation is a hard problem. There is a
detailed moderation guide and much of this problem space is
actively worked on in Matrix right now. A fundamental problem with
moderating a federated space is that a user banned from a room can
rejoin the room from another server. This is why spam is such a
problem in Email, and why IRC networks have stopped federating ages
ago (see the IRC history for that fascinating story).

The mjolnir bot

There’s also a new command line tool designed to do things like:

  • System notify users (all users/users from a list, specific user)
  • delete sessions/devices not seen for X days
  • purge the remote media cache
  • select rooms with various criteria (external/local/empty/created by/encrypted/cleartext)
  • purge history of theses rooms
  • shutdown rooms

Rate limiting

Synapse has pretty good built-in rate-limiting which blocks
repeated login, registration, joining, or messaging attempts. It may
also end up throttling servers on the federation based on those
settings.

Room admins

This is even more frustrating when you consider that Matrix events are
actually signed and therefore have some authentication attached
to them, acting like some sort of Merkle tree (as it contains a link
to previous events). That signature, however, is made from the
homeserver PKI keys, not the client’s E2E keys, which makes E2E feel
like it has been «bolted on» later.

Update: note that this flaw has actually been called a «serious
vulnerability
» by Ars Technica, based on a paper from
researchers
that confirmed the flaw I hinted at above. The
response from Matrix.org has been rather underwhelming, with many
issues still unaddressed.

Availability

While Matrix has a strong advantage over Signal in that it’s
decentralized (so anyone can run their own homeserver,), I couldn’t
find an easy way to run a «multi-primary» setup, or even a «redundant»
setup (even if with a single primary backend), short of going full-on
«replicate PostgreSQL and Redis data», which is not typically for the
faint of heart.

How this works in IRC

On IRC, it’s quite easy to setup redundant nodes. All you need is:

  1. a new machine (with it’s own public address with an open port)

Rooms

(Finding this in the Element settings is not obvious though, because
that «alias» are actually called a «local address» there. So to create
such an alias (in Element), you need to go in the room settings’
«General» section, «Show more» in «Local address», then add the alias
name (e.g. foo), and then that room will be available on your
example.com homeserver as #foo:example.com.)

A room is therefore not fundamentally addressed with the above alias.
Instead, it has a internal Matrix ID, which basically a random
string. It has a server name attached to it, but that was made just to
avoid collisions. That can get a little confusing. For example, the
#fractal:gnome.org room is an alias on the gnome.org server, but
the room ID is !hwiGbsdSTZIwSRfybq:matrix.org. That’s because the
room was created on matrix.org, but the preferred branding is
gnome.org now.

Spaces

Discovering rooms can be tricky: there is a per-server room
directory, but Matrix.org people are trying to deprecate it in favor
of «Spaces». Room directories were ripe for abuse: anyone can create a
room, so anyone can show up in there. It’s possible to restrict who
can add aliases, but anyways directories were seen as too limited.

Home servers

So my guess is it would be possible to create a «warm» spare server of
a matrix home server with regular PostgreSQL replication, but
that is not documented in the Synapse manual. This sort of setup
would also not be useful to deal with networking issues or denial of
service attacks, as you will not be able to spread the load over
multiple network locations easily. Redis and PostgreSQL heroes are
welcome to provide their multi-primary solution in the comments. In
the meantime, I’ll just point out this is a solution that’s handled
somewhat more gracefully in IRC, by having the possibility of
delegating the authentication layer.

Update: this was previously undocumented, but not only can you scale
the frontend workers to multiple hosts, you can also shard the
backend so that tables are distributed across multiple database
hots. This has been documented only on 2022-07-11, weeks after
this article was written, so you will forgive me for that omission,
hopefully. Obviously, this doesn’t resolve the «high availability»
scenario since you still have a central server for that data, but it
might help resolving performance problems for very large instances.

Delegations

If you do not want to run a Matrix server yourself, it’s possible to
delegate the entire thing to another server. There’s a server
discovery API
which uses the .well-known pattern (or SRV
records, but that’s «not recommended» and a bit confusing) to
delegate that service to another server. Be warned that the server
still needs to be explicitly configured for your domain. You can’t
just put:

{ "m.server": "matrix.org:443" }

The server discovery API is what allows servers to find each
other. Clients, on the other hand, use the client-server discovery
API
: this is what allows a given client to find your home server
when you type your Matrix ID on login.

Performance

The high availability discussion brushed over the performance of
Matrix itself, but let’s now dig into that.

Horizontal scalability

There were serious scalability issues of the main Matrix server,
Synapse, in the past. So the Matrix team has been working hard to
improve its design. Since Synapse 1.22 the home server can
horizontally scale to multiple workers (see this blog post for details)
which can make it easier to scale large servers.

Other implementations

There are other promising home servers implementations from a
performance standpoint (dendrite, Golang, entered beta in late
2020
; conduit, Rust, beta; others), but none of those
are feature-complete so there’s a trade-off to be made there. Synapse
is also adding a lot of feature fast, so it’s an open question whether
the others will ever catch up. (I have heard that Dendrite might
actually surpass Synapse in features within a few years, which would
put Synapse in a more «LTS» situation.)

Latency

Matrix can feel slow sometimes. For example, joining the «Matrix HQ»
room in Element (from matrix.debian.social) takes a few minutes
and then fails. That is because the home server has to sync the
entire room state when you join the room. There was promising work on
this announced in the lengthy 2021 retrospective, and some of
that work landed (partial sync) in the 1.53 release already.
Other improvements coming include sliding sync, lazy loading
over federation
, and fast room joins. So that’s actually
something that could be fixed in the fairly short term.

But in general, communication in Matrix doesn’t feel as «snappy» as on
IRC or even Signal. It’s hard to quantify this without instrumenting a
full latency test bed (for example the tools I used in the terminal
emulators latency tests
), but
even just typing in a web browser feels slower than typing in a xterm
or Emacs for me.

Transport

Some courageous person actually made some tests of various
messaging platforms on a congested network
. His evaluation was
basically:

  • Briar: uses Tor, so unusable except locally
  • Matrix: «struggled to send and receive messages», joining a room
    takes forever as it has to sync all history, «took 20-30 seconds
    for my messages to be sent and another 20 seconds for further
    responses»
  • XMPP: «worked in real-time, full encryption, with nearly zero
    lag»

So that was interesting. I suspect IRC would have also fared better,
but that’s just a feeling.

Other improvements to the transport layer include support for
websocket
and the CoAP proxy work from 2019 (targeting
100bps links), but both seem stalled at the time of writing. The
Matrix people have also announced the pinecone p2p overlay
network
which aims at solving large, internet-scale routing
problems. See also this talk at FOSDEM 2022.

Update: there is a formal proposal (MSC3079) about a
low-bandwidth, UDP-based transport, but it’s been stuck at that stage
for a few years now, because of security issues inherent to the UDP
protocol, at first glance. There’s also a golang implementation.

Оцените статью
Хостинги