Matrix Client Tutorial

138 pointsposted 2 days ago
by whereistimbo
(uhoreg.gitlab.io)

48 Comments

Arathorn

2 days ago

There was a comment here complaining that Matrix is a failure as an open protocol because encryption in Matrix is too complex and hard and PFS is overrated and "why can't we have a simple protocol for chat like Wireguard is for VPNs"... but it got deleted while i as writing my reply. I'll post the reply anyway:

Matrix without encryption is as simple as it gets - e.g. here was a younger, happier me writing a working client in 8 lines of bash: https://news.ycombinator.com/item?id=20948530

With encryption, inevitably things get way more complicated - especially in a decentralised network which needs to be byzantine fault tolerant. As you say, we've successfully simplified this by providing best-in-class implementations like matrix-rust-sdk-crypto - which i'd argue is the equivalent to Wireguard (which under the hood is a bunch of gnarly crypto, even if the API it exposes it simple).

In the end, encrypting messaging is just way harder than a VPN. The encryption hooks need to know the membership of the room (as users), the membership of the room (as devices), verify identities of all devices and their users to prevent MITM, verify that only the right devices can be added to the room, handle accessing history for new logins and new joiners, handle backing up history if you log out of all devices, handle receiving msgs if you log out of all devices, handle encrypted push notifs and allow multiple processes (push, share extension, etc) to share the same crypto state, scale to thousands of devices, etc etc.

Meanwhile if you simplify that by removing PFS - sure, some of it gets better ("the room history gets encrypted by a static password!") but then breaching that secret from any client at any point trivially leaks the whole history of the room.

In terms of "Matrix as an open protocol isn't very successful", i suggest taking a look at https://2024.matrix.org/watch/ for the zeitgeist from a few weeks ago. It's working for some folks at least.

INTPenis

2 days ago

The thing is, while we were all waiting for Matrix clients to handle Encryption several other encrypted messengers came out and seem to handle it just fine.

For example I've been using SimpleX in a group chat for a year now and had no issues at all.

Arathorn

2 days ago

I'd argue that SimpleX has probably learned from the path Matrix has been on... and so has Matrix. So you end up with multiple viable options to pick from, and to drive each other forwards; sounds like a good outcome to me.

whereistimbo

a day ago

I'm hopeful for Matrix future success as I'm rooting for Matrix! Props for you for growing Matrix into this big!

Also, this blog post is still I'm hoping for to be realized sometimes soon: Breaking the 100bps barrier with Matrix, meshsim and coap-proxy (2019): https://matrix.org/blog/2019/03/12/breaking-the-100-bps-barr...

Arathorn

a day ago

me too. but like all the more scifi Matrix projects, the core team does not have the funds to work on it, so it's stuck in favour of foundational work. Others are welcome to pick it up and contribute it, or apply funding to the core team to let us work on it again: https://matrix.org/blog/2024/01/2024-roadmap-and-fundraiser/

whereistimbo

a day ago

You call it scifi? It's already realized lol! What talented guys you are!

RadiozRadioz

a day ago

> a younger, happier me

I hope you're okay.

I have notifications set up for anything Matrix/ XMPP on HN, and I very often see you in the comments. Some of the threads on here are really harsh and unnecessarily snarky, I don't know how you do it. You're doing great.

ThePhysicist

2 days ago

I deleted it as I was anticipating exactly such replies that just tell me all the ways in which I'm wrong and just make me feel dumb for voicing an opinion, and I realize I don't enjoy these kind of discussions anymore. It was up for like 3 minutes before I realized my mistake, sorry about deleting it I guess.

abnercoimbre

a day ago

Don't take it too personally, they seem to be speaking from some automatic playbook.

I run indie conferences for a living [0]. From 2020 - 2023 we gave Matrix a serious shot: enough to risk losing audience members who found the UX unbearable. Then a third of my ticket holders threatened to leave if we kept using it. I was forced to drop it [1].

This year, I’m self-hosting Revolt, a lightweight Discord clone. Unlike Matrix my community's actually loving it. If Matrix leadership is reading this, take heed.

[0] https://handmadecities.com

[1] https://handmadecities.com/news/new-discord-server/

Arathorn

a day ago

I'm not speaking from a playbook. Sorry that Element worked out so badly for you. Other conferences like FOSDEM seem to be pretty happy with it. If you don't need encryption, decentralisation, or an open standard, then Revolt looks like a reasonable FOSS Discord clone.

abnercoimbre

a day ago

