https://matrix.org/blog/2023/09/matrix-2-0/
Matrix, the open protocol for secure decentralised communications
Highlights include Sliding Sync (instant login/launch/sync), Native OIDC (industry-standard authentication), Native Group VoIP (end-to-end encrypted large-scale voice & video conferencing) and Faster Joins (lazy-loading room state when your server joins a room).
I think it's supposed to become just normal element when it gets feature parity with current element
It is just a codename, Element X is going to be just Element once it replace the old one.
Matrix has had a bit of trouble penetrating the enterprise market, which is where the real money is. Hence the corporate-speak rename.
I mean, they haven't had that much trouble. Last I checked they had portions of the French and German governments using Matrix as a secure messenger. (To be fair, those both came after the rename.)
Their main competitor in the open-source, self-hosted space is Mattermost, which has a much more business-oriented solution, so there's that as well.
That seems more like a direct competitor to Slack and MS Team to me rather than general communication. Matrix is a facinating protocol that keeps pushing the limits of federated communication but it always sucked as replacment for those and unless someone invests huge amounts of money in a completely new client I don't see taht changing any time soon tbh.
Ah there is a solution for it https://github.com/matrix-org/sliding-sync I guess I could try to install it.
Yeah I was able to install sliding-sync on Dendrite without issues. A bit surprising that I didn't see any guides made for it yet.
Did you find docs? I did a cursory glance around late last week and ended up just shrugging assuming that's what I got for using Dendrite (positive)
Edit: Turns out, when running sliding-sync you really only need to patch the .well-known/matrix/client configuration
Their native group VoIP calling looks to have a solid topology that could easily replace Jitsi in the near term, and eventually compete with larger scale conferencing services like Zoom. That's kind of exciting for those of us who care about open systems and privacy.
I wish the whole project was a little bit more clever with its names. Matrix and Element are not unique enough names and can cause a lot of confusion.
I like the project though and still hope it continues to succeed.
Okay, help an old-timer out.
Lemmy :: Reddit
Mastodon :: Twitter (I refuse to call it "X")
Matrix :: ???
Is it like discord? The olden days of AIM/ICQ/IRC?
Does there tend to be logical groups for Matrix channels/servers? (Meaning you don't really just join Matrix, you go to a Matrix instance for Jerjoba support, or other common interest like Hockey?)
There do tend to be in logical groups, e.g. you'll see all of Mozilla's stuff in their server - but there are quite a few general purpose servers.
I'm not the best person to ask as I just chat on a few channels in a single server.
There definitely are software projects that run their real-time support through Matrix in the same way others do it through IRC or Discord.
At the same time most servers seem to have a General room (or similar) for off-topic chats.
Peruse the big list of public rooms here. That might give you a sense of it.
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.
I agree in theory, but in practice my experience with Matrix has been infinitely better than with XMPP:
Matrix may be technically complex, but at least it has managed to keep its ecosystem together. Whenever I've faced an issue with my server, all I needed to do was upgrade synapse. The "millions of users" in XMPP are mostly all on their own silos, while 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.
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?
- 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.
Not to dismiss the work of FOSS developers, but siskin seems quite primitive. It does provide the very basic functionality that you could expect from any messenger from about 10 years ago but that's about it.
For calls to work, you need to use a stun/turn server
I may try to take another look, but I did have a ejabberd server that was passing pretty much all the tests in the conversations suite, but I did not manage to make calls between pidgin and conversations.
Which is kind of my beef with frustration with XMPP. There was never a whole combination of client/servers that would work consistent.
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.
As long as this working implementation is working and it is open source with some community oversight, I don't mind having a clear leader in the project. The alternative is this eternal push-pull of forces that we had in XMPP, where we end up with a fragmented ecosystem which is never universally accessible.
whereas failing to update synapse for a matter of weeks guarantees compatibility issues.
Well, yeah... but since when it is a good idea to let a server unpatched/out-of-date in the public internet?
Not to dismiss the work of FOSS developers, but siskin seems quite primitive.
Fair, but it does that in ways that do not deceive its users, as in, what it does it does pretty well.
It does provide the very basic functionality that you could expect from any messenger from about 10 years ago but that's about it.
As far as I'm concerned, Instant messaging was a solved problem 20 years ago, we had practically more features in Yahoo and MSN Messengers (of which XMPP was a superset, for bridging and compatibility purposes), and Whatsapp, telegram and the rest have been removing the most distracting features. What are you missing for effective communication essentially?
I may try to take another look, but I did have a ejabberd server that was passing pretty much all the tests in the conversations suite
Are you talking about ? As far as I remember, it's pretty upfront about testing the capability but not the implementation (because testing for things like calls is very difficult and network dependent, you won't get the same behavior from being behind a NAT or a public IP, and the test passing is no guarantee that it will work in the wild. Even
is full of gotchas but is a good step to add to your testing).
Which is kind of my beef with frustration with XMPP. There was never a whole combination of client/servers that would work consistent.
There will never be a client nor a server that will implement all XEPs, because that's not desirable: some fringe/IoT/obsolete cases just have no meaning nor use for most users, though there are some compatibility levels, updated regularly, that all maintained clients and developers target (e g. https://xmpp.org/extensions/xep-0479.html ). Under those circumstances you have a pretty good user experience.
As long as this working implementation is working and it is open source with some community oversight, I don't mind having a clear leader in the project.
But how about the implementation not working so well in practice and with enormous trade-offs, and the leader being essentially a marketing agency running for funds while covering up those trade-offs or blatantly lying about them?
The alternative is this eternal push-pull of forces that we had in XMPP, where we end up with a fragmented ecosystem which is never universally accessible.
Beyond the facade of new vector's products, Matrix is as much fragmented if not more. Why would it be otherwise? Nothing is fundamentally better: there's a spec and people chasing it. Except that in the case of Matrix, the spec is just there for reference and eventually consistent with what's in the code of synapse running matrix.org, which is actually what matters (and might be quite different from what your server is doing for a bunch of good and bad reasons). I've bumped into more client to server and server to server incompatibilities hosting Matrix for few months than I did over years and years of operating XMPP. Things are just so much more stable and mature there (and slow, and boring, which users and admins alike tend to appreciate for something so central to their lives).
Instant messaging was a solved problem 20 years ago
AFAIK, none of that existed 20 years ago and all of that are features that expected of any basic messenger.
how about the implementation not working so well in practice and with enormous trade-offs, and the leader being essentially a marketing agency running for funds
GOTO 1. It's the best one that we have (in practice) and it's open source. If leadership ever becomes a real problem, it can be replaced.
- Emoji support
XMPP had that in 2002, before emojis was a thing outside japan :)
https://xmpp.org/extensions/xep-0038.html
- Reactions
2006: https://xmpp.org/extensions/xep-0201.html
- Share location in real-time
2003: https://xmpp.org/extensions/xep-0080.html
- Threads in conversation
2006 (see reactions)
- Media embeds
Which media? You had whiteboards in 2001 (https://xmpp.org/extensions/xep-0010.html), games in 2002 (https://xmpp.org/extensions/xep-0047.html), stocks in 2003 (https://xmpp.org/extensions/xep-0067.html), rich text (beyond markup) in 2003 (https://xmpp.org/extensions/xep-0071.html), mood (https://xmpp.org/extensions/xep-0107.html), activity (https://xmpp.org/extensions/xep-0108.html), maps (https://xmpp.org/extensions/xep-0110.html), tune (https://xmpp.org/extensions/xep-0118.html), co-browsing (https://xmpp.org/extensions/xep-0151.html), calls (https://xmpp.org/extensions/xep-0166.html), serverless (https://xmpp.org/extensions/xep-0174.html)
and all those were added to XMPP because they were in widespread use in the popular messengers of that era (for the history lesson, XMPP was built first and foremost to bridge and unite all messengers). So, yeah, the trend has been going towards simplification over the years, not the opposite, and there were many many things that you could do in MSN Messenger in 2005 that you won't be able to do in FB/WA/TG/Matrix/… :)
@u_tamtam @pezhore It's not like XMPP doesn't have issues. Finding a combination of clients and servers to get a coverage of the XEPs you want is quite an exercise. MUCs are painful, especially if you want to join from multiple clients. Cross-device trust between accounts for E2EE AFAIK still requires each device to trust all the other devices manually. Matrix has many more multimedia features.
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
XMPP - now that's a name I haven't heard in a long time. I thought the woke Google chat federation and subsequent drop pretty much killed it off - but I'm glad to be wrong.
Are there XMPP based group chat/Matrix/Discord alternatives?
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 :)
@pezhore @u_tamtam Your question may require a bit of specifying. Discord is a product and a platform. XMPP and Matrix are protocols. So, uh, it's a bit like asking whether there are any SMTP or IMAP alternatives to Google Groups? There are *many* servers and clients and supporting bots and libraries that do many things. What specific things are you interested in, to narrow it down somewhat?
Well, I'm slight embarrassed. I think that was part of my confusion about Matrix - it seemed to me that it was both a protocol and a platform. That colored my memory of XMPP too. IIRC, Jabber was the client and protocol before the protocol was renamed to XMPP.
As for what I'm interested in - I'm not sure. I don't really use discord save for a few Patreon follows; my friends use a group Signal chat. I think maybe I'm interested in recapturing the old IRC feeling of finding a chat room and just "hanging out"? I suppose I could always dig out my Irssi client config and just join Freenode again.
(Ye gods, wtf happened here to Freenode/Librachat?)
@pezhore The confusion is somewhat warranted, since matrix.org is the main/largest instance of Matrix the protocol, using Synapse the server, and having web access via Element the client.
For just text chat, anything will do. Matrix has the bonus of having a liberachat gateway, though it's had issues recently.
But, the experience is somewhat different. [1/n]
@pezhore 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. You want to join from another client, that's a separate session, with a different presence and name on the channel. Your clients don't share history etc. [2/n]
@pezhore With Matrix, depending a bit on channel settings, your account joins the room and gets either all history or starting from the point of joining. And your account is in the channel. Regardless of what clients you use, and how many of them you use, and whether they're online at the time or not, it's your server keeping track of what's going on in the channel, and keeping history of it, so you have one presence and same view regardless of type and count and connectivity of clients. [3/3]
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.
The counter points on the site you posted are either completely expected or even desired properties of distributed systems (like not being able to force a delete or room closure on another server), or just problems with specific implementation details or insufficient clarity in the specs (like interop hickups or handling of media files). As far as I can tell nothing on the list is an "unfixable" protocol bug or core design flaw.
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".
Kind of a mix between Discord and IRC. Although it doesn't have servers like Discord and is more of individuals rooms. In fact they made bridges an important feature, so an IRC room and Matrix room can be merged together without either side really noticing a difference. Same with Discord and a ton of other programs.
If you actually tried spaces, you'd realize they're incredibly clunky and not even close to discord rooms. You can't even search for them. They're not quite there yet, they leave a lot to be desired.
The organization does suck, I do agree with that. It still needs a lot of UX improvements too. Though you can turn off read indicators in the settings, and I feel like it is a lot faster then commenting on Lemmy. Lemmy being written in rust is actually causing a lot of issues. It's not a good language for web applications and it's really starting to show. It also hasn't prevented security issues either.
Synapse, the most up to date matrix server, is really slow and resource intensive for sure. But, it's currently in middle of being replaced with Dendrite. It doesn't support all the bleeding edge features, but Dendrite has caught up enough to be able to run servers just fine now. In fact Dendrite is light enough to be ran in the mobile Element client, or at least that's the plan in the near future while they work on p2p. You can read more about it here: https://matrix-org.github.io/dendrite/faq
You can check the beehaw writeup if they didn't defederate already. They've been having too many issues with Lemmy, and it's been a battle with the developers. On Element desktop you can disable sending read receipts, but not mobile which is stupid.
I think you and those responding to you are conflating Matrix and Element and Synapse.
Spaces are a UI feature in Element for grouping rooms. Element is only one of many Matrix clients.
Element, the client, is written in typescript and kotlin.
https://github.com/vector-im
Synapse, a server implementation using the Matrix protocol, is indeed written in Python.
There are several other servers, written in Go, Rust, C, and C++.
https://matrix.org/ecosystem/servers/
Matrix is the protocol itself. Blaming it for UI problems is like blaming TCP for the toolbars in Internet Explorer: very remotely correct.
You're not correct about spaces being a UI feature.
Spaces are now part of the protocol and are stored server side with your account data. Other clients - like fluffychat - can work with spaces just like Element.
They were element only back while they were being tested, but are now a direct replacement for the old - deprecated - groups functionality.
You had me second-guessing for a minute, but I think the other commenter is correct.
One can definitely use Spaces in other clients, even Beeper supports them. So if it was an Element-specific feature, it doesn't appear to be any longer.
Yeah, spaces need server side support too. Technically they are just rooms that are handled differently, but it's not just a UI feature.
Although it doesn't have servers like Discord
The other way around. Discord does not have servers
technically it's an eventually consistent federated database (or series of databases i guess? dunno), which just happens to primarily be used for instant messaging similar to discord but also inheriting features from IRC.
Been waiting for this for a long time! Another thing that's been on the horizon I'm eagerly waiting for is p2p. They've been working on Dendrite, which is a much more efficient Synapse, and the goal is to be efficiently running it to effectively running it on your own device as like an invisible self-host. They're working on MXIDs as well so @hostname.com wouldn't be a thing anymore. P2p with all this other tech would make Matrix really the privacy holy grail imo.
They're working on MXIDs as well so @hostname.com wouldn't be a thing anymore.
Are you sure about that? I think they'll still exist, but will be less meaningful, as a users identity will be backed by cryptography instead of their name with the HS name
afaik server domains would essentially just be aliases for a user's UUID, like how it works with rooms.
"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.
"Sliding sync" is Matrix's own admission that the protocol is too complex and taxing on clients to be practical
I know of no major messaging service where the client wants to download everything
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
I think most of the criticism on Telegraph regarding how Matrix handles rooms and events are addressed by the work behind linearized matrix: https://www.qwant.com/?l=en&q=linearized+matrix+messaging&t=web
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.
Is their shift key broken?
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. JSON form is very well defined.
I can agree with the problem of DAG complexity building up, sure, but that is a tradeoff.
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. I mean you could argue that they should have started with this, but imo better late than never. From what I've seen this will take load off of the client AND the server, because both don't have to sync thousands and thousands of events anymore. It basically looks like an indexing/caching layer between client and server, which is standard practice to make things go faster, especially for thin clients.
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"
I really don't get this attitude. It's not like global decentralized instant messaging with all the usability, bells and whistles of centralized services is an easy problem to solve. And no one is selling anything, not to regular users at least. If you thought that this would be a straight forward path to a finished product then idk what to tell you, that's not how this works.
It's not like global decentralized instant messaging with all the usability, bells and whistles of centralized services is an easy problem to solve.
Yup, absolutely, and being in this space myself as an enthusiast, that's an interesting problem to see being worked on and having significant brain power allocated to, though that doesn't remove anything from the fact that
a finished product
..is precisely what Matrix developers are advertising Matrix to be, and actively marketing it to be. You can go on hackernews right now and observe Arathorn telling everyone that everything is fine and solved now, even when shown evidence that it is not, like he has done since the beginning.
I believe people should know what they are engaging with.
precisely what Matrix developers are advertising Matrix to be
Idk what stuff you're reading, but every dev talk I've seen includes many acknowledgments of the shortcomings that still exist and the difficulty of the underlying problems. I never had the impression that they're trying to sell a silver bullet that'll fix everything once and for all. It's mostly just incremental changes here and there that fix or improve certain parts of the system, and with that a steady progress towards the goal.
Arathorn telling everyone that everything is fine
I wouldn't give too much on the speculations and opinions of any one person, even if he's the Matrix project lead. Probably especially the project lead, because part of his job is being optimistic about changes so they actually happen. But this is still mostly uncharted territory, and all anyone can do is make best effort attempts to improve things bit by bit. And from what I've seen he also openly talks about issues and the limits of coming changes, so perhaps you just read too much into his more optimistic posts and comments?
Personally I'm just excited for new developments, but also aware that any change has to prove itself in the field before it can be declared a solution for anything.
I wouldn’t give too much on the speculations and opinions of any one person, even if he’s the Matrix project lead. Probably especially the project lead, because part of his job is being optimistic about changes so they actually happen.
Yep, I think that's a very peculiar aspect of Matrix, about how it's run and why I have such a hard time trusting and recommending it. It's uncommon for opensource projects (especially "essential" ones) that adoption and fame must precede stabilization, as a condition to get to keep the cashflow and the lights on.
I don't think Matrix, starting up on venture capital, with an original but completely unproven idea, downplaying alternatives with FUD and superlative marketing, over-promising and constantly deflecting, was good community building.
Had they kept a lower profile and not an antagonizing one, they could probably have built and integrated better with the other communities in this space (and I'm not just talking about XMPP, which was on the receiving end of the FUD, but also about libera.chat whose OPs are right to be fed-up with NV).
so perhaps you just read too much into his more optimistic posts and comments?
Arathorn, 2023-09-23:
It's also true that 8 years ago, everything was flakey as hell. However, whether you like it or not, we fixed it. The federation problems were resolved before the time of Matrix 1.0 back in 2019, and since then we've focused on making everything go fast too - e.g. Faster Room Joins in Matrix 2.0.
I don't know any admin who considers federation problems to be solved, and I don't think Matrix 2.0 to be ready for the general public, so I call this denial, but heh, this is subjective :)
Seems like they're building other things in rust, about time for the server? Seems like bloated servers are the biggest downside of matrix. Does anyone more educated on this topic know why it's not a thing?
Because Synapse is already widely used. The Matrix foundation is also building Dendrite, which is in beta and written in Go.
Conduit is another server, in Rust https://gitlab.com/famedly/conduit
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
Yes, I'm confused by the released messaging. It feels like there may be a new server requirement. Search this page for Synapse https://element.io/blog/element-x-ignition/ to see the link to the guide.
The proxy is needed until sliding sync is finalised and merged into the spec and implemented into clients
For now, you need to run a sliding-sync proxy besides synapse. They'll integrate it properly, but for now the focus was on getting it to work.