
Enter the Matrix – A technical overview and guide to all things Matrix - babolivier
https://brendan.abolivier.bzh/enter-the-matrix/
======
fb03
What are the differences between Matrix and Jabber?

Jabber implemented a protocol with similar mechanisms several years ago, with
a custom xml protocol which could also pass not only text but also rendezvous
data for voip/video calls and whatever else custom data you could codify.

Jabber has native protocol implementations for both clients and servers and
can handle a reasonable amount of connections with ease. Clients are available
throughout all platforms.

I'm asking this question because I believe the reason Jabber "failed" (read:
didn't catch as much as other closed alternatives like WhatsApp) wasn't
because of technology hurdles, because it was poised to solve the very same
problem Matrix works against - which is 'IM fragmentation', but actually a
lack of a proper plan to generate interest with its intended population.

I'd say work on your release plan and make your clients 'tasty' and snappy,
because technologically speaking, I believe Jabber has already solved all the
technological problems Matrix strives for.... and it sadly wasn't enough.

~~~
Arathorn
One use of Matrix is defragmenting IM, and it's true that both XMPP and Matrix
can be used to power chat systems.

However, architecturally they really couldn't be more different:

* Matrix's main data primitive is synchronising conversation history within a room - _not_ message passing. In fact, there is no way to just 'send a user a message' in Matrix: instead, you can only synchronise your copy of a room's state and history with someone else's copy of it.

* Matrix rooms are replicated equally over all participating servers - there is no focal point as there is in a XMPP MUC.

* Matrix provides a single monolithic (beta) spec, which compliant clients have to implement (for a given class of clients). There are no optional features or competing extension proposals for a given feature for a given class of client (e.g. 'desktop messenger'), to try to avoid fragmentation.

