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.

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.

> 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?

> 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.

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.