Glad you're not using any playbook. The commenter above us represents a growing sentiment worth considering. In my opinion, placating every negative feedback might backfire.

Arathorn

a day ago

I'm trying to agree with the negative points (e.g. I fully agree that Element UX has historically been below par, hence all the work around Element X; elsewhere in the thread you can also see me agreeing about current & historical problems).

I'm not trying to dismiss them, but just explain that a) we did listen, b) we are listening, c) we're trying to fix it. Fwiw https://youtu.be/gHyHO3xPfQU?t=497 showcases what we've been doing. Perhaps I should leave all the "Matrix sucks" feedback unchallenged, but i'm trying to stand up for the work we've been doing to fix it.

Arathorn

2 days ago

i suggest reading the comments here and try to figure out what direction the steamroller is rolling...

alwayslikethis

2 days ago

The lack of good clients is really holding Matrix back. Element is rather bloated, and most of the other clients are missing significant amounts of features.

ericjmorey

2 days ago

I'd say that the protocol itself is what's doing Matrix in.

Arathorn

2 days ago

What are you thinking of in particular? Fwiw, as project lead, i would be first to admit that there were slow bits - eg sync v2, which is why we built sliding sync… and crypto was easy to get wrong, hence shipping a highly polished implementation in matrix-rust-sdk. But what do you have in mind? Otherwise this doesn’t sound very wellfounded…

lifty

2 days ago

It's been a bumpy road but I think now Matrix has gotten to a good place. What's still missing is for the ecosystem to catch up a bit, both on the home server side and on the client side, and implement some of the new usability improvements brought by sliding sync and the rust sdk. Looking forward to see it happen!

isaacaggrey

2 days ago

Could you elaborate?

dzaima

2 days ago

There are some hilariously ugly things for even trivial things like editing/replies:

Edits get a `"m.relates_to": {"event_id": ..., "rel_type": "m.replace"}` field in the body, and `"m.new_content": {...}`, containing the plain-text and HTML versions of the message (while also keeping a copy of both, typically with a prepended "*", outside "m.new_content", for backwards compatibility; yes, that's 4 (four) copies of the message text in an edit; for some while Element generated up to 10 (ten) copies IIRC, due to some proposed extension(s), but that seems to be gone thankfully).

Reply messages get `"m.relates_to": {"m.in_reply_to": {"event_id": ...}}` - an annoyingly different format from the edits. It might look like that that allows an edit to change which message is being replied to, but nope, last I checked, that's not supported. Oh and for backwards compatibility a <mx-reply> HTML element is to be prepended, containing a copy of the replied-to message and its info (and yes, that means that the replied-to message effectively can't be deleted as the reply will still contain its text; luckily clients can choose to do not generate such <mx-reply>, but Element still does). And if you want to actually get proper reliable info about the replied-to event, you have to just make an API request for every single one you want to display (unless you happen to already have a cached copy, which luckily for replies is reasonably common).

And then there's threads - again in the name of crappy backwards-compatibility there's a mess - within-thread replies imitate a reply to the last in-thread message, along with `"m.relates_to": {"event_id": ..., "rel_type": "m.thread", "is_falling_back": true, ...}`, that "is_falling_back" indicating that this isn't actually a reply (being false when you want an actual reply). And clients are "supposed" to also handle replies to in-thread messages without the "m.thread" relation (which'd come from clients not supporting threads), but as far as I can tell there's no way do to it while paginating without making an API request per every single message (and yes Element behaves quite buggily here).

And then there are some things that can't be reasonably handled - the context/message listing/pagination APIs don't give any reaction info (besides the reaction events themselves in chronological position of their addition), so reaction presence/counts in history view must be calculated by clients, and thus won't be able to show ones that were posted a while after the messages. (there used to be some aggregation provided, but it's since been removed!!!) I think the only way to do this properly is truly just making an API request of "list reactions" for every single message the client wants to show.

This may make it seem like Matrix has an extremely firm stance on backwards-compatibility, but nope - recently they deprecated & made non-functional the unauthenticated API retrieval of media, making it impossible for clients not supporting video/audio/image display to just open those in the browser, instead forcing them to have custom file downloading & saving code, and also making it impossible to link to media within a message. There was a window of 6 (or less?) months between the new API being finalized, and the old one being removed.

jeltz

a day ago

While you have a point with the ugliness of threads and replies I do not like your example with the authenticated media. The reason for the very short deprecation cycle was that it was deemed to be almost a security fix. The Matrix team did not like how their and other's servers were used as CDNs.

dzaima

a day ago

