Hacker News Reader

Comment by Arathorn | Hacker News Reader

This isn’t a case of NIH; France has adopted Matrix for the project, which is a lightweight fork of Riot.im combined with a large private federation of Matrix servers. The whole thing is open source (although not public yet, as it is very early days) and open standards based. At Matrix.org we’ve been providing some support to them :) It’s very exciting to see open government projects which actually grok open source and open standards.

View on HN

I'm so glad Matrix/Riot.im is getting some traction. This and https://blog.status.im/status-invests-5m-in-riot-im-4e3026a8... may be two important steps.

As I understand Matrix is not a fork of Riot, Riot is just a client for a Matrix synapse server (there are others like WeChat) provided by the devs.

I think he means the project is a lightweight fork of Riot.im, which is using the Matrix protocol.

wechat != weechat

Would you say it's a correct description of Matrix to call it "Jabber/XMP without the whole XML mess and over HTTP"?

Not really - the protocols are very different. Matrix is a way of replicating conversation history over a mesh of participating servers; a bit like a bunch of Git repositories constantly pushing commits (messages) to one another. XMPP is much lighter weight and builds on simpler message passing and pubsub primitives. You can use both to build comms systems, but they take opposite engineering and governance approaches on almost everything.

> a bit like a bunch of Git repositories constantly pushing commits (messages) to one another.

Why would you need to do that? Why not just give every message a timestamp, make sure they get sent, and sort the messages on the receiver side? If you're really concerned about message order, you could give every message a unique id, and send out the id of the previous message with every message, and improve your sort function accordingly.

Absolute timestamps cannot be trusted in a byzantine environment, so we do precisely as you suggest - messages are transmitted with pointers to the previous message(s) in the room message graph, so you get a partial ordering within the room (just like git). We also sign the messages into a merkle graph (like git) to stop the shared datastructure being tampered with.

Ok, makes sense now, thanks!

So it's a blockchain! /s

https://twitter.com/whitequark/status/946886702932557824 :D

So, Matrix is a better IRC, while XMPP is a better IM.

Matrix is a better NNTP, while XMPP is a better SMTP

Their architectures differ a lot and nowadays you can use XMPP with HTTP via BOSH. I think a fair comparison is the one in the Matrix FAQ:

https://matrix.org/docs/guides/faq.html#what-is-the-differen...

Disclaimer: I prefer XMPP.

For all the hate XML gets... it's not that bad. Certainly not worth switching protocols for. Main problems with XMPP is a divided ecosystem where different clients and servers support different features, and that multi-client encryption is severely flaky.

At least multi-client encryption exists for XMPP, unlike for WhatsApp.

See https://omemo.top/

Also, there is relatively minor subset of features that provide good messaging experience: https://conversations.im/compliance/

If you think XMPP is bad, take a look at Matrix’s "new HTTP connection for each sent or received batch of messages", thanks to HTTP longpolling.

> France has adopted Matrix for the project

Could you provide a source for this?

I'm the project lead for Matrix. Failing that, on the French side there's been some press where they've confirmed the system is built on Matrix & Riot (https://www.nextinpact.com/news/106463-la-france-travaille-a..., although it's behind a paywall), plus others have spotted the Github repository too.

Thanks!

I'm guessing he is the source.

Actually the source seem to be already available here: https://github.com/dinsic-pim

That's great; this other article I read about this kept mentioning Telegram and how Macron used that during his campaign, so this is much better than I expected :)

yes, the point of the project is to provide a secure and self hosted (yet interoperable for intra- and inter-government purposes) alternative to Telegram for state comms :)

What would appear in a lightweight fork of Riot though? Do you just remove a lot of the fluff to make it a bit more accessible for the public/general consumer?

you simplify the ux (eg autodiscovering the right homeserver); hook it up to directory services and/or SSO; simplify the e2e crypto UX; change the logo and branding, and have a basis to build on for whatever future custom features they need.

were doing exactly that at the place i work at, riot has too many settings and can be quite hard for a "normal" user (someone who is used to slack for example).

would love some kind of integration with openid connect though, since that would enable us to easier integrate with our AD. of course we could make that ourselves but we dont have the manpower right now.

Really? We are looking to use it for some of our work but are aware that the UI/UX esp around keys is a bit messy. Would be great to see how your simplifying it.

It has (or at least had, when I ran a server) support for CAS. JASIG CAS isn’t that difficult to set up against AD, I think Shibboleth has a plug-in that implements the protocol too.

This sounds great! I am looking forward to running it.

But I also need an admin panel to lookup user ip addys from the past 36 hours, ability to assign moderator user roles who can see other user's ips, ban ip addys, subnets, hostnames and cidrs easily.

Love to have some other needed admin options and run this! A stun / turn server to hide other user's ip addys and such as well, interception of images posted so they are scanned, exif stripped and hosted temporarily rather than giving the hoster everyone's ip info.

Stuff like that.

I guess blocking users from joining the huge main matrix channels through our server would cut down on the ram / processing needed..

I wonder if something like https://access.watch could hook into this, or if it needs something all in it's own language or what. Looking forward to this system growing.

I like (and use) Riot.im but as an electron app that uses ~300 MB of RAM (I just checked) it is definitely not lightweight.

I can't think of any way they could make it lightweight either. Maybe if they treated the JS as pseudocode and re-implemented as native clients.

The lightweightness here referred to the complexity of the fork - i.e. it's not an attempt to entirely rewrite Riot, but instead a reskinning and UX simplification exercise. The intention is to be able to keep merging in updates from Riot proper (and indeed to port stuff back into Riot).

Agreed that Riot itself uses way too much RAM though - but we have some massive improvements on the horizon there; by lazyloading user data on demand rather than preloading it up front, we can improve RAM usage by ~5x. This work is happening over the next month or two (modulo GDPR).

Meanwhile, you can always use a desktop client; Nheko, Fractal and Quaternion are all looking increasingly good :)

I would've liked better if they'd gone to extend XMPP clients to do audio/video, but this is ok as well.

jitsi does this.

Is Matrix planning to use MLS for interop with other E2E systems?

https://datatracker.ietf.org/wg/mls/about/

Good question.

We're participating on the periphery of the MLS discussions, mainly to try to encourage the MLS team to consider and support decentralised use cases.

At the moment there's a temptation to go for a simpler approach which assumes there's a centralised sequencing server which solves all the races you otherwise get (and which have plagued us in Matrix whilst implementing Megolm). However, assuming a centralised focal point for each group conversation kills the whole point of decentralisation, so we're trying to ensure it's not designed out.

See https://mailarchive.ietf.org/arch/msg/mls/MnLJkbJ_Mwe8Oz0Ll6... for the gory details.

Has Matrix considered developing a DMLS (D for decentralized use cases) specification for submission to IETF?

We may have to go down that path if MLS ends up being decentralisation unfriendly.

> This isn’t a case of NIH

Makes sense as the title says "due to surveillance risk".

Reply on news.ycombinator.com