
Matrix 1.0 – Are We Ready Yet? - jaywink
https://matrix.org/blog/2019/03/15/matrix-1-0-https-arewereadyyet-com/
======
fro0116
I had a pretty positive view of Matrix until I came across this post and the
follow up responses from the developer behind an unofficial Matrix server
implementation:
[https://news.ycombinator.com/item?id=19365968](https://news.ycombinator.com/item?id=19365968)

I'd say tread carefully given their apparent hostility towards competing
server implementations, which is literally the only thing that makes the
protocol meaningfully "federated" to begin with.

This part in particular was deeply disturbing:

> I can quote the CEO of new vector in an argument we had about the
> insecurities of the protocol and what needs to be done to fix them where he
> said "good luck talking to your own federation." That reveals a lot.

Not exactly the kind of attitude I'd like to see from the stewards of an
"open" protocol.

~~~
Arathorn
I'm the project lead for Matrix (and CEO of New Vector, the company which
hires most of the core Matrix team) and can try to clarify this.

1\. We don't have any hostility to alternative server implementations; it
would be utterly idiotic to sabotage the project by doing so. Instead, we
promote them, even when they're written by people who for whatever reason have
issues with the project. For instance, if you look at
[https://matrix.org/blog/category/general/this-week-in-
matrix...](https://matrix.org/blog/category/general/this-week-in-matrix/) you
can see us publishing almost weekly updates on Construct (the server written
by the guy who is levelling the accusations here). Meanwhile, Construct
appears to work well enough to talk to the rest of Matrix in practice.

2\. Yup, there have been some security issues pre-1.0 in Matrix around
federation, particularly around state resets (thinkos in the state merge
resolution algorithm), event ID collision, incorrectly trusting potentially
malicious DAG depth parameters, and issues around the perspectives logic. As
far as we're aware, these have all been fixed now, or will be once everyone
has migrated from perspectives to real TLS, as per the original article -
hence us making a big noise about it with AreWeReadyYet.com. Most of the gory
details are at: [https://github.com/matrix-org/matrix-
doc/issues/1442](https://github.com/matrix-org/matrix-doc/issues/1442),
[https://github.com/matrix-org/matrix-
doc/pull/1659](https://github.com/matrix-org/matrix-doc/pull/1659),
[https://github.com/matrix-org/matrix-
doc/issues/1229](https://github.com/matrix-org/matrix-doc/issues/1229) and
[https://github.com/matrix-org/matrix-
doc/pull/1711](https://github.com/matrix-org/matrix-doc/pull/1711)
respectively. You can also see me talking through these issues one by one on
the main stage at FOSDEM, starting around
[https://youtu.be/C2eE7rCUKlE?t=2035](https://youtu.be/C2eE7rCUKlE?t=2035).

3\. I can't remember the precise context where I said "good luck talking to
your own federation", but I suspect it was the result of a disagreement over
how federation should be designed - probably over whether DAG depth parameters
should be calculated locally or proposed remotely and then validated. We chose
one solution, there was a lengthy disagreement, my eventual response on giving
up on the argument was "okay, if you want to do it the other way, good luck
with that" or words to that effect.

For context, the guy levelling the accusations here is also responsible for
maliciously exploiting the security issues on discovering them (e.g.
[https://matrix.org/blog/2018/06/14/security-update-
synapse-0...](https://matrix.org/blog/2018/06/14/security-update-
synapse-0-31-2/)). He is also banned from our github and the core-team
chatrooms on Matrix after exhibiting pretty much every flavour of obnoxious
and destructive behaviour, culminating with ad hominems against me and most of
the individuals on the core team, illustrating his points with hardcore porn,
and asking how we're going to compensate him for not launching further
exploits. He's also filled up the network with sockpuppet accounts to spam his
project (despite us, for better or worse, already promoting it on the weekly
blog), and I'd assume he's also seeding sockpuppets on HN too.

So, TL;DR: whilst it's true that pre-1.0 we had some security issues around
federation, we believe they are now fixed (or will be, once we've upgraded all
the rooms to 1.0). Meanwhile, be aware that the complaints are coming from a
deeply disingenuous and malicious source.

~~~
speedplane
Matrix is a fantastic project. As the technology matures and becomes more
useful, I hope there will be a large push to formalize the organization and
bring in other stakeholders. As I'm sure you know, Matrix will not be able to
get off the ground by itself, it'll need institutional buy-in from
corporations and existing tech companies. Hope there is a plan for that type
of out-reach.

~~~
zinid
> it'll need institutional buy-in from corporations and existing tech
> companies. Hope there is a plan for that type of out-reach.

"Failing to plan is planning to fail".

I don't see why would corporations and existing tech companies be interested
in yet another IM protocol they cannot control, especially in the era of total
silos and FAANGs. Doesn't sound like a solid plan to me at all.

~~~
fro0116
I can absolutely imagine why existing tech companies would be interested if
the protocol became so popular that they'd be stupid to ignore it and start
from scratch with their own protocol, like XMPP was at one point.

I'd be more interested in seeing how they plan on preventing the whole
Embrace, Extend, Extinguish thing pretty much every company pulled with their
initially XMPP based chat apps that gained market share, turning them into
back into closed silos.

~~~
Arathorn
Preventing the embrace, extend, extinguish manoeuvre that WhatsApp, Facebook
Messenger, Google Talk, even Apple Push Notifications did with XMPP is indeed
a tough one.

The best solutions we have right now are:

* Ensure there's enough value in the wider network (e.g. available services, integrations, bridges, public chatrooms) that you'd be taking a massive step backwards not to federate.

* Try to build the protocol to be capable enough that vendors don't feel that they have to fork and close it in order to make it do what they want.

I think it's mainly the first one that will make the difference. If there
hadn't been such great content out there on the public internet, we might
still be on AOL & Compuserve today.

~~~
ge0rg
The second point will only address the vendors that are actually interested in
federation, not the ones that want to close down their silo. XMPP fifteen
years ago is a prime example.

Regarding the first point, I'm not sure it will be ever possible to pull this
off. The proprietary IM silos are many orders of magnitude larger than IRC,
XMPP and Matrix taken together. You are doing a good job with promoting Matrix
to nerds, and there will be _some_ value in being able to directly contact the
French government (provided that they will allow federation from the public
network, which I have a hard time imagining).

I think the only viable route today is to push for legislation (e.g. in the
EU, in the context of ePrivacy / GDPR) that will force silo providers to open
up their silos and to offer interop by means of standardized protocols. But
even in this improbable case they will probably rather create their own
rubber-stamped standards (remember Office Open XML) than follow what is
already out there.

------
tannhaeuser
I'm not very much into chat apps and protocols, but isn't it possible to just
revive XMPP? Ten years ago we used Adium and Pidgin, and federated chat seemed
like a solved problem. I understand XMPP with its extensions and use of XML
fragments might be complex, but it sounds like matrix or another new protocol
isn't easier. In a way, those willing to invest time into F/OSS chat apps have
done the best they could with XMPP, and creating a new community around a
protocol for no good reasons seems like a wasteful thing to do. XMPP folks
shouldn't stop using it just because of Google's kiss of death.

~~~
pedroaraujo
Why are people so attached to XMPP?

There was no entity preventing XMPP from thriving, if the community really
wanted XMPP, we would have had XMPP everywhere.

But honestly, as someone who ran and tried to use XMPP for many years, the
entire protocol was an unmaintained divided mess. And the XEPs didn't help,
they felt like hacky workarounds to keep an old protocol up-to-date with the
modern needs.

Matrix feels very consistent, specially in the client side. I have all the
modern features one could have wanted (E2E encryption, video and audio calls,
file sharing, proper synchronization across multiple devices, etc) working
out-of-the-box across all my devices. This was almost impossible to achieve
with the XMPP clients existent nowadays.

~~~
superfist
I have very same impression. XMPP is basing on XML where parsing is order of
magniture more complex than JSON. In lot of ways very similar to SOAP mess
where you could not comunicate across different software because each of them
supportet different set of SOAP extensions and good luck with communicating
with web client.

~~~
oaiey
XML is not popular because of JavaScript developers.

Coming from .NET, I do not care using JSON or XML, because the APIs
System.Xml.Linq, Newtonsoft.Json and the upcoming System.Text.Json are a joy
to use. I think the lack of good native representation of XML in JavaScript
made it a unwanted choice.

Regards SOAP I tend to agree to you. Beyond the Basic profile it was a hassle
to interop.

~~~
tannhaeuser
XML is extremely popular with the JS crowd, they just don't know they're using
it ;) JSX (React's template language extension to JavaScript) stands for
"JavaScript XML" [1], and there was E4X as an official ECMA spec for XML
literals before that (though admittedly not as cool as React is, doesn't have
vdom and update events, components for MVC, etc). And JavaScript was indeed
_invented_ for DOM manipulation, it's just that the DOM API simply sucks.

The whole XML hate thing is symptomatical for the staged this-vs-that
discussion we endure in today's forums.

I guess there are those document representation schemes that everybody hates
on, and those that nobody uses ;)

[1]:
[https://en.wikipedia.org/wiki/React_(JavaScript_library)#JSX](https://en.wikipedia.org/wiki/React_\(JavaScript_library\)#JSX)

~~~
Boulth
E4X was far more powerful than JSX. JSX is just a nice syntax for object
construction. E4X could additionally query XML (think XPath but different) not
to mention support for XML namespaces, etc.

I agree with the rest though.

------
est
I sincerely hope someone took the Telegram client code and add Matrix protocol
to it.

Really, Telegram client is open source and the app is more usable than any
other bloatware on the market.

~~~
cloogshicer
Agreed, the Telegram desktop client is super fast.

EDIT: Someone seems to already have done this:

[https://matrix.org/docs/projects/client/nheko.html](https://matrix.org/docs/projects/client/nheko.html)

~~~
Arathorn
I think nheko is a clone of the telegram UI rather a fork of it.

I agree it'd be awesome if someone took the actual Telegram FOSS clients and
ripped out the TG backend and replaced it with Matrix (a bit like the
Delta.chat folks did, but replacing with email)

~~~
est
No need to replace it, just add dual protocol support :D

------
xingped
I hear about Matrix a lot, but I have no idea why I should use it. Can anyone
explain why I should use Matrix?

~~~
thinkloop
\- no vendor lock-in

\- decentralized

\- encrypted/private/secure

\- open-source

It's like irc or email for private decentralized encrypted chat.

~~~
dboreham
Matrix isn't really decentralized. It's federated.

~~~
zaarn
Federation is a form of decentralization.

~~~
amiraliakbari
No, decentralization is invented alongside the blockchain and nothing without
a blockchain is decentralized. :)

~~~
stagas
No, you don't need a blockchain for decentralization. Also, you don't need a
blockchain[0].

[0]: [https://thomaslarock.com/2018/11/no-you-dont-need-a-
blockcha...](https://thomaslarock.com/2018/11/no-you-dont-need-a-blockchain/)

~~~
viraptor
I believe you missed a joke.

~~~
stagas
Gosh, I did miss it actually, my bad. Mild autism, I suppose, I often take
words literally, esp. when there are no facial/voice tone cues.

------
Animats
The home page gives no clue as to what "Matrix" is. It seems to be yet another
"federation" system. Is this worth any attention?

~~~
speedplane
> It seems to be yet another "federation" system. Is this worth any attention?

In the current internet environment of walled gardens and a siloed and
decimated internet, any federation system is worthy of attention.

~~~
pbhjpbhj
Given Facebook, Microsoft, and Google have shown they're against federated
messaging the more pertinent question for me is "can it work?

Will anyone other than geeks switch from Facebook, et al..

You'd probably need some legislation to force those running large
communication platforms to open their protocols and allow federation before
there can be significant progress. I really can't see their being political
will for that at present.

~~~
speedplane
> Given Facebook, Microsoft, and Google have shown they're against federated
> messaging the more pertinent question for me is "can it work?

You're probably right, the legacy companies won't buy-in without a fight, but
I see two avenues of success.

\- New companies: If a federated messaging system existed five years ago,
Slack may have chosen to run on an open standard rather than build its own.

\- Large corporates: they may want the self-hosting, security customizeation,
and lack of vendor lock-in of an open standard. For example, I know that
Goldman Sachs has built their own in-house messaging service (crazy, I know).
They may be a good candidate to switch to an open standard.

~~~
pbhjpbhj
The lack of ability for their chat to interface with others is probably a
considerable measure of control over information flow, which I imagine is good
for Goldman Sachs.

~~~
speedplane
> The lack of ability for their chat to interface with others is probably a
> considerable measure of control over information flow, which I imagine is
> good for Goldman Sachs.

A federated system can still be locked down, and made to be inoperable with
other services. If you wanted to make an email service that didn't speak to
other email services, you would still probably start with the email standard
and make changes to lock it down rather than creating a new email service from
scratch.

Likewise, a Goldman Sachs (or similar company) that wanted a locked down
messaging service would likely consider an open platform that they could
modify and lock down rather than using a commercial one (like slack) or
rolling their own (which is extremely expensive).

------
MR4D
No.

But I mean that in a nice way. Here's why...

My understanding (limited, to be fair), is that a large percentage (most?)
users have a matrix.org account instead of an account somewhere else. By
definition, this is not federation. Certainly riot.im users get that by
default.

Let's look at a different example - email. What if the inventors of email
created email.org and created accounts on it. Everyone would also ask "where's
the federation?". What ultimately made email really useful (note the use of
the word "really"), was the ability to reach people outside your organization.
So you could email back and forth to stanford.edu, ibm.com, usna.mil, and even
aol.com.

What is difficult (today), is for me to go to google or yahoo, or microsoft,
or stanford and get an account. Yes, there is this [0] but only one provider
is on the page. Further, according to that provider [1] it's only a sub-
domain, not _my_ domain. It's a start, but also a version behind from the
looks of things, so therefore not truly ready.

If any of this is wrong, and I can sign up with a reliable hosting to have
server.mydomain.com, I'd sign up. I don't have the time to manage updates &
server security, and a reliable provider would allow me to run my own
instance.

[0] -
[https://matrix.org/docs/projects/hosting](https://matrix.org/docs/projects/hosting)
[1] - [https://www.modular.im/](https://www.modular.im/)

~~~
Arathorn
modular does support custom dns (at no extra charge) - eg webchat.kde.org is
hosted on it.

there are a bunch of public servers you can sign up on rather than matrix.org
- see [https://www.hello-matrix.net/public_servers.php](https://www.hello-
matrix.net/public_servers.php).

our hope is to turn off matrix.org sooner or later (or at least disable
signups) to prevent these misconceptions.

~~~
MR4D
Thank you!

As a side-note, someone should make that link a bit more visible on the
matrix.org site.

------
jMyles
When is the kickass Riot UI remaster that y'all showed off at Web3 coming to
town?

~~~
neiljohnson
The future is now [https://medium.com/@RiotChat/the-
big-1-0-68fa7c6050be](https://medium.com/@RiotChat/the-big-1-0-68fa7c6050be)

~~~
nicklaf
I don't want to knock the hard work the Riot developers have put into their
application, but I just don't understand: why does 'modern' web design seem to
require wasting so much white space? Looking at the screenshot on that blog
post, the actual chat transcript is somewhere in the middle of the screen
(sandwiched between giant sidebars on either side).

Compare to irssi (or any other console IRC program), which uses just about the
entire width of the terminal to print chat messages.

Is this really just a side-effect of developers all having large, high-DPI
monitors, making the white space look smaller to them? Because on my tiny
little Chromebook, no more than 50% of the screen width is actually used to
display chat messages.

~~~
Gigablah
Why would you want messages to span the entire screen?

[https://ux.stackexchange.com/questions/108801/what-is-the-
be...](https://ux.stackexchange.com/questions/108801/what-is-the-best-number-
of-paragraph-width-for-readability)

~~~
nicklaf
Because: window managers!

[http://i.imgur.com/4K0pa6m.jpg](http://i.imgur.com/4K0pa6m.jpg)

That said...I must confess that irssi uses a non-trivial amount of margin
space as well!

~~~
johntash
I think some developers either only have one window open at a time, or always
use fullscreen/maximized windows. There are so many things that are just
difficult to use when windows are tiled to fit ~4 things on one monitor.

------
davefp
I think Matrix is brilliant. I run a synapse home server and
updating/maintaining it has been a breeze.

That said, on a couple of occasions (once a while ago, and once with Riot 1.0)
I've tried migrating from my free Slack org to Matrix and it still falls short
for the feature set I want.

Specifically, I want a community whose members can create rooms for that
community that are automatically visible and private to the community.
Currently the community features in Riot make that a difficult task.

If anyone has had success doing this I'd be more than happy to hear about it!

------
DygFiul
OK, you want XMPP. But without the many XEPs, something with a monolithic
specification. And you like to use the latest trendy hipster stuff, like JSON
over HTTP instead of XML. Then you get:

Monolithic, Awefully Trendy Re-Implementation of XMPP (M.A.T.R.I.X.)

Which is also a dedication to XMPP, which has been invented in 1999, the year
of the Matrix film.

------
wholemoley
I made a seq2seq chatbot with Matrix/Riot, the python-api implementation
([https://github.com/matrix-org/matrix-python-sdk](https://github.com/matrix-
org/matrix-python-sdk)) and [https://github.com/tensorlayer/seq2seq-
chatbot](https://github.com/tensorlayer/seq2seq-chatbot):

Here it is:
[https://www.youtube.com/watch?v=rCggOcKZn-c](https://www.youtube.com/watch?v=rCggOcKZn-c)

(There's a fun interaction at 25:52)

~~~
Hendrikto
That triple nested if is horrible though…

------
aitchnyu
Off-topic, but Whatsapp provides E2E for groups upto 256. Matrix can
apparently provide E2E for bigger groups. Did they do scaling better?

~~~
Arathorn
yup. we layer megolm on top of olm (double ratchet) to scale to ~1000 or
further.

~~~
ajconway
Looks like every device still has to establish an olm channel with every other
device in the group. Does that scale?

~~~
Arathorn
you're right that that's the slow bit (typically about 50ms to set up each
channel, so across 1000 devices that's 5s to establish the initial mesh), but
the important thing is that having established the channels, they are only
used to sync key data for the megolm layer which sits on top. megolm keys
typically rotate every 100 messages or every day (whichever comes first), and
this uses the existing olm channels. In turn, the olm channels themselves only
resetup when conversation changes direction (or if they stall).

[https://blog.jabberhead.tk/2019/03/10/a-look-at-matrix-
orgs-...](https://blog.jabberhead.tk/2019/03/10/a-look-at-matrix-orgs-olm-
megolm-encryption-protocol/) is quite a good overview of this (from the XMPP
perspective!), as is
[https://www.uhoreg.ca/blog/20170910-2110](https://www.uhoreg.ca/blog/20170910-2110)
(from the Matrix perspective).

------
l0b0
I don't know about Matrix, but Riot, the default frontend, certainly isn't:
[https://github.com/vector-im/riot-web/issues/7062](https://github.com/vector-
im/riot-web/issues/7062) Copy/paste is a pretty fundamental feature.

~~~
bepvte
This only applies to text with embedded formatting, like bold and italic

~~~
l0b0
It doesn't have to have any explicit formatting, it just needs to be rich
text. If you try pasting _anything_ from a web browser or WYSIWYG editor it
will break.

------
0xb100db1ade
How does Matrix's encryption compare to Signal? I've heard they are supposed
to be very similar but I'm doubtful

~~~
Arathorn
[https://blog.jabberhead.tk/2019/03/10/a-look-at-matrix-
orgs-...](https://blog.jabberhead.tk/2019/03/10/a-look-at-matrix-orgs-olm-
megolm-encryption-protocol/) is quite a good comparison.

------
bovermyer
I'm tempted to spin up a Matrix homeserver.

Anyone know if it runs well on Docker via træfik?

~~~
neiljohnson
You might find this to be helpful [https://jonnev.se/matrix-homeserver-
synapse-v0-99-1-1-with-t...](https://jonnev.se/matrix-homeserver-
synapse-v0-99-1-1-with-traefik/)

~~~
bovermyer
Thanks for that!

------
superkuh
Lets Encrypt has been enabling bad behavior quite a bit lately. Here Matrix
says they will no longer accept federation from peers that self sign their
certs. Why? Because Lets Encrypt exists. That's the entire argument. They do
not address the problems of centralization this creates.

~~~
Arathorn
no, the argument is that Let's Encrypt is doing a better job at
trustworthiness than our previous attempt at using Perspectives to vouch for
self-signed certificates, and so at least self-signed folk can have a fairly
seamless upgrade to LE if they want.

However, if you want better trust, you can always use a CA you trust more than
Lets Encrypt (including a private one, if you're on a private federation, of
course).

~~~
krick
Could you please point me in the direction of someplace where this problem is
better explained? I'm struggling to understand, how the certificate choice of
the peer X should be a problem, given you send them only the information
directly related to the peer X, so it seems like you shouldn't care if the
traffic between you 2 is encrypted using X's key or MitM's key, because it's
only their part of the network that potentially gets compromised. If so, it
should be the choice of every given node, if they trust that part of the
network they are connecting to, and, conclusively, if they want to accept a
certificate they see for the first time, no matter if it's signed by any
common CA or not.

~~~
Arathorn
[https://github.com/matrix-
org/synapse/blob/master/docs/MSC17...](https://github.com/matrix-
org/synapse/blob/master/docs/MSC1711_certificates_FAQ.md#it-used-to-work-just-
fine-why-are-you-breaking-everything) is the best explanation. You can’t just
make it a per-node decision otherwise everything would splitbrain.

------
chrisMyzel
Can't Check my federation, only seeing the square next to the textfield
animating the sh*t out of itself :-)