* Matrix's baseline transport and encoding is super-simple-stupid HTTP+JSON, but with room for folks to propose superior transports & encodings as we see fit. So far there's been WS+JSON (which nobody seems to use, as it's not that massive an improvement over HTTP+JSON), and this year there's a GSoC project to look at MQTT-and-similar as an alternative.

~~~
seba_dos1
IOW, Matrix is best suited for replacing IRC or Slack, for communication
around organized teams/communities or topical conversations with strangers;
while Jabber/XMPP is a better Facebook Messenger, WhatsApp, Hangouts or Gadu-
Gadu, best for staying in touch with friends and talking in ad-hoc group chats
between them.

Plus, XMPP can be used for great amount of stuff non-IM related, while Matrix
seems very focused around its IRC-like use case, where XMPP doesn't really
improve much over IRC.

~~~
babolivier
> Plus, XMPP can be used for great amount of stuff non-IM related, while
> Matrix seems very focused around its IRC-like use case

I don't really agree here. While Riot is focused on a IM use of Matrix, Matrix
itself is open enough to be usable in any use case requiring a payload to
travel from A to B. You could think of Matrix use in IoT, social networks,
forums, etc. Some people even made a working PoC of a blog using Matrix, and I
heard some others are also working on building a system to bypass information
censorship using Matrix as its only back-end.

I don't know XMPP enough to state which spec is wider than the other, but what
I know is that Matrix isn't limited by what Riot or other Matrix-based IM
clients can do.

~~~
seba_dos1
Of course you can (ab)use a lot of protocols in various ways, however, XMPP
was designed with this extensibility in mind and that's exactly why its basic
RFC is so minimal. Heck, even basic instant messaging over XMPP is defined in
a separate RFC (RFC 6120 for Core and RFC 6121 for XMPP-IM).

GP already stressed it out:

> Matrix's main data primitive is synchronising conversation history within a
> room - not message passing.

So Matrix might be well suited for things like blogs, but XMPP will be
certainly better for push notifications, for instance. However, you can easily
build Matrix-like primitives on top of XMPP, while the other way around will
be less flexible.

~~~
bsummer4
But flexibility is the problem with XMPP in the first place. None of the
clients and servers have compatible feature sets.

------
fcanela
It is nice to see Matrix in HN: this project needs more visibility.

In a world dominated by Slack, which removes privacy/history control from
users and place walls, Matrix is the promise to have a better open scenario
than IRC was.

I am crossing my fingers. I hope with all my heart to this technology to
flourish.

------
sleepless
Just a user, but I think Matrix needs to

\- work on stability: the status quo is unreliable. Until this is solved it's
hard to recommend Matrix to anybody who is looking to use it for serious work

\- disable signup on main server: this is a decentralized netword and the main
server is overloaded already. It is overloaded so badly, that devs decided to
turn off presence for as long as I can remember first seeing matrix. So even
IRC is more usable in that regard because I know when I see a user they are
online or they even have presence and an away message

There's more but those are two issues I think should be dealt with urgently.

~~~
thereandhere
You bring up a good point about disabling signup on the main server.

I've recently been wondering why the Matrix team wouldn't want to lose some of
the control they have over the Matrix universe..

They could solve their scalability problem by bringing up other homeservers
(why not a paid riot.im server even?) or promoting other open servers hosted
by the community.

Seems like Mastodon folks are favoring horizontal scalability by making people
use various servers, but the Matrix team wants to keep mostly everyone on
matrix.org.

(I hope this doesn't sound too negative.. I know it's not like Matrix folks
want to centralize things.. It's just, I wonder why they don't promote other
homeservers more)

~~~
heavenlyhash
I'm on the public Matrix.org server and I recommend new folks to sign up on
the public server unless they're 100% sure they're willing to commit to the
devops burden of maintaining their own homeserver.

I also know at least a halfdozen people who immediately said "yes" to the
devops burden of maintaining their own homeserver (and reportedly, it's
actually really easy).

Different strokes for different folks. If self-hosting it was a pre-req for
using it, I'd still be saying to myself "yeah, I'll do that _riiiight_ after I
get my closet k8s cluster just the way I want it", and, well, I know myself
better than that, so I use the public one, and I'm happy.

~~~
vertex-four
Mastodon gets away with just telling people to go find a server to register
with, you don’t have to self host to get some reasonable level of
decentralisation.

------
aaomidi
If matrix wants to be a thing it needs to get a good and native client for
popular operating systems. Riot isn't a good client.

~~~
Arathorn
There at least 4 good native clients in very active dev atm:

* Fractal ([https://matrix.org/docs/projects/client/fractal.html](https://matrix.org/docs/projects/client/fractal.html)) from the GNOME community (who just had a big hackathon in Strasbourg last week: [https://wiki.gnome.org/action/login/Hackfests/Fractal2018](https://wiki.gnome.org/action/login/Hackfests/Fractal2018)). They're looking to add E2E and VoIP in the relatively near future.

* Nheko ([https://matrix.org/docs/projects/client/nheko.html](https://matrix.org/docs/projects/client/nheko.html)) - a very Telegram-looking Qt client, which has been in very steady progress for ages. They're actively working on E2E right now.

* Quaternion ([https://matrix.org/docs/projects/client/quaternion.html](https://matrix.org/docs/projects/client/quaternion.html)) - a more IRC-like looking Qt/QML client, also in very active dev.

* Gomuks ([https://matrix.org/docs/projects/client/gomuks.html](https://matrix.org/docs/projects/client/gomuks.html)) - this one's new; a really nice dedicated text-user-interface client written in Go - again, in very active dev.

Meanwhile we're also doing everything we can to improve Riot, but for desktop
usage a native client will always beat an electron one :)

~~~
vbezhenar
The most popular OS is Windows. And Qt is not a native client, at least for
Windows. Something modern built with UWP would be nice. Second popular OS is
macOS. And native for macOS is Cocoa.

PS not requiring anything, just my 2 cents. I, personally, like Riot.

~~~
Arathorn
Qt's native support on Windows is very very good these days, as apps like the
Telegram desktop client show.

~~~
vbezhenar
Last time I checked, Qt still used completely its own rendering, input
handling, etc, imitating platform. So it's conceptually not different from,
e.g. Java Swing. Probably imitation is better.

That said, Windows is bad at UX consistency. Native used to mean WinAPI with
built-in window classes handling input, buttons, etc (and wrappers like MFC or
Windows Forms). Then it was WPF with its own DirectX-based stack. Now it's UWP
with even different code. I guess, Qt is not the worst solution. macOS is much
more coherent ecosystem when it comes to native.

~~~
vesak
>macOS is much more coherent ecosystem when it comes to native.

Then again if you try to run a gtk3 app like Fractal mentioned above on Mac
OS, you will see that it looks exactly like a Gnome application.

~~~
Arathorn
yup. Qt seems to get it much better on MacOS (at least from comparing Fractal
with Nheko).

------
0x006A
Does E2E work now? Last time I tried, it did not. That was some time ago so
things might have changed. It still is listed as "working on it" for many
clients though.

To develop a new communication platform today without E2E as a core
functionality is odd.

~~~
Arathorn
Yes, it does. The UX is not great but the crypto has been solid since 2016:
[https://matrix.org/blog/2016/11/21/matrixs-olm-end-to-end-
en...](https://matrix.org/blog/2016/11/21/matrixs-olm-end-to-end-encryption-
security-assessment-released-and-implemented-cross-platform-on-riot-at-last/)

~~~
0x006A
for Riot, it still is not enabled by default due to bugs though?

> As of May 2017 Riot’s end-to-end encryption is technically in beta, but this
> is due to some residual stability bugs and missing usability features. Once
> these are resolved we plan to get the full implementation security assessed
> and out of beta. End-to-end encryption will then be turned on by default for
> private conversations.

[https://about.riot.im/security/](https://about.riot.im/security/)

~~~
Arathorn
Yup, we haven't turned it on by default yet - but this no longer really due to
bugs, but missing UX features. The stuff that remains is:

* Cross-signing devices when you sign up to remove verification pain

* Ability to access history from before the point you join the room (if desired)

* Better UX for verification (comparing mnemonic phrases rather than public key fingerprints)

* Ability to optionally back up E2E keys, encrypted, on the server so you don't lose your history if you lose all your devices

* Ability to search E2E rooms (using a clientside search engine)

* ...and fixing any last key management bugs, although right now we believe we've fixed almost all of them.

------
beders
I really would like to have a single chat client. I have friends/business
partners on Skype, WhatsApp, FB Messenger, iMessage, Discord, Slack and (ze
horror)MS Teams.

I wish I had a single app, be it on desktop and mobile, to use, with the
combined feature set of all of those (filtered down to whatever my
communication partner supports). I know: how dare I dream of such a
magnificent beast?

What are the chances Matrix is turning into this?

~~~
babolivier
I'd say they're quite high because not being "yet another IM thing" but rather
becoming the way to bring all comms togeter is one of Matrix's core missions.

Of course it's not there yet, though it's quite likely to get there in the
future.

------
Ace17
From the FAQ:

" Tox.chat looks to be a very cool clone of Skype - a fully decentralised
peer-to-peer network. Matrix is deliberately not a ‘pure’ peer-to-peer system;
instead each user has a well-defined homeserver which stores his data and that
he can depend upon. "

What's the rationale behind "impure" decentralizing? Why not go fully
decentralized like Tox does?

~~~
Arathorn
Battery usage, network utilisation, complexity of implementing clients, and
wanting a more guaranteed home for your data than having it smeared over
endpoints.

That said we will hopefully move to a more hybrid model in time.

------
sam_goody
Can someone point me to a good comparison of Matrix, Mattermost, Zulip,
Rocketchat, IRC and XMPP (say, Prosody) or explain what niche each fills if
they are not competing.

Assuming for a small company with a dozen employees, all of whom sometimes
work remotely.

~~~
dsr_
Let me take a crack at it. This is highly opinionated and probably biased.

IRC is reliable, can be forced into encrypted client-server communications,
and has the fewest client-side features. The strength is the number of
available clients and the primacy of channels (rooms). File-sharing is
available but not a focus. There are lots of bot libraries.

XMPP is reliable, the server can mandate client-server encryption, and has
some client-side features including simultaneous appearances (being one person
logged in through several devices) and better one-to-one chat than IRC. File-
sharing is an optional add-on. There is no good iOS client that I know of;
mobile clients tend to be bad at requesting history.

Mattermost, Zulip and Rocketchat I have the least experience with; they all
seem to be very popular with small groups of users but are complex to install
and have very few clients.

Matrix is promising. It does one-to-one and chat rooms smoothly, server config
is pretty easy, and you can have the server mandate client-server encryption.
There are lots of clients that all seem to be in mid-alpha development. If it
survives a year or two, I think it will be widely adopted.

~~~
fbartels
> Mattermost, Zulip and Rocketchat I have the least experience with; they all
> seem to be very popular with small groups of users but are complex to
> install and have very few clients.

At least for Mattermost I have to disagree with the "complex to install". All
you need is a sql database (MySQL/MariaDB or Postgres), for production you
then also should put a reverse proxy in front.

With "very few clients" you are referring to client software, correct?

~~~
dsr_
Yes.

------
stevenicr
Is this project affecting by the pgp sMIME issues in the news recently?
(starting to learn this matrix thing, thanks in part to this nice synopsis
posted in the article)

~~~
Arathorn
a broken matrix client might fail to sanitise its html messages and be
vulnerable in the same way, but we’re not aware of any that are.

------
clishem
> guide to all things Matrix

> A device is bound to an access token and E2E encryption keys (which I’m not
> covering in this post).

This is far from 'all things Matrix' then.

~~~
AlphaWeaver
That's very nitpicky for such a comprehensive article.

~~~
NetOpWibby
_Sigh_

This is HN, after all.

------
packet_nerd
This is an exciting project but still needs a lot of work (particularly in
making the faster, cleaner, and easier to install).

