u_tamtam @ u_tamtam @programming.dev

Posts

6

Comments

454

Joined

2 yr. ago

Is their shift key broken?

Could be the result of repetitive strain injury, I'm not judging

Furthermore, this blog post has outdated information and many of their problems with Matrix are fundamental for federated protocols. Good luck removing an email sent to another server, for example.

Yup, I don't think that's the main argument, more a warning like "well if you normal folks were expecting anything else, that's how it is and can't be changed"

JSON form is very well defined.

Though that's flawed/incomplete, and an essential reason for incompatibility between implementations

I can agree with the problem of DAG complexity building up, sure, but that is a tradeoff.

That's my main issue, really. Basically, there's no end in sight to the problem of inconsistent messages that can take minutes/hours/days to be delivered: Matrix just isn't dependable for instant communications, by design. This rules it out of a ton of very significant and practical real world use cases and expectations. That's not a system you can think typical modern users (used to their messages being either delivered instantly or not at all) to trust and to like once faced with these issues, not just once, but repeatedly. It is us, the world, being told again "Blockchain will solve all problems of centralization", with a crowd of enthusiasts blinded by the hype embarking (taking hostage) their less savvy peers while the people being the steering wheel have no idea how to bring the car home. And worse, those people behind the steering wheel being in denial (or malicious, or incompetent), will keep telling you to just trust them, and that the problem is solved already while the evidence points in the other direction.

Admitting problems and improving/replacing your protocol is good, you make it sound like a bad thing.

The only bad thing about this is that we've been at it for 10 years. If you've been following Matrix long enough, you've witnessed "the next big thing that will solve all problems" being promised every year. Matrix funding relies on hype, and I'm somewhat ok with that, so long as users and hosts are not taken hostage of empty promises. My first hand experience of Matrix X is that we are still far from what's being advertised.

edit: adding a missing word "thing"

The counter points on the site you posted are either completely expected or even desired properties of distributed systems

I agree that some are, and I think that the point being made in the article was that some of those properties might be surprising/deceiving for those who approach Matrix as another chat platform and not as a "distributed partially-replicated graph database".

What I consider "unfixable" is the fact that we are 10 years into this now, and that nothing has improved substantially: I sent a message yesterday which took 10 hours to deliver, and an enormous amount of resources at that. Matrix isn't ready for mass adoption, it is still not reliable, it broke on its promise to be the "protocols of all protocols" by failing to allocate the funds to maintain the bridge with the largest IRC network, and the developers don't see the overwhelming complexity of it all as a bug, but as a feature. To me, it looks like Matrix will remain a mediocre platform for the general public, aka. those who want something fast and that just work and don't care about "distributed partially-replicated graph database".

And XMPP, used by the German police and NATO

In the meantime the French dropped them

Yup, that's the annoying state of Matrix: nothing ever gets completed and running smoothly, because everything's in a constant state of flux

Or

What sides? There's only one side of the law to stay within as far as I'm concerned, so let them all corrupt politicians rot in jail no matter their alignment.

Since its inception, Matrix has always been "months away" from cracking this very problem, I won't hold my breath for this one, not after 10 years of kicking the same can down the road.

XMPP and IRC (to my knowledge, which very well may be outdated) are quite similar - you join a room from a client, you get a nickname, maybe a few lines of history, you chat, you close your client or lose connectivity, you don’t know anymore what’s happening there.

That's not true in the case of XMPP: upon reconnecting, any modern client will request from the server enough messages to recreate the missing history (of course it's up to you/the client to put a limit to that if you want).

I think even IRC(v3) is taking that route.

It’s not like XMPP doesn’t have issues.