Right; it's not unreasonable to want to quickly transfer away from it, but it's still a rather short deprecation cycle compared to everything else I've had to touch never being deprecated; it's not an "example", it's a real thing that actually affects my usage of Matrix (due to being now unable to post images inline in a message (granted, including fixed-URL links wasn't the prettiest thing, but it did work), and having to fully download videos before viewing them from my client that doesn't include video playback, whereas before I could immediately open it in a browser and view it while it's streamed in). Granted, then again, it's the only such occurrence, and probably there's nothing else that could match it in the future.

However many years ago I started work on my matrix client I was rather surprised it ever allowed direct links to media in the first place, but then again Discord had done the same mistake. But at least Discord's solution is more sensible, providing temporary links.

ptman

2 days ago

Many of these problems stem from the fact that matrix is federated. And it's a protocol, not really even for messaging but for a federated graph database. In federation some messages may be missing and arrive out-of-order. And different clients have different capabilities. There's a really simple example client implemented in a couple of lines of bash.

dzaima

2 days ago

No, most of those are just plain and simple bad outcomes due to not having thought out extremely basic things ahead-of-time. And even if there are problems with actually no simple fix, that in no way means the problem ceases to be a problem.

Replies to threads from thread-unsupporting clients are the one potentially-hard thing federation-wise, as doing it properly would require the server to trace back the reply and from that handling it as in the thread, but that's not far from what servers already have to do with edits. Or you could also just not require/suggest that behavior, having replies without thread metadata always be outside of threads; would probably save on confusion too, as the illusion would break anyway when someone on a client without thread support would not do a reply on some message after having used replies on others.

There might be some graph core to it, but it's still primarily a messaging service. Opening the client spec will show you tons of messaging-specific APIs.

I utterly disagree that saving a half-dozen lines in largely-useless toy clients is worth making more feature-complete clients more complex, and doubling the size of every edit event.

self_awareness

a day ago

> In federation some messages may be missing and arrive out-of-order.

Doesn't "some messages are missing" trait defeat the point of a reliable communication protocol?

ptman

a day ago

Missing at any given moment. There's eventual consistency. But sometimes connectivity isn't 100%

ranger_danger

2 days ago

https://0x0.st/H8h-.png

Groxx

2 days ago

All that really shows is "the project has an active community". Have you seen how many XMPP has? Or Python[1]? This is just normal open development metadata.

[1]: https://peps.python.org/pep-0000/#

jeroenhd

2 days ago

> Have you seen how many XMPP has? Or Python[1]?

Python has had 664 PEPs in 23 years (29 per year). XMPP has received 495 XEPs in 23 years (22½ per year).

Matrix has received about 650 in 8 years (>81 per year). Four times the change rate is quite annoying when writing code against the spec. Plus, most XMPP clients only support a fraction of the full spec, so by that comparison the impact of the rate of change is even worse. Furthermore, most XEPs and PEPs are mere (optional) extensions, whereas a lot of MSCs are alterations of existing APIs. Any JSON parser used for Matrix needs to anticipate fields changing or being added all over the place because you never know when random fields show up all over the input data because of a spec change.

The way the Matrix spec is developed feels a lot more like a proprietary company spec that happens to be published on Github than the IETF/XMPP/Python spec process. The rate of change is high and almost all changes are done to serve new features for the two or three major players that bought into the Matrix ecosystem.

One recent change that comes to mind is the move from secret, public URLs for media, to authenticated URLs. The setting to force that changeover won't apply everywhere for a while, but it'll completely break every media-supporting client written before the spec change.

Nothing wrong with extending the spec to improve the product, but with how fast the protocol is growing, I wouldn't want to be tasked with maintaining a Matrix client and I don't have much faith in the forward compatibility of the few Matrix bots I've written either.

Arathorn

a day ago

Aaaargh, this comment is a nightmare.

It is a GOOD THING for people to open MSCs and try to evolve Matrix, and the number of open proposals shows the enthusiasm in the ecosystem for doing so and proposing ways to evolve the protocol.

Meanwhile, the number of actually accepted merged MSCs is way lower - 226 merged in 8 years: https://github.com/matrix-org/matrix-spec-proposals/issues?q... - so 28 per year. Same as Python.

> I wouldn't want to be tasked with maintaining a Matrix client and I don't have much faith in the forward compatibility of the few Matrix bots I've written either.

Authenticated media is literally the first time we've made a significant breaking change on the CS API in 10 years - and was effectively a security fix, to stop people abusing Matrix as a CDN. Bots I wrote 10 years ago still work today without changes (other than auth media).

> The way the Matrix spec is developed feels a lot more like a proprietary company spec that happens to be published on Github than the IETF/XMPP/Python spec process.

Seriously, read the proposal mechanism (https://spec.matrix.org/proposals/) and look at a MSC like https://github.com/matrix-org/matrix-spec-proposals/pull/177... with >500 comments from across the wider community (so big that it crashed GitHub at the time).

alwayslikethis

2 days ago

In order to support bridges to so many different proprietary platforms Matrix needs to have a superset of their features, so the feature creep is probably intentional. It does make it harder for clients to keep up though.

cmeacham98

2 days ago

Matrix is the opposite of feature creep - there are several features entirely missing from major clients that users of modern chat apps expect to have.

(Examples include: custom emoji, functional search of encrypted chats, pinned messages or some sort of MOTD, forwarding messages, etc)

ptman

2 days ago

The matrix developers are experienced IM developers. They've built systems on XMPP and custom protocols before. Their estimate was that because of matrix being federated, every feature was 5-10x harder to implement than in centralized systems.

Arathorn

2 days ago

As a protocol, Matrix has all of these features (custom emoji is a proposal, but many clients implement it).

As a client, Element has all of these (encrypted search only on Desktop for now) other than custom emoji.

itsthejb

2 days ago

Very very true. I self host synapse, and generally speaking the ability to bridge my ~3 most used messengers into one app (ElementX) adds value. However, the lacking features and bizarre feature disjoints between Element (supposedly EOL) and ElementX (suppose next gen) are jarring

heroprotagonist

2 days ago

I _really_ wish that if Element has an update prompt for me almost every single time I open it, that it would just update during the startup sequence on its own.

Or at least have an option for it. Not a 'Oh you loaded, now click this button to load again please' prompt whenever I launch it.

paulcarroty

2 days ago

cinny/fluffychat/iamb are the greatest.

huxflux

2 days ago

I've been setting up servers for everything ranging from IRC to Teamspeak, Exchange, and you name it. But how come setting up a Matrix server is still a science in itself?

Yes, I'm aware of the Ansible script, but should that really be the only somewhat reasonable option? When Matrix wrote " Matrix 2.0 a new chance if you gave up on us in the past".

I listened, but without a somewhat reasonable setup process for the server and the ongoing confusion in terms of clients, it hasn't gotten any easier to onboard to Matrix, unfortunately.

NicolaiS

a day ago

Self-hosting Conduit as my homeserver using SQLite as by database and Caddy as reverse proxy.

That is: 2 binaries (conduit + caddy) + 5 lines of toml config for Conduit and 2 line of config for Caddy + 1 database file. That's all you need for a basic homeserver.

xinayder

a day ago

I have to agree with you. Not having a proper, understandable documentation is part of what drives people away from Matrix, IMO.

And shoving the ansible script into people's faces is not a solution. I never used Ansible, and I won't start using it just because it's "easier" to setup Matrix with it, instead of setting it up by myself.

All services I self-host are quite easy to setup, Matrix so far has been a bit more difficult, but not that hard.

solarkraft

2 days ago

Oh my, this looks nice and comprehensive!

I’ve been wanting to write a Matrix client for a while now, but found myself too caught up in getting even an existing library to work: The Rust SDK, the most maintained and batteries-included SDK, doesn’t have JS bindings and the JS SDK is insufficiently documented and generally seems a bit crusty.

In general I find there to be a bit of a lack of guides on implementing Matrix, which is probability a factor in there not being that many implementations.

user

2 days ago

[deleted]

amstan

2 days ago

I tried to do something similar. It's infuriating how the client must be stateful and have local storage, for both the access_token and even last message recieved. That's right you must remember as the client where the last events [1] you've seen (even if you already told the server to mark it as read) was or else the server will happily send you the same messages over and over again.

I kind of miss making IRC bots where things were much simpler and ... quicker honestly (latency wise).

[1] https://uhoreg.gitlab.io/matrix-tutorial/sync.html#:~:text=w...

dzaima

2 days ago

At least that means that you will never have messages get dropped due to network issues, or even restarts if you persist the token across such. (the API will jump forwards if there are too many unsynced messages, but at least it should then be providing a "limited: true" so that one can paginate in the omitted events if so desired (or not if undesired))

ranger_danger

2 days ago

Finally something besides the matrix foundation's "lol the auto-generated API docs are enough" nonsense. This really helps a whole lot better.

user

a day ago

[deleted]