Also:
> It's easy to pick a proprietary network like Telegram or an unsustainable one like Matrix,
What's unsustainable about Matrix? I've really enjoyed running our community on Matrix.
Matrix has been going strong for 10 years, and while it's true that the Matrix.org Foundation (and Element) need funding (c.f. https://matrix.org/blog/2024/01/2024-roadmap-and-fundraiser/ and https://matrix.org/blog/2024/04/open-source-publicly-funded-...) it's clear that elsewhere in the Matrix ecosystem there's loads of $ flying around: https://techcrunch.com/2024/04/09/wordpress-com-owner-automa... etc.
So I think it's a little ridiculous to call Matrix "unsustainable" (at least any more than any other FOSS project).
> I've really enjoyed running our community on Matrix.
I'm glad, thank you for using it.
Of course! We love how easy it is to get bots up and running, and the ecosystem of bridges made it really easy to incentivize people to onboard, because we can basically offer "for free" the ability for people to answer their instagram messages without opening instagram, etc.
Our only issue has been onboarding flow. We get that there's an "identity server" but when we use vector.im and generate invite links from for example Element, they usually get sent into a flow where they, confusingly, are making an account on some big home server instead of ours (I think like matrix.org or something). We were going to deploy our own identity server after someone on iirc matrix community chat somewhere mentioned that the email flow is implemented per identity server, but all the FOSS identity servers we could find were deprecated. Anyway now we just give people tokens that we generate in synapse and screenshot instructions lol. The one thing I miss from slack is being able to just right click a Room, click "invite," enter someone's email address, and it's all handled from there.
However, that's not what's being talked about here most likely (though it's unclear since when we just say "Matrix" or "XMPP" we're talking about a protocol, not a service, client, server, etc. so who knows). If you compare Matrix the foundation/company, they are VC funded (the foundation is a bit of a sham after community pressure, it's all the same people and accounts controlling it, so it's a step in the right direction but not really well established). The moment that funding dries up, or the Element people (who still mostly control protocol work) decide they want to monetize the users more, the whole thing will fall apart. That's unsustainable.
Meanwhile proper standards organizations like the IETF or XSF have been going for way longer than 10 years and have proven track records of sustainable funding and membership. People just like to pretend it's worse somehow because they're not building sexy looking software themselves with millions in VC funding. In reality infrastructure is never sexy, and if it's using unsustainable funding models it will fail. This seems like a good reason to pick something controlled by a real standards body over something that's not if you want a long-term community.
(P.S. Since someone once accused me of bias and deliberately not mentioning this even though I'm completely open about it: I have volunteered for the XSF and have done work on both Matrix and XMPP related products and open source projects; I chose to volunteer for the XSF after working on both protocols and evaluating their funding and leadership, so take that for what it's worth)
This not true.
Element (the company set up by the original Matrix team to fund their work) may be VC funded - but the Matrix.org Foundation is entirely separate, with its own leadership (the Managing Director is Josh Simmons, formerly president of OSI), its own accounts, and is funded by memberships and donations. It’s also electing its own governing board in the next few weeks: https://matrix.org/blog/2023/12/electing-our-first-governing...
Calling it a “sham” is demonstrably untrue, and far from pleasant.
Hi, author here. It doesn't need a 3rd party server - it's all hosted in Codeberg Git repos. Here's a guide - https://codeberg.page/
> What's unsustainable about Matrix? I've really enjoyed running our community on Matrix.
Many of us in the Delhi OpenStreetMap community are associated with projects like the Free Software Community of India, and run public instances of federated services, including Matrix and XMPP.
It has been our experience that XMPP has a dramatically lower server resource footprint than Matrix. We've actually had to close down a public Matrix service because it was economically unsustainable in this sense.
So far as I can tell, xmpp has no concept of threading, is that the case? It's what prevented me from choosing it when I went with matrix for my co-op.
I believe several are hosted on matrix.org.
However, user accounts aren’t portable yet, sadly. So the problem is more that if matrix.org disappeared then it would impact the user accounts homed on it.
> Talking over phone is the most reliable way to announce the party, send reminders and confirmations, and to coordinate during the party. That way, there's no question of "didn't check my messages/email".
Maybe it’s different in India but here in the states, when you tell most people that you’re not coordinating with imessage/sms (or fb messenger or whatsapp), you’ll get blank stares. I’m reminded of this: http://howfuckedismydatabase.com/nosql/fault-tolerance.png
[0] in particular because of the plight of the umbrella protestors in Hong Kong and the government's infiltration of coordination platforms
Meanwhile, Matrix has never needed the full room history to be synchronised - when a server joins a room, it typically only grabs the last 20 messages (with other history pulled in demand when the client scrolls up). (It does needs to grab all the key-value state about the room, although these days that happens gradually in the background).
If you're wondering why Matrix implementations are often greedy on disk space, it's because they typically cache the key-value state aggressively (storing a snapshot of it for the room on a regular basis). However, that's just an implementation quirk; folks could absolutely come up with fancier datastructures to store it more efficiently; it's just not got to the top of anyone's todo list yet - things like performance and UX are considered much more important than disk usage right now.