True, but the problems you mention really are a thing of the past (I'd like to get your feedback after using latest versions of maintained clients), and message delivery across multiple devices and networks does, in my experience, work much more seamlessly and reliably than on Matrix (I mean, there must be a reason why google is using XMPP behind the hood to push every single notification on every single Android device on earth, right?).

And those are client/polish issues anyway, delivering messages at enormous scale has been a solved problem in XMPP for two decades, the protocol hasn't changed, essentially, but Matrix still hasn't found a solution to their self-inflicted problem: https://telegra.ph/why-not-matrix-08-07

Yep, I'm absolutely appreciative of the good work put together by the Matrix folks on the client side, element is overall okay (although slow, quirky, unstable, …) because of fighting a misguided and unstable server and protocol.

To answer your points:

• what is its equivalent on iOS?

https://siskin.im/

• No decent web-based client for XMPP.

I would argue that https://movim.eu/ is at least as good as element web. https://conversejs.org/ does the job to bridge across native clients.

• Setting up e2ee is a pain.

What is there to set up? The experience is very comparable to Signal and al. What did you find painful?

• Setting up MUC is a pain.

How so? It depends on the client, but on Conversations it's a matter of clicking on + → "Create private group chat" or "Create public channel". In gajim it's + → "Create group chat"

• To this day I did not manage to set up video chat on my XMPP server, or at least I never found someone on a different server that managed to connect with mine.

For calls to work, you need to use a stun/turn server (like everything everywhere else, including Matrix, Jitsi Meet, …). If you self-host, and you have a recent ejabberd, it's configured out of the box and you just have to open server ports.

Matrix may be technically complex, but at least it has managed to keep its ecosystem together.

Another way to put it, is that matrix is technically so complex that only a single party can afford to develop and maintain a working implementation. The documentation is lacking and alternative implementations are incompatible in effect. This isn't a sustainable situation (that those who define the standard are the ones implementing it) and we have started to see the cascading effects of that with the bitrot of the IRC bridge with libera.chat for instance.

I am yet to have an issue where I want to chat with someone on Matrix but couldn’t because their client/server was not compatible with mine.

it's funny because I've never experienced that in the XMPP world where the protocol is so stable that you can just S2S/C2S with decades-old servers seamlessly, whereas failing to update synapse for a matter of weeks guarantees compatibility issues. And I'm not even talking about 3rd party implementations like conduit for which incompatibilities is a guarantee.

I won't need to develop anything in response, because an open-standard (IETF) protocol for federated instant communications already existed long before Matrix, and as far as I can tell, from my experience of having administered XMPP and Matrix servers for hundred of users, nothing about Matrix, its design and its implementations makes it more desirable, more reliable, more resilient or more "future proof" than what XMPP came-up with a decade earlier.

And I am aware that I sound like an old man yelling at clouds, I take comfort in the fact that more and more technically-versed people who look behind the marketing and buzz get to see what I know from experience: https://telegra.ph/why-not-matrix-08-07

XMPP itself is the alternative, and the client you use shapes the user experience. If you want something that's comfortable for large chat rooms and dealing with a handful of them on desktop, gajim is hard to beat IMO, if you want something web, movim and conversejs are good alternatives :)

Covering up a bloated protocol by a faster language has its limits though, and in the case of Matrix, well, a faster language only buys you little

I will get shit for writing that, but Matrix in its current form shouldn't have seen the light of the day, nor should have been let to spread with close to no technical scrutiny and based on empty promises/hype like it did.

Just to be clear, I'm absolutely encouraging, in fact, actively promoting federated alternatives to things like WhatsApp, Messenger, Signal, Telegram, …
But I don't believe for a second that the foundations on which Matrix is built make sense, can be made to work well in practice, nor represent a problem worth spending so much time and effort solving. This article does a good job at introducing the "behind the scenes" of the protocol: https://telegra.ph/why-not-matrix-08-07

The whole history of Matrix can be summarized as:

• "let's do this because it's cool"
• "shit, it's hard/slow, but we will figure it out"
• "I have a breakthrough, here comes a new version of the protocol/client/…" (the ecosystem reboots)

(rinse and repeat)

Matrix has seen more incompatible reincarnations of itself in the last 5 years than XMPP in the last 20. Arathorn, its lead contributor and evangelist will keep apologizing, promising that this time they have their stuff in order, that whatever buzzword will solve this or that aspect of the problem, while the elephant still is in the room. You practically can't tell apart arathorn's messages of 2015 from those of 2022 and that would be funny if it wasn't so sad.

IMO Matrix is broken beyond repair, while XMPP is quietly used by millions of users. I wish Matrix could carry its own weight and be so unambiguously better that we wouldn't need competing alternatives there. To me, the better XMPP is XMPP itself, and I'd be happy to elaborate on that.

"Sliding sync" is Matrix's own admission that the protocol is too complex and taxing on clients to be practical, and shifts the burden further onto already overwhelmed servers for what's essentially bouncers marketed as new tech. And it's still a mess.

It depends, E2EE is mostly a client thing and most of them implement OMEMO as a standard: https://omemo.top/

OMEMO is XMPP's take on the double ratchet algorithm (very similar to Signal's), MLS is in the works as the hot new cross-protocols standard (but is inferior to OMEMO:2 when it comes to metadata encryption), PGP is often an option for the cases where perfect forward secrecy isn't desired, and OTR is still used in niche cases when you want E2EE across protocols.

In fact, E2EE was a thing in XMPP world since about 10 years… before Signal existed.

It appears to be P2P, so, just like federated protocols, they are good in my book compared to centralized silos.
But I have yet to find a P2P chat protocol that works well in practice on mobile (energy efficiency/battery usage is a real concern, and mitigating it in practice means losing the benefits of P2P without the advantages of federated).

It really took me a second to figure out: https://www.bundespolizei.de/Web/DE/Service/Mediathek/Jahresberichte/jahresbericht_2020_file.pdf , click on the PDF link, hop to page 48. But even without that, do you really believe that the developer of the app, who's making a living of it, would commit financial suicide by lying so openly about such a trivial thing? Either way, with or without Conversations, XMPP is used by millions of users daily: https://www.rst.software/blog/22-companies-using-xmpp-and-ejabberd-to-build-instant-messaging-services
https://xmpp.org/uses/instant-messaging/