The road to mainstream Matrix [LWN.net]

By Joe Brockmeier
March 11, 2025

Matrix provides an open network for secure, decentralized communication. It has enjoyed some success over the last few years as an IRC replacement and real-time chat for a number of open-source projects. But adoption by a subset of open-source developers is a far cry from the mainstream adoption that Matthew Hodgson, Matrix project lead and CEO of Element (the company that created Matrix), would like to see. At FOSDEM 2025, he discussed the history of Matrix, its missteps in chasing mainstream adoption, its current status, as well as some of the wishlist features for taking Matrix into the mainstream.

Hodgson said that the mission for Matrix is to build the real-time communication layer for the open web so that "no single party owns your conversations". Matrix is an open standard for a decentralized communication protocol. Often, when people refer to Matrix, though, they may be referring as well to the server and client implementations, or the providers, such as Matrix.org, that offer servers for users. The Try Matrix page is a useful start for those who have not yet dipped their toe in the Matrix waters.

Quite a few people have taken the plunge already, though the numbers are small when compared to other systems like Slack, Discord, and Microsoft Teams, which Hodgson named as competitors to Matrix. Hodgson displayed a slide with the number of "retained users" across reporting servers. Retained users are the users who have been "actually hanging around for at least 30 days on the platform". If the user disappears, they are no longer counted. In 2019, the retained user count was in the tens of thousands. In the six years since "it's been growing fairly linearly" to reach nearly 350,000 users by early 2025.

The dream

The rest of the talk, Hodgson said, would be about the road to making Matrix mainstream, "and this is a road with a past and a future". It started in May 2014 with the dream of building the missing communication layer for the web. At the time Hodgson worked at Amdocs with a team of "about ten folks who'd been working together about ten years doing lots of [session initiation protocol] SIP" work. The team wrote its own voice over IP (VoIP) stacks and that sort of thing. The idea was that the team would build an implementation first (called "Project Synapse" originally) and then use that implementation to prove that the protocol works. "Then, having implemented it, we would spec it, updating the One True Spec. This would keep us anchored in reality. Hopefully."

Project Synapse was publicly launched, using the Apache License version 2.0, in September 2014 at the TechCrunch Disrupt conference after an all-night hackathon. At Disrupt, the project shipped Synapse (the server) and a client called Syweb (later renamed Matrix Console). Hodgson said that it actually had a lot of features when launched. "You'd have chat, you'd have one-to-one VoIP, you'd get federation in there too. I think VoIP got added literally at the last hour." The whole idea was to prove the implementations and then create the spec. After the launch, the team then went around the world to tell people about it and convince them to use it. That included a talk at FOSDEM 2015.

Hodgson said that the team really wanted Matrix to be more than chat, and wanted it to be mainstream "not just for geeks. No offense." For that, the project needed a killer app to bring funding for development. "We figured out there were 75 different products you can build on Matrix [the protocol]". He said that one idea was to create a "visual chat application" that featured something like Apple's Animoji, but four years before Apple had shipped the concept. Other product ideas included virtual worlds, government communications tools, or dating apps. In the end, the team decided to converge on a professional collaboration application it originally code-named "Skype done right". It was named Vector on launch—as in "a vector to push Matrix out into the world". That was launched in 2016. Then Vector was renamed Riot, and ultimately became Element in July 2020.

The original sin and mainstream miss

End-to-end encryption (E2EE) work started about the same time that Vector was launched. Hodgson called the E2EE work "the original sin of Matrix" because it slowed development velocity down significantly. People who remembered Matrix before E2EE development began may have felt "oh my God, this thing is going incredibly fast". Then everything ground "not to a halt, but probably ten times slower than we'd been going before". As it turns out, decentralized encryption is rather hard.

At the same time, Matrix was getting real attention. People were excited about a new protocol that would liberate them from the silos of proprietary applications. "Entirely my fault for hyping it to the heavens and back," he said. There was lots of pressure from the community to improve the spec, because it was "very much following what we were implementing". Unfortunately, the governance for a spec process wasn't there. The team behind Matrix wound up investing a lot of time into trying to make the spec something everyone could build on rather than shooting for mainstream adoption with a killer app people could use.

And I think it's an interesting and very controversial viewpoint, which will probably get people to throw rotten fruit at me, that perhaps in retrospect we should have ruthlessly prioritized polishing the app or an app to drive mainstream adoption. Rather than, perhaps prematurely, focusing on the open ecosystem.

One thought example, Hodgson said, was that Matrix itself should not have been primarily positioned as a protocol. It could have been the name of an app "which was a Trojan horse, unashamedly, for a protocol". Rather than setting expectations from the outset that Matrix would be the missing communications layer of the web, "you could have just shipped a really, really good thing like, say, Skype". He noted that the Bluesky social-media service is taking this approach with its Authenticated Transfer Protocol (atproto). This has been "pretty controversial, but it seems to be working out for them" in that they are effectively smuggling a decentralized protocol under the guise of a centralized communication network.

Hodgson said that he knows the people developing Bluesky and believes that they are "genuinely aiming to decentralize things", but they are following the track that Matrix did not follow. As a result, they have a mainstream, successful, decentralized social-media app "whereas we've been on this Escher-like infinite staircase".

Most of the initial work on Matrix was funded by Amdocs until 2017 when the team set up a company called New Vector, which was a subsidiary of Amdocs. In 2018, the Matrix.org Foundation was established to ensure that Matrix would be independent from commercial vendors. In 2020 the company took the name Element, and adopted the Element naming for its products as well. Hodgson said that the company spent 70 to 80 percent of its funding on building out Matrix for many years before transferring its IP to the Matrix Foundation.

1.0 ships

From 2018 to 2021 Matrix entered what Hodgson called its "halcyon days", with many open-source communities—and government entities in France, Germany, and elsewhere—rolling out their Matrix presence. There were hints of killer apps forming, such as one of the forks of Element, Beeper. Lots of projects and products were being built on Matrix, like peer-to-peer Matrix applications, low-bandwidth versions, Gitter integration, virtual-reality demos, and other applications beyond chat. "All of this inspirational work made for some fun demos at FOSDEM, but it did steal a lot of energy from writing that killer mainstream app."

In 2022, "the wheels come off". The markets crashed post-COVID, there was no more zero-interest-rate policy, and "no more investment, really". Element is not yet profitable, and not in a position to raise more money, but it is seeing adoption in the public sector. "Governments realize that the idea your country is operationally dependent on a private US tech company like Microsoft is bananas." So Element decided to focus on government implementations to become more profitable and sustainable.

That, said Hodgson, has two big failure modes. The first is losing bids on contracts to large system integrators. A government entity would put out a tender for a Matrix deployment, which would wind up going to the integrators because they have local staff, existing contracts, and know all the right people. The integrators then pick up the open-source Synapse off GitHub and support it themselves, without any of the money being routed to the upstream development. That happens again and again, Hodgson said.

Basically, almost every deal, I think, that we had on the Element side for providing Matrix to governments ended up disappearing to somebody who basically could win it because they didn't have the cost of developing Matrix.

The second failure mode is that a government is willing to put public money toward open-source feature development, but not toward maintenance or support fees. The upstream gets paid to do features, which is good, he said. For example, all of the Matrix 2.0 work on the Element X Matrix client app for iOS and Android been funded by government contracts. But those features may not be applicable to a mainstream client. Or the government client may say "here's $500,000, go and implement threads or whatever." But, Hodgson said, threads, which allow users to visually branch their conversations in a Matrix room, are a maintenance nightmare and no one is paying for continued development and maintenance of that feature.

Survival time

By the end of 2023, Hodgson said that Matrix was being taken for granted as a commons. The creators of open-source implementations were cut out of paid implementations, as there was little incentive to pay for Matrix's development. "So it started to get fairly drastic at the end of 2023". At this point Element started to focus on being sustainable and switched from the Apache License-2.0 to the AGPLv3 for its contributions to Synapse and other backend Matrix projects. The research and development projects were shelved in favor of focusing purely on stability and quality, which was "arguably a good thing for the ecosystem overall". Even with those changes, though, free riding is still posing an existential threat to the whole ecosystem.

Free riding is the technical economic term for this failure mode when people take the free thing and milk it for all it's worth and don't maintain it.

Hodgson said that the simple answer is that organizations buying a commercial Matrix deployment should also mandate that the upstream project is funded by buying that upstream's products. He suggested that organizations should "only buy from people who are actually going to fund upstream maintenance" and normalize paying for open-source products as much as they pay for proprietary ones.

Licenses for things like Adobe Acrobat or Microsoft products are in the billions of Euros per year for government agencies, but then the same agencies say "we don't have the two million a year that would be needed to provide some support for the Matrix stuff". People might feel that this is just "evil Element trying to force people to buy their thing", he said, but there are other open-source implementations out there. If the upstream isn't suitable, then switch, and that would be "true public money for public code."

Some organizations, such as the Center for Digital Sovereignty (ZenDiS), do get it right in Hodgson's book. It provides openDesk collaboration software and has worked with Element, Nextcloud, Open-Xchange, and others to incorporate those projects into the product. ZenDiS's ground rules, he said, were "we will just go and pay for their professionally supported product, full stop". Hodgson said that a lot of Matrix vendors, including Element, have ended up focusing on government and healthcare initiatives to survive. As a result, "you end up with enterprise features prioritized over the mainstream consumer and community-centric features". But sometimes what is good for government adoption is good for mainstream uptake as well.

Matrix 2.0

Hodgson introduced Matrix 2.0 in 2023 at FOSDEM. Previously the idea had just been to make Matrix work right, but with Matrix 2.0 the idea is to "make it not suck". That means making Matrix fast and usable—and that means a number of proposals to enhance the spec. Proposals to change or enhance the Matrix specification are offered as spec change proposals, known as MSCs, which follow a process that is likely familiar to anyone who has worked with a standards process before. Hodgson said that implementations of the MSCs for Matrix 2.0 "that prove that 2.0 could work" landed in September 2024.

One of those is MSC3861, which lays out next-generation authentication for Matrix. It adds industry-standard OpenID Connect (OIDC), QR login, two-factor authentication, and more. Currently, Matrix's OIDC implementation is merely "ODIC-ish", according to Thibault Martin, who wrote a useful blog post in 2023 to explain some of the authentication changes for Matrix 2.0. According to Hodgson, MSC3861 is implemented in the Matrix Authentication Service and many Matrix clients. He said that the plan is to turn next-generation authentication on after it passes the final comment period in the MSC process "so that we drag everybody on the Matrix.org instance, kicking and screaming, into the brave new OIDC-world future".

Simplified Sliding Sync (MSC4186) is a feature that will, Hodgson said, provide "instant login, instant launch, and instant sync" of a user's chat history and rooms. As an occasional user of Matrix, I can attest that this is a sorely-needed feature. The wait for Matrix to load is painful. He said that it is close to entering the final comment period, but has an edge case that needs to be sorted out, and is already implemented in the Synapse and conduwuit servers.

Matrix real-time communication (MatrixRTC) is a set of MSCs that define native encrypted group VoIP and video calls with pluggable media engines. Hodgson said that this is already implemented in Element Call, Element Call Web, and Element X clients as well as a WhatsApp-like client called Famedly that is aimed at German healthcare providers, but that "we are still incorporating feedback" on the specification.

Finally, there is the "invisible crypto" specification, which is laid out in MSC4153 ("Exclude non-cross-signed devices") and others. The idea behind this specification is to make E2EE "invisible" to users, as it is on systems like Signal, iMessage, and others. Hodgson said that there are people who don't understand the specification and say "this is crap, they're removing all the warnings, it won't be safe anymore". That is the opposite of what invisible crypto is. "The whole idea is to make it more safe by removing the unactionable cryptic (see what I did there?) warnings" about unverified devices and message authenticity. It will require users to identify their devices at login and then it will simplify the experience of using E2EE massively.

Implementations of invisible crypto were launched with the Element X client and Element Web but "we kind of forgot to actually ship this in a community-friendly distribution". He said that there would be AGPLv3 Helm charts (a packaging format for deploying software on Kubernetes) "coming soon" to allow community users to deploy the feature.

Hodgson talked a bit about the first Matrix conference, which was held in September 2024, and noted that there were many independent, production-grade implementations of Matrix available and discussed at the conference. "This is a properly heterogeneous ecosystem" with totally separate stacks without any shared code. That demonstrated, he said, that Matrix was a true ecosystem and not controlled by Element.

The next ten years

Hodgson briefly discussed State Resolution 3, and Chaos. State Resolution 3 is an overhaul of the way that Matrix replicates state (such as room membership and permissions) between servers. The plan for State Res 3 involves the Time Agnostic Room DAG Inspection Service (TARDIS), which provides a "time-traveling debugger" for Matrix room directed-acyclic graphs (DAGs). Chaos is a fault-tolerance-testing tool for Matrix servers, in the vein of Netflix's Chaos Monkey. While Hodgson did not go into detail on these during his talk, they were the topic of another talk at FOSDEM by Kegan Dougal, "Demystifying Federation in Matrix".

Message-layer security (MLS) (RFC9420) defines efficient key exchange across a set of devices. "If I had another three hours, I would talk about MLS in great detail", Hodgson said. There are two proposals to add proper MLS to Matrix, and it is an active area of research, but both proposals are blocked on funding. There is also a pull-request to add the post-quantum extended Diffie-Hellman (PQXDH) protocol to Matrix, which was mentioned at the last FOSDEM. Hodgson said that "we assumed that somebody would leap out of the audience" to offer funding for that work, but a year later nothing has happened. Element is also experimenting with post-quantum group messaging but again, he said, progress is blocked on funding. There are lots of missing features needed for mainstream support on the client and server, Hodgson said. For example there is lots of trust and safety work to be done. "We are expanding the team there and making some progress". He did not discuss other features, but his slides listed features like custom emojis, voice rooms ("for Discord folks"), and safety tooling to hide things like invite spam.

The Matrix Foundation, he said, is key to the future of Matrix. "The next ten years of Matrix will be nurtured the foundation if it has funding". He asked the audience to join the foundation, or "even better, bully your employer to join if they like Matrix and use Matrix". There was no time left for questions, but he invited the audience to join the Matrix state of the union talk immediately after his. The video and slides for Hodgson's talk have been uploaded to the road to Matrix talk page on the FOSDEM 2025 web site.

Coda

On February 20, Martin and Robin Riley posted an update to the Matrix.org blog with a plea for funding.

The Matrix.org Foundation has gone from depending entirely on Element, the company set up by the creators of Matrix, to having half of its budget covered by its 11 funding members, which is a great success on the road to financial independence! However half of the budget being covered means half of it isn't. Or in other words: the Foundation is not yet sustainable, despite running on the strictest possible budget, and is burning through its (relatively small) reserves. And we are at the point where the end of the road is in sight.

The bottom line, according to the post, is that the foundation needs to raise $100,000 of funding by the end of March, or it will have to shut down bridges to other networks that are hosted by the foundation. This includes bridges to Slack, XMPP, and IRC.

Raising $100,000 would extend the runway by one month, but the foundation says that it needs to raise an additional $610,000 to break even. The full cost of operations is $1.2 million, but the foundation is only bringing in about $561,000 currently. The post lists a number of ways individuals or organizations might help fund the foundation.

Seeing open-source projects build their communication strategies around proprietary tools, like Discord and Slack, is discouraging. Some of us might even say short-sighted. Whatever warts Matrix may have, it is one of the few open alternatives that is viable and relatively simple for projects to adopt. One hopes that the foundation will find ways to be sustainable.

[I was unable to attend FOSDEM in person this year, but watched the video for the talk when it became available. Many thanks to the video team for their work in recording all the FOSDEM sessions and making them available.]

Index entries for this article
Conference	FOSDEM/2025

to post comments

Financial situation

Posted Mar 11, 2025 20:01 UTC (Tue) by Hello71 (guest, #103412) [Link] (7 responses)

I don't use Matrix, but I support their mission in principle. Everything in the first half of the article sounds like they're trying hard to accomplish that.

The last section of the article is a bit surprising. Why does shuffling around mostly plain-text chat cost $100,000 per month? Does that include salary costs, or only servers? It's not explained on the linked article, nor is there any link there to financial reports, nor on the donation page. After some digging, I found https://github.com/matrix-org/matrix-spec/issues/571, which seems to say that the Foundation's reports barely cover legal requirements (or maybe they don't?), and public promises to provide any more detailed information are repeatedly broken. If they were asking for a few thousand or tens of thousands to cover a couple servers, then I guess that's forgivable, but this is millions of donated dollars and regular pleas for "just a little more money" while reporting promises are apparently ignored.

Financial situation

Posted Mar 11, 2025 21:40 UTC (Tue) by NYKevin (subscriber, #129325) [Link] (6 responses)

Honestly, when I look at the numbers in [1], they look too *low* if anything:

> $360K/yr – Trust & Safety

In the US, that's ~3-6 people depending on how well you pay them. I'm not sure exactly how salaries in the UK compare, but it's probably not a massive difference. If I'm right, then they have 1 T&S employee for every ~50k-100k users, which seems... low? I dunno, maybe Matrix users are extremely well-behaved and everything is fine, or maybe they have really, really good tooling. But I would be worried about burnout and long-term sustainability here.

> $240K/yr – Server and SRE

It is hard to believe that you can afford more than ~2-4 SREs with that money, and you're also paying for servers on top of that. As an SRE, I would not be thrilled with a team of 2-4 people. That's just about enough people to keep the pager covered during business hours in one time zone, but you're not getting much of anything done beyond that.

> $170K/yr – [Robin Riley's] salary, covering fundraising, open governance, community relations, biz ops, and people mgmt

We can argue over precisely how much Riley should be paid for this work, but $170k/yr does not strike me as exorbitantly high.

> $150K/yr – Matrix Conf + other events

I've never put on a conference before, but this sounds like a plausible number to me. You have to rent out a large space, pay for at least some travel expenses, temporarily hire a lot of people for logistics and security, etc., and that's going to add up to a lot of money.

> $30K/yr – Assorted expenses like travel, lodging, productivity infra

I could imagine shaving a few thousand off here or there by taking cheaper flights, skipping unnecessary in-person visits, etc., but that possibly jeopardizes fundraising, and it's a fairly small part of the budget anyway. "Productivity infra" is vague and I'm not entirely sure what they mean by it, but there are enough plausible interpretations, and a low enough dollar value, that I find it unconcerning (engineers' laptops, build clusters, maybe even desks and chairs, etc.).

> $250K/yr – Other folks, covering program management, legal, compliance, finance, IT, security, dev

And this is the really baffling number. I cannot believe that you could hire professionals in all of those different areas of expertise for $250k/yr in total - this seems like it should pay for at most ~2-4 people, for seven jobs. The only plausible explanation (that I can think of) is that somebody is wearing several different hats at once. If so, kudos to the Matrix folks for hiring people with just the right competences.

All told, this adds up to ~8-15 people, which is pretty much the ballpark estimate I thought of when I first saw the number "$100k per month." Given everything Matrix is trying to do, I find it hard to believe that they're going to accomplish it with fewer people than that. I do agree that more transparency would be nice, but I don't think $100k/mo is excessive under the circumstances.

TL;DR: Human labor is expensive, and $100k/mo is plausible for an organization of this size and complexity (but more transparency would be better).

[1]: https://github.com/matrix-org/matrix-spec/issues/571#issu...

Financial situation

Posted Mar 11, 2025 22:09 UTC (Tue) by Wol (subscriber, #4433) [Link] (1 responses)

> In the US, that's ~3-6 people depending on how well you pay them. I'm not sure exactly how salaries in the UK compare, but it's probably not a massive difference.

Bear in mind, last I knew, UK salaries were a lot flatter, so somebody who is reasonably well paid in the UK would be earning maybe half what someone in the US would be on.

That said, if I had to pay rent on my (small) house, it would be roughly 100% of my net salary, so a lot of young people can't afford NOT to have a very well paid job (or live at home with their parents) if they want anything close to a comfortable life.

Cheers,
Wol

Financial situation

Posted Mar 11, 2025 22:47 UTC (Tue) by NYKevin (subscriber, #129325) [Link]

In the specific case of T&S employees, you may have a point. I somewhat conservatively assumed they would be paid at least $60k/yr, but T&S is often considered unskilled work, so they could plausibly be paid somewhat less than that even in the US.

However, I reused this lower bound of $60k for all of the other (more skilled) roles, and those are a bit different. In the US, $60k is maybe reasonable as a starting salary for somebody fresh out of college (at least in a low cost of living area), but it is entirely normal for an engineer's salary to more than double within a few years (and the data at https://www.levels.fyi/t/software-engineer/locations/lond... suggests that this doubling is also a thing in the UK, given the wide range and long tail of high-paid jobs). Even given the UK's lower pay rates, I would tend to assume that the Matrix folks won't be able to pay salaries too much lower than $60k for very long, unless they are constantly replacing their engineers with new people who don't know what they're doing. The video game industry manages to do that, mostly because too many people want to work there, but it's a recipe for death marches and failed projects.

Even ignoring all that, if we conservatively double all of my estimates, that still puts them at an upper bound of ~30 people, which is still plenty small IMHO.

Financial situation

Posted Mar 12, 2025 2:10 UTC (Wed) by Hello71 (guest, #103412) [Link] (2 responses)

That's all well and good, but all those paragraphs don't explain anything about where the $100K figure comes from or what it has to do with bridges?

Financial situation

Posted Mar 12, 2025 2:22 UTC (Wed) by jzb (editor, #7867) [Link]

It doesn't explain exactly why the figure is $100K, but this

"However, these bridges require regular maintenance as the bridged platforms evolve their APIs, and significant engineering and moderation support to run."

at least gestures toward an explanation of why they'd cut that service first. If you're having to bridge, say, Slack and Matrix, that requires development time each time Slack changes its API -- which it can do any time, without regard to interoperability with Matrix. So it sounds like that service is both a convenience feature not needed to run Matrix and probably a bigger hassle to keep running than just supporting the Matrix protocol that they are involved with.

Financial situation

Posted Mar 12, 2025 4:32 UTC (Wed) by NYKevin (subscriber, #129325) [Link]

The numbers given add up to $1.2M per year. Divide by twelve.

Financial situation

Posted Mar 18, 2025 17:17 UTC (Tue) by misc (guest, #73730) [Link]

> All told, this adds up to ~8-15 people

The webpage of the foundation ( https://matrix.org/foundation/about ) say there is a 5 people staff, with only 1 being directly employed by the foundation (Robin), and the 4 others being working for Element, but paid by the Foundation (as the page say "most of our staffers are employees of Element, working under a contract with, and funded by, the Foundation").

I am sure there is good reasons for that specific setup, but to be honest, I can see how it would also look sketchy to have the non-for-profit money going to the for-profit entity that spun it in the first place.

How NIH actually kills progress

Posted Mar 11, 2025 20:45 UTC (Tue) by PeeWee (subscriber, #175777) [Link] (11 responses)

I remember quite well when I first heard about Matrix and how I thought: "What was wrong with Jabber/XMPP?" Most, if not more, of Matrix's initial features were already present, albeit maybe a bit unpolished. Also the timing was iffy, because it was one of those "post-Snowden" apps, where everyone and their dog reinvented the wheel of crypto, and threw out the baby with the bathwater in the process. I will never use an app that requires a smartphone, because of the fact that it already has a unique ID, i.e. the phone number (talk about lazy devs!) - yes, I am talking about you Signal; hashing phone numbers is a cheap gaslighting attempt to gloss over this design flaw and it's useless given that the phone number namespace is rather small in terms of computational effort for a rainbow table. I am not necessarily talking about Matrix here, but more generally. And the talk about "easy" authentication of devices is onerous, and always has been. The only app, I know of, which does a proper job of, rather easy, authentication is Conversations, which - surprise, surprise - uses XMPP, and lets users authenticate each others public keys by providing QR codes. It does also "authenticate on first use", as any other app does these days, but the only proper authentication is to actually add a new contact in a (personal or video chat) meeting and scanning the respective QR codes - if it's too easy there is only a false sense of security and reliance on luck; which is just bad advice for people like dissidents.

And all this talk about hosting really takes the cake, since public XMPP servers had already been very well established back in 2013 (the "Snowden year"). It's hardly any different than an email server. In fact the user IDs look like email addresses and some mail providers actually had additional XMPP services that one could use with the already existing mail address, doubling as XMPP user ID. Many more things had already been available back then, like GPG encryption, or OTR, offline messages (depending on server support, which is a non-issue when self-hosting), group chats etc.

Thus Matrix feels like the epitome of NIH when keeping in mind what it started out as and what XMPP had already in turnkey state. So instead of doing yet another "post-Snowden" hip shot, much of the effort could have been redirected to improving the XMPP sphere. And I simply cannot shake the feeling that someone wanted, or still wants, to get rich off the fallout from the Snowden leaks, so they must, at all cost, never even mention the existence of XMPP and act as if they first invented a subset of that protocol suite - and then feature creeped their way up the ladder. If anything, they are part of the problem, in that they poison(ed) the well by making people believe true strong crypto can be had without any hassle, which is just a blatant lie. But that horse has bolted and I will never again be able to convince less technical minded people to use proper tools and authentication. If it hasn't become clear by now: I have been fuming and blow a gasket every time Matrix, Signal and their ilk come up.

How NIH actually kills progress

Posted Mar 11, 2025 20:56 UTC (Tue) by Cyberax (✭ supporter ✭, #52523) [Link] (9 responses)

> Thus Matrix feels like the epitome of NIH when keeping in mind what it started out as and what XMPP had already in turnkey state.

XMPP was not in a "turnkey" state at that time. It still is not. XMPP is just a terrible protocol.

How NIH actually kills progress

Posted Mar 11, 2025 22:05 UTC (Tue) by PeeWee (subscriber, #175777) [Link] (8 responses)

Given that Matrix basically reinvented most of it and that one could use XMPP back then, that equates to "turnkey" in the grand scheme of things. If anything, the effort would have been better aimed at improving the XMPP experience, instead of starting from scratch, is what I am saying. Given the homeopathic adoption figures, your argument can just as well be made about Matrix. So, instead of one protocol suite, we now have two, which cannibalize each other. Plus, there were plenty XMPP clients when Matrix was still in its infancy. And speaking of infancy, it looks like they are now at the toddler stage while XMPP seems to have at least graduated Junior High. ;-)

How NIH actually kills progress

Posted Mar 11, 2025 23:28 UTC (Tue) by Cyberax (✭ supporter ✭, #52523) [Link] (7 responses)

> Given that Matrix basically reinvented most of it and that one could use XMPP back then

No, you couldn't. XMPP back then didn't support the distributed encryption for group chats (Axolotl ratchet and all that). The XEP for it was approved later, around 2017. I don't think it's widely implemented to this day, either.

And XMPP protocol _itself_ deserves to die a flaming death, it's just bad.

How NIH actually kills progress

Posted Mar 12, 2025 0:26 UTC (Wed) by jkingweb (subscriber, #113039) [Link] (6 responses)

> I don't think it's widely implemented to this day, either.

There's a tracker for it here:
https://omemo.top/

By my count it's 16 distinct clients. According to the Matrix client list, 17 distinct clients implement end-to-end encryption, so the two seem to be equally widely (or narrowly?) implemented.

How NIH actually kills progress

Posted Mar 12, 2025 9:47 UTC (Wed) by tzafrir (subscriber, #11501) [Link] (2 responses)

I could hardly find a decent Matrix client for my Linux phone. Matrix client seem to mostly be repackaged Element (and badly done so) or not that convenient to use.

With XMPP I have several useful clients, one of them (Dino) works well on my phone.

Generally for me XMPP works and Matrix: sort of works. And less intuitive. It's niicer for public chat rooms, but not for personal communication.

How NIH actually kills progress

Posted Mar 14, 2025 8:51 UTC (Fri) by debacle (subscriber, #7114) [Link]

Matrix works reasonably well for me — using "slidge" as a gateway from XMPP, though.
That way I can use the Jabber clients Dino, Gajim or Profanity as Matrix clients.
E2ee is broken on the bridge atm., but I use Matrix only for public rooms anyway, i.e. I don't care.

Mobile Linux Matrix clients

Posted Mar 16, 2025 15:14 UTC (Sun) by KJ7RRV (subscriber, #153595) [Link]

Have you tried using Fractal? It works well for me on my PinePhone, tablet, and laptop; the phone and tablet run Arch with Phosh and the laptop runs Mint with Cinnamon.

How NIH actually kills progress

Posted Mar 14, 2025 9:27 UTC (Fri) by debacle (subscriber, #7114) [Link]

Adding modern encryption to Jabber (groupchats) was probably less complex then inventing a complete new protocol suite.
But for building on existing technology, it is hard to get VC.
You need to use trendy stuff, e.g. in that time JSON became more popular than XML, so it was a must to use that.
So the created M.A.T.R.I.X., the Monolithic, Awfully Trendy Re-Implementation of XMPP, and that worked out pretty well.
(The name "Matrix" was also a reference to a 1999 film, the year Jabber has been invented!)
To get new VC, they probably should not improve on Matrix, but invent something entirely new.

How NIH actually kills progress

Posted Mar 14, 2025 19:11 UTC (Fri) by Cyberax (✭ supporter ✭, #52523) [Link] (1 responses)

The devil is in details. Things like pasting videos or audio content on top of E2EE chats are spotty.

The problem is that XMPP is not really a chat protocol. It's a message delivery protocol with association management. It's fair to say that it's something like SMTP, but with persistent connections. And it's a really bad protocol in itself, it uses a never-ending stream of XML stanzas over a custom port, rather than HTTP.

So all the work to build reliable _chat_ protocol has to happen in the layers built on top of XMPP. E.g. if you want to get an archive of your past messages when you log in from a new device. That's an extension. You want that encrypted? That's another extension. Want audio and video in that archive? You guessed it, another XEP.

And when you have literally hundreds of extensions, you get an integration hell where nothing works 100% reliably.

How NIH actually kills progress

Posted Mar 15, 2025 15:38 UTC (Sat) by raven667 (guest, #5198) [Link]

> never-ending stream of XML stanzas

Yeah, this is unfortunate, it was designed at the height of the XML craze, which thankfully didn't last long, but so much was built during those 5 or so years that continues to plague us today. Eventually the wider development community shifted to JSON/HTTPS/REST for more efficient and simpler to reason about protocols, XML might solve some particular set of problems but it's way to inefficient, verbose, fiddly and mismatched with most computer languages and data formats to be the one and only true format for data interchange, for XMPP having it stream is also working directly against the intended design of XML parsers, which were designed for complete and enclosed documents, and as you point out making all the useful functionality subject to a wide array of incomplete extensions makes it even worse than X11 or Wayland chaos trying to find the compatible subset between two users and the servers that bridge them (4 different software entities), maybe the server implementations eventually winnowed their way down to a few common ones that could coordinate but it seems that browser standards eventually surpassed a lot of XMPP, with WebRTC for example, such that you could build web apps with more functionality than native XMPP clients that use a more familiar, supportable and scalable technology stack on the server side.

I do miss 2010 though when you could get a MacOS Unix workstation with OpenSSH, Terminal, iChat XMPP, WebKit browser, Mail and Calendar with Exchange ActiveSync, X11, perl, python, gcc, etc. As a sysadmin working with Linux I could do pretty much my entire job with only the built-in, out-of-the-box applications with basically no drama, in a different world chat/voice/video wouldn't have fragmented so badly into webapp silos and you'd still be able to get at least a basic functional experience out of the box on whatever OS you use. Now you need to run literally gigabytes of Electron apps to be logged into Slack and Teams and Discord and whatever else (Mattermost, Matrix, Messages/iMessage, IRC if you are freaky) and they are totally disconnected experiences with independent identities, notifications, features, etc. when you could have one native client using 1/10th of the resources with a consistent interface that talks to all of them.

How NIH actually kills progress

Posted Mar 12, 2025 10:49 UTC (Wed) by paulj (subscriber, #341) [Link]

Re Signal and phone numbers, have you looked at Session (getsession.org)? Kind of a Signal fork on the UI side (IIUC), but it seems the whole low-level communication infrastructure has been replaced with a decentralised one (Oxen), with identity derived from a random cryptographic key-pair.

Downside is, it hasn't had a lot of review, young and not really "battle tested" yet. Also, potentially has some scaling / perf. issues.

Tried it a few times, was horrible, won't try it again unless something major changes

Posted Mar 12, 2025 9:22 UTC (Wed) by taladar (subscriber, #68407) [Link] (3 responses)

I am sorry for all the Matrix advocates but Matrix is one of those protocols that really has not figured out what users actually want out of a method of communication.

When I tried it the performance in large group chats was horrible, the performance requirements for running a server were even worse, the on-boarding is too complicated to ever even think about trying to get any of the people on there I would want to communicate with.

What is the point of Matrix? This whole article talks about funding and features but it completely omits any mention of how to actually get adoption, both for more server operators and communities to use Matrix and for actual users or any analysis about the causes for lack of adoption.

Instead some of the features that are just about the only advantages of Matrix over the competition like E2EE are called into question and portrayed in a negative light.

Tried it a few times, was horrible, won't try it again unless something major changes

Posted Mar 12, 2025 15:19 UTC (Wed) by zdzichu (subscriber, #17118) [Link] (1 responses)

Performance requirements for running a server seem reasonable. Unless you are running Synapse, which is written in Python - not a speed daemon. I suggest trying conduwuit mentioned in the article (Rust-based). Or dendrite, written in Go.

Speaking of dendrite, it was "adopted" by Element, but development stopped afterwards. Any mention of it in the talk?

Tried it a few times, was horrible, won't try it again unless something major changes

Posted Mar 12, 2025 15:50 UTC (Wed) by jzb (editor, #7867) [Link]

Speaking of dendrite, it was "adopted" by Element, but development stopped afterwards. Any mention of it in the talk?

Mention yes, very briefly. He mentioned it once in passing—just a name check—and again briefly to say there was a PR to implement next-generation authentication from someone named "midnight" in dendrite. I don't think development has stopped entirely, but it has moved to Element's GitHub organization here. The last commits in the main branch were on February 4th.

Tried it a few times, was horrible, won't try it again unless something major changes

Posted Mar 12, 2025 16:18 UTC (Wed) by marcH (subscriber, #57642) [Link]

> This whole article talks about funding and features but it completely omits any mention of how to actually get adoption,

Did you read it? I felt like it was the main point:

> perhaps in retrospect we should have ruthlessly prioritized polishing the app or an app to drive mainstream adoption. Rather than, perhaps prematurely, focusing on the open ecosystem.

Timeline does not fit

Posted Mar 12, 2025 11:14 UTC (Wed) by paravoid (subscriber, #32869) [Link] (5 responses)

> From 2018 to 2021 Matrix entered what Hodgson called its ""halcyon days" [...] Lots of projects and products were being built on Matrix, like peer-to-peer Matrix applications, low-bandwidth versions, Gitter integration, virtual-reality demos, and other applications beyond chat. ""All of this inspirational work made for some fun demos at FOSDEM, but it did steal a lot of energy from writing that killer mainstream app"."

> In 2022, ""the wheels come off"".

...and yet I distinctly remember Hodgson spending a considerable chunk of his FOSDEM *2023* "Matrix 2.0" keynote in the main Janson room to demo this aforementioned VR functionality, while wearing and VR headset etc. Plus talking about all kinds of exotic and/or experimental projects (P2P, Dendrite, decentralized MLS etc.) in a talk that was supposed to be all about the polished experience. Video: https://archive.fosdem.org/2023/schedule/event/matrix20/ (VR demo starts at the 40min mark).

So at minimum I don't think this timeline as described here fits reality all that well.

For what it's worth, I remember this talk, because I felt quite saddened and hopeless (and if I'm being honest, a little weirded out) by it. I was sitting there, forced to use a proprietary app (Slack) to perform basic functions of my work, plus a bunch of proprietary apps to chat with friends and family (WhatsApp etc.), and the piece of software that I was considering the most promising escape from these walled gardens was a) unusable for even my very basic use cases, and b) and yet too busy chasing whatever trend exists at any given time, such as the 2022-2023 Metaverse hype. This included performing major/full rewrites of their stack (e.g. to Rust), while trying to cover entirely new use cases (VoIP & Meet/Teams-like functionality), and trying to become an IETF standard - all at the same time.

Even as we speak, Element is currently shipping *two* separate apps on the Play Store (Element & Element X), both considered stable, both regularly updated and recommended for use. Element X, i.e. the "we’ve completely rewritten the app in Rust" version, was first released in beta in mid-2023, and became "stable" in September 2024, but has not reached feature parity and is thus not a replacement per se. These are the flagship apps by Element the company mind you, not a random community fork or something.

Hodgson's 2025 talk, as captured in this article, seems to paint a better and perhaps promising picture, in the sense that they seem to have finally realized the value of simplicity, of doing a few things well before trying to do all the things, as well as of the costs of the second-system syndrome. One can hope! In any case, best of luck to Matthew Hodgson, Amandine le Pape, Robin Riley & their respective teams. All extremely talented folks, which I'm confident are capable of learning from past mistakes and course-correcting.

Timeline does not fit

Posted Mar 12, 2025 11:41 UTC (Wed) by Phantom_Hoover (subscriber, #167627) [Link]

> and yet I distinctly remember Hodgson spending a considerable chunk of his FOSDEM *2023* "Matrix 2.0" keynote in the main Janson room to demo this aforementioned VR functionality, while wearing and VR headset etc.

This just sounds to me like the 2022 shock took a while to move through the pipeline, not anything disingenuous.

Timeline does not fit

Posted Mar 12, 2025 23:04 UTC (Wed) by Arathorn (guest, #101018) [Link] (3 responses)

> So at minimum I don't think this timeline as described here fits reality all that well.

FOSDEM 2023 was the first week of Feb 2023, and so I demoed the stuff we had been working on over the previous year, hoping that someone would understand the potential of an open spatial collaboration platform built on top of Matrix's decentralisation & e2ee. Instead, folks wrote it off as "chasing whatever trend exists at any given time, such as the 2022-2023 Metaverse hype". We then kept it going for as long as we could, until eventually shelving it in July 2023.

> Even as we speak, Element is currently shipping *two* separate apps on the Play Store (Element & Element X), both considered stable, both regularly updated and recommended for use

The legacy Element app has had no work beyond critical maintenance since July 2023; all effort has gone into Element X. Most people seem to agree that the enormous improvements in Element X justify the rewrite, even if it doesn't have threads & spaces yet. (Threads should land in a few months, fwiw). Yes, that means that we have to keep the old app around for features which don't have parity - much as (say) Apple kept Classic MacOS and Mac OS X around in parallel for years. It worked out okay for them in the end, and hopefully it will for Element too.

> the piece of software that I was considering the most promising escape from these walled gardens was a) unusable for even my very basic use cases

Well, that's why we wrote Element X. I get the impression that much of the unhappiness here and elsewhere in the comments comes from people disappointed in Matrix and Element based on bad experiences years ago. All I can suggest is giving the current stack a go - and then at least we can also fix issues which come up.

Timeline does not fit

Posted Mar 13, 2025 10:08 UTC (Thu) by paravoid (subscriber, #32869) [Link]

Thanks Matthew for taking the time to respond and engaging with this thread. Highly appreciated!

> FOSDEM 2023 was the first week of Feb 2023, and so I demoed the stuff we had been working on over the previous year [...] until eventually shelving it in July 2023.

Appreciate the insight. The article -at least how I read it- made it sound like this kind of experimentation ended in 2021 (2022 being the year of "wheels off" etc.) which didn't match my observations. This revised timeline of mid-2023 seems more plausible to me!

> Apple kept Classic MacOS and Mac OS X around in parallel for years. It worked out okay for them in the end, and hopefully it will for Element too.

I don't think comparing your strategy to one by a big-tech megacorp with infinitely more people, money and market penetration is a good argument, especially in what is ultimately a conversation about costs, profits & sustainability.

But since you're bringing it up, then I think a more apt comparison is Google infamously shipping multiple competing messaging apps and eventually getting its ass kicked in the IM/messaging space, despite entering that market very early on, and at one point acquiring a critical mass. I've found https://arstechnica.com/gadgets/2021/08/a-decade-and-a-ha... to be an insightful historical analysis of that, including quotes such as "thanks to a decade and a half of nearly constant strategy changes, competing product launches, and internal sabotage, you can't say Google has a dominant or even stable instant messaging platform today" and "Google seems content only to spin up an innumerable number of under-funded, unstable side projects". It's not a 1:1 mapping, but it broadly captures my feelings about the Matrix/Element ecosystem.

> Well, that's why we wrote Element X. I get the impression that much of the unhappiness here and elsewhere in the comments comes from people disappointed in Matrix and Element based on bad experiences years ago. All I can suggest is giving the current stack a go - and then at least we can also fix issues which come up.

I use Element X and Element Web/Desktop on a daily basis. I was using Element since the Riot days, and Element X since November or so. I've tried a bunch of other clients over the years including recently (all broken in some way in my experience). I've installed Synapse and briefly ran my own homeserver a few years ago. I've experimented with Dendrite. I've tried to get a sizeable community & organization to switch to Matrix & Element.

Don't be so quick to discount me as a hater; I'm someone that admires your work and really wants you to succeed. Everything I say, I say with appreciation but also disappointment of seeing so much unrealized potential, and frustration due to having to use another (checks notes) 9 apps/platforms either to socialize or to engage with open source communities (your bread-and-butter).

Wishing you the best of luck regardless!

Timeline does not fit

Posted Mar 20, 2025 16:46 UTC (Thu) by paravoid (subscriber, #32869) [Link] (1 responses)

> (Threads should land in a few months, fwiw).

Sorry to slightly necromance this subthread, but I came across https://github.com/element-hq/element-x-android/issues/2831 today and got reminded of the response quoted above.

To summarize (my understanding of) the GitHub issue, Threads in Element X is going to wait until something called "Threads 2.0" gets to be defined as a protocol mechanism & API, then implemented across servers (at least Synapse) and all clients (at least Element X & Element Web). The Element representative on the issue is estimating the cost of this to be several hundred thousands of dollars. Plus the quote above estimated the timeframe of this to be a "few months". (Feel free to let me know if any of that is incorrect).

So AIUI this yet another very costly rewrite/reimplementation, in both money and time. Which, in turn, blocks the adoption of the new client (and thus its time-to-market), possibly tarnishing its reputation with new users that install it (as recommended), as well as delays the sunsetting of the old implementation, thus forcing the project to continue incuring the costs of both implementations.

I don't want to sound like a broken record, but it's a good example of the point I was making above w.r.t. the state of constant rewrite and second system syndrome that the Matrix ecosystem is IMHO plagued with.

(To be clear, I don't mean to be telling anyone how to run their business, and I say this with the hope that it is interpreted only in the context of "mainstream adoption" and "project sustainability".)

Timeline does not fit

Posted Mar 20, 2025 23:03 UTC (Thu) by Arathorn (guest, #101018) [Link]

I’m afraid you’re wrong. “Threads 2.0” isn’t a rewrite; it’s simply fixing some of the bugs in the current threads implementation (specifically around how notifs & threads interact). And it’s already largely funded and delivery is committed to the entity who funded it, hence giving the timeframe.

There’s no road here!

Posted Mar 12, 2025 14:32 UTC (Wed) by chexo4 (subscriber, #169500) [Link] (9 responses)

Everything I hear about Matrix’s protocol from people more knowledgeable than myself is horrifying. Cryptography nerds hate it, implementers hate it, and the UX sucks as an occasional user.

To me it feels like a fad.

There’s no road here!

Posted Mar 12, 2025 16:19 UTC (Wed) by marcH (subscriber, #57642) [Link] (4 responses)

What do these people recommend instead?

There’s no road here!

Posted Mar 12, 2025 17:19 UTC (Wed) by antiphase (subscriber, #111993) [Link] (3 responses)

It's entirely possible for something to be awful without there being a viable alternative.

There’s no road here!

Posted Mar 12, 2025 20:55 UTC (Wed) by marcH (subscriber, #57642) [Link]

https://wiki.c2.com/?PlanToThrowOneAway

Hi BitKeeper! And many others...

(BitKeeper as in "learn from mistakes and iterate", not as "awful")

There’s no road here!

Posted Mar 13, 2025 11:11 UTC (Thu) by intelfx (subscriber, #130118) [Link]

> It's entirely possible for something to be awful without there being a viable alternative.

Yes, but no.

Value judgments, just like scientific claims, must be falsifiable: if you claim something is awful, you should be able to show, exactly, what would *not* be awful under your value system. Then I can evaluate whether this not-awful alternative (whether it does or does not exist) would be viable and feasible under *my* value system, and based on that, draw a conclusion on whether this value judgment is worth listening to.

Alternatives to something awful

Posted Mar 13, 2025 11:35 UTC (Thu) by farnz (subscriber, #17727) [Link]

Note that the alternatives don't have to be practical implementations (and thus can be non-viable for now); it's reasonable to say that (for example) ETSI IMS is a better protocol than Matrix, since it does foo, bar and quux better than Matrix, while supporting screen sharing, instant messaging (RCS), voice calls and video calls.

That's not a viable alternative to Matrix, since there's no simple way to run your own IMS setup (at the moment - the nice folk who team up at osmocom are almost certainly going to work on this for VoLTE and VoNR). But you can look at it and see why someone making that suggestion thinks that IMS does foo, bar and quux better - and come to a useful conclusion about why they'd think that way.

There’s no road here!

Posted Mar 12, 2025 23:26 UTC (Wed) by Arathorn (guest, #101018) [Link] (2 responses)

> Everything I hear about Matrix’s protocol from people more knowledgeable than myself is horrifying. Cryptography nerds hate it, implementers hate it, and the UX sucks as an occasional user.

It's certainly true that Matrix attracts a lot of hate, especially from uninformed folks who parrot what they hear others saying.

In practice, there is one major outstanding issue on the cryptography, which is that the server controls the membership of the conversation. So, if Alice is in a conversation with Bob, the server could puppet Alice's account to invite Charlie into the room. When doing the first iteration of Matrix's E2EE, we considered this acceptable, given Alice and Bob would be able to see the unexpected user Charlie being invited and joining and react appropriately. Fixing this is challenging in a decentralised environment, but there are at least two different approaches under way to address this (MSC3917 and MSC4256). However, it certainly upsets some cryptographers.

In terms of implementer hate: there seem to be a lot of successful independent implementations out there if people hate it so much. Aside from Element's Rust and JS stacks, you have the full Golang stack from Beeper; the full Dart/Flutter stack from FluffyChat; the full C++ stack from Nheko; the React Native stack from unomed etc. Now, the spec isn't perfect: the use of Canonical JSON causes problems, State Resolution is fragile and hard to understand; there some warts around how fallback representations of messages are handled. But I'm unconvinced that a handful of warts undermines the whole protocol, even if it makes for easy grounds for complaint.

In terms of the UX sucking as an occasional user: what client are you talking about? Each one has totally different UX; some suck; some don't. The common failure mode is that people either judge based on the legacy Element apps - either from a bad experience years ago, or by using them now without realising that for the last 2 years all the effort went into writing Element X. If you still think Element X's UX sucks, then *please* let us know details - because huge amounts of effort have gone into ensuring it has great usability.

In terms of Matrix being a fad: well, we've been at it 10 years; some people like it and use it, and it continues to grow. It's not perfect, but it's been steadily improving, and my hope is that it will eventually get mainstream, despite all the hate :)

Element X issues

Posted Mar 13, 2025 0:33 UTC (Thu) by fraetor (subscriber, #161147) [Link] (1 responses)

I tried to use the Element X app from F-droid at FOSDEM, but I got stopped at the first hurdle, as my matrix.org login details were rejected. On the regular Element app I could happily sign-in with GitHub and be off to the races, but this wasn't an option with Element X.

Is this something that will be coming with the new authentication service, and I just jumped the gun a bit on using it?

Element X issues

Posted Mar 13, 2025 8:12 UTC (Thu) by Arathorn (guest, #101018) [Link]

Yup. Migrating all ~50M matrix.org users to MAS efficiently has taken a while, and is now blocked on the OIDC MSCs being approved for the spec. We’re hoping that will happen in the next 1-2w and then Element X will be usable by folks there using social logins.

There’s no road here!

Posted Mar 13, 2025 9:48 UTC (Thu) by vasvir (subscriber, #92389) [Link]

This is unnecessary harsh in my opinion.

I have used element in small teams 3-4 and it works ok for my use cases.

It doesn't behave like a VM in a tab like slack or Teams and group video conference is ok,

Really small replies - avoid the email - small files - small copy paste snippets it was liberating for me. The same is true for the other solutions but element feels less bureaucratic. For example Teams tries to organize and compartmentalize everything, Slack has threads that I will forget where they are anyway. Thanks but no thanks. Chat is an ephemeral thing. Element has threaded replies too but they do not fell like Kafka himself designed them.

For mobile use, Element does not always show the notifications. I think this is a feature - especially if I had seen them in the desktop but generally the app does not feel that it drains my battery like the other guys.

I can understand that there are pet peeves left and right but the concept of a universal decentralized protocol is something nice to at least dream on.

Disclaimer: I am in no way affiliated with Matrix or Element - just a not unhappy user.

HOWTO sponsor and run an open-source foundation

Posted Mar 12, 2025 17:55 UTC (Wed) by marcH (subscriber, #57642) [Link] (3 responses)

> The second failure mode is that a government is willing to put public money toward open-source feature development, but not toward maintenance or support fees. [...] Licenses for things like Adobe Acrobat or Microsoft products are in the billions of Euros per year for government agencies, [...] Some organizations, such as the Center for Digital Sovereignty (ZenDiS), do get it right in Hodgson's book. [...] Hodgson said that the simple answer is that organizations buying a commercial Matrix deployment should also mandate that the upstream project is funded by buying that upstream's products. He suggested that organizations should "only buy from people who are actually going to fund upstream maintenance" and normalize paying for open-source products as much as they pay for proprietary ones.

Yes, professional matrix users should absolutely prioritize the consultants who are not free-riding but contributing upstream. So where to find these consultants? I went to https://matrix.org and I struggled. Eventually I found them on the "Donate" page, which apparently doubles as a "Thank you" page. "Donate" is probably not where you click when you look for professional services. That Donate page has a long list with different types of "members" and it does not say which ones offer what if anything. I doubt Thunderbird sells Matrix services.

On https://www.linuxfoundation.org/ the sponsors are literally in the middle of the front page.

Much better: this is really the page that matrix.org is missing: https://zephyrproject.org/ecosystem-vendor-offerings/

> This has been "pretty controversial, but it seems to be working out for them [BlueSky]" in that they are effectively smuggling a decentralized protocol under the guise of a centralized communication network.

Good realization, better late than never. In the very same way, the matrix.org site and matrix communication in general should try to "smuggle a decentralized protocol" under the guise of promoting the consulting companies that fund upstream. Someone good at that sort of promotion would probably be also better at managing priorities, which sounds like this has been the top issue. It does not have to be a full time job.

The role descriptions at https://matrix.org/foundation/about/ do not talk about business much.

Maybe get in touch with other, more successfully sponsored foundations for advice? Advice not just about funding but other aspects of running an open-source foundation too, why not.

> Hodgson said that "we assumed that somebody would leap out of the audience" to offer funding for that work, but a year later nothing has happened.

I don't know whether this comment was 1st or 2nd degree but I think it's very telling either way.

HOWTO sponsor and run an open-source foundation

Posted Mar 12, 2025 23:49 UTC (Wed) by Arathorn (guest, #101018) [Link]

> > Hodgson said that "we assumed that somebody would leap out of the audience" to offer funding for that work, but a year later nothing has happened.

> I don't know whether this comment was 1st or 2nd degree but I think it's very telling either way.

It was 1st degree. It was also a bit of an oversimplification: one very large organisation did actually leap out of the audience to offer to fund PQXDH in Matrix, which meant we didn't pursue other options. However, they fell through in the end as they decided as they couldn't fund it as open source, because that would mean that their competition would have access to it.

Which I guess is telling in an entirely different way.

HOWTO sponsor and run an open-source foundation

Posted Mar 15, 2025 10:30 UTC (Sat) by jnareb (subscriber, #46500) [Link] (1 responses)

>> This has been "pretty controversial, but it seems to be working out for them [BlueSky]" in that they are effectively smuggling a decentralized protocol under the guise of a centralized communication network.

Do they? With a single implementation, is it really a decentralized network? They promise decentralization and federation, but...

That is why Free Our Feeds project exists: https://freeourfeeds.com/ to create an entire ecosystem of interconnected apps and different companies.

HOWTO sponsor and run an open-source foundation

Posted Mar 18, 2025 1:22 UTC (Tue) by Arathorn (guest, #101018) [Link]

i rest my case ;)

What is the use case for decentralised messaging?

Posted Mar 13, 2025 0:25 UTC (Thu) by fraetor (subscriber, #161147) [Link] (35 responses)

I've lightly used matrix, but I've always slightly stuggled to find the use case for its decentralisation.

Most of the time when I'm doing real-time communication I'm interacting with a specific community, which makes me think that a self-hostable centralised model is a better design, as it avoids the complexity of decentralisation. Think things like IRC, Mattermost or Zulip.

I guess these centralised services don't cater for the direct message/small group chat need, but in that case you can use Signal or WhatsApp, as the switching cost is low when you only need to coordinate with a few people, or just email if you want something that works.

What is the use case for decentralised messaging?

Posted Mar 13, 2025 2:15 UTC (Thu) by Cyberax (✭ supporter ✭, #52523) [Link]

> I've lightly used matrix, but I've always slightly stuggled to find the use case for its decentralisation.

It's very useful for governments and large companies. This way, individual groups with different requirements can still exchange messages.

What is the use case for decentralised messaging?

Posted Mar 13, 2025 11:12 UTC (Thu) by kpfleming (subscriber, #23250) [Link]

(Disclaimer: I've been an avid Matrix user and support for many years)

I find the decentralized features to be incredibly valuable: ignoring the bridged chats currently visible in my Element client, I've got chats open for a number of communities - Tusky, Jellyfin, Matrix, Mautrix Bridges, Embassy, Vaultwarden, systemd, zrepl, Forgejo, and others. After joining those rooms/spaces, I don't have to care where those rooms 'live' at all, they are all accessible using one client with one identity that I control. I've also created rooms for a few of my own open source projects, and don't have to manage a server with accounts for people other than myself, I can just post a link to a room I created on my server and any Matrix user can access it.

If that was 8+ Discord 'servers', or Zulip/Mattermost 'servers', or any other community-specific services, I doubt I'd participate in all of them (especially the lower-volume ones). I do have a Matrix-Discord bridge in place for a few more communities, and in that case I'm actually thankful that Discord is centralized as I only have to run one bridge, not one for each community.

What is the use case for decentralised messaging?

Posted Mar 13, 2025 13:14 UTC (Thu) by jzb (editor, #7867) [Link] (31 responses)

"but I've always slightly stuggled to find the use case for its decentralisation"

As someone who has to dip in and out of different community chat systems to do my job, I find the decentralization to be a great feature. I have one Matrix account. I can sign into rooms for Fedora, GNOME, FOSDEM, and so on with one account. In the past year, though, I've had to go through sign up / sign in hassles for quite a few Discord, Slack, and Zulip instances. And, of course, in my personal life I have some folks I communicate with mostly via texting, some via Signal, some via Slack...

It has its uses, but if you use Matrix in an organization in place of Slack or something, I can see how it wouldn't be immediately obvious if you only use Matrix in that one context. If the Matrix folks do manage to hit the mainstream, though, it may become more apparent why decentralization is beneficial. Trying to shepherd my friends and family to a single messaging system hasn't worked so far. It'd be great if all of those methods were using the same protocols and I could just use one client to communicate with everybody.

What is the use case for decentralised messaging?

Posted Mar 13, 2025 15:15 UTC (Thu) by excors (subscriber, #95769) [Link] (30 responses)

It sounds like this is more about federation, not decentralisation?

Fully centralised services can provide the same feature: I have one Discord account that's signed in to a dozen different communities, with millions more joinable within seconds.

It is annoying when other communities are spread across Matrix/Discord/Slack/etc with separate accounts per platform, and everyone switching to Matrix would solve that, but everyone switching to Discord would also solve that. (And both outcomes are equally implausible, since they have pretty different feature sets and use cases beyond the basic chat functionality). Fragmentation seems like an orthogonal problem to centralisation.

I think the contrast here is with non-federated decentralised protocols like IRC (and Zulip?), where every community might have its own server with its own independent and slightly-incompatible NickServ to authenticate with, which is the worst model. But federation and centralisation can both solve that.

What is the use case for decentralised messaging?

Posted Mar 13, 2025 15:36 UTC (Thu) by fraetor (subscriber, #161147) [Link]

This thread is makes sense. When I use these decentralised but non-federated services I generally sign in with OIDC social sign in and then stay up to date with them via email notification features. But it that case I am using email as my federation layer.

Matrix provides that federation layer natively within the protocol, and therefore simplify communication overall.

What is the use case for decentralised messaging?

Posted Mar 13, 2025 22:35 UTC (Thu) by marcH (subscriber, #57642) [Link] (28 responses)

> It sounds like this is more about federation, not decentralisation?

Federation is a particular case of decentralization so I'm confused by the word "not".

> Fully centralised services can provide the same feature: I have one Discord account that's signed in to a dozen different communities,...

They can't because of what you wrote in the next line: you can never get _everyone_ to join a private, centralized service.

> but everyone switching to Discord would also solve that. (And both outcomes are equally implausible,

No, they are not "equally implausible" because they are not in the same "class".

> since they have pretty different feature sets and use cases beyond the basic chat functionality)

There is much more than a "feature set" difference. Discord is a service and business whereas Matrix is a _protocol_ like email. So it is actually plausible that everyone is reachable using Matrix (or similar) some day in the future; same as email and SMS/RCS are near-universal today.

What is the use case for decentralised messaging?

Posted Mar 14, 2025 1:13 UTC (Fri) by NYKevin (subscriber, #129325) [Link] (27 responses)

> same as email and SMS/RCS are near-universal today.

Well, you say that...

SMS and RCS are by no means universal. I mean, they probably do work to contact the average person (assuming they have a mobile phone), but whether the average person actually uses them in practice is a much thornier question, and depends a lot on which part of the world we're talking about. Plenty of people use centralized services like WhatsApp and iMessage in lieu of SMS or RCS.

Email is at least nominally federated, but as we have discussed in past threads, it has become comically difficult to operate your own mail server (that can successfully send email to and receive email from arbitrary addresses, where "success" implies that a human actually sees the email or at least its subject line). But at least the big companies' implementations can mostly interoperate with each other, which is more than we can say for chat.

As can be seen from the giant thread of people arguing over XMPP, IRC, and various other federated chat technologies, we've been trying to make federated chat happen for a really long time. I don't think it would be entirely fair to brand IRC a failure, but these days I think it is fair to say that it's a niche technology at best. While IRC does have pain points that would be unacceptable to the average end user (nobody wants to know or think about this funky NickServ thingy that keeps sending me weird private messages), I think it is becoming increasingly obvious that chat does not generate the same scale of network effects as email or HTTP, and therefore cannot justify federation purely for its own sake.

In retrospect, this should be obvious. The optimal size of a single chat room is no more than a few dozen people or so (ignoring lurkers and anyone else who's mostly or entirely inactive for extended periods of time). Users don't *want* a chat system that has everyone on it, unless the "everyone" in question is mostly in other rooms where I don't have to see or interact with them. But then what's the point? If you want to message a person individually, you've already got two perfectly good ways of doing that (email and SMS/RCS/some-centralized-thing). What concrete, practical problem does federated chat solve?

What is the use case for decentralised messaging?

Posted Mar 14, 2025 2:35 UTC (Fri) by marcH (subscriber, #57642) [Link] (25 responses)

You're mixing up "universal" with "popular"and other things. Universal means you can use with almost anyone. It may be feature limited, it may be slow, it may even be expensive (think SMS ripoffs in some countries at some points in time) and it may suck in a number of other ways but it is standard, does not depend on any business and can reach almost anyone.

What is the use case for decentralised messaging?

Posted Mar 14, 2025 12:34 UTC (Fri) by kleptog (subscriber, #1183) [Link] (24 responses)

> can reach almost anyone.

If only. If you only try to message people in the same country and there's no roaming involved, then yes it works pretty well. But international SMS is a clusterf*ck, it suffers from all the issues of email and so messages get killed due to spam filtering and other filtering. We don't even bother trying SMS to India for example, it never gets through anyway.

So I guess it's universal in the way that email is universal. You must have an account and not run into vague invisible restrictions.

What is the use case for decentralised messaging?

Posted Mar 14, 2025 16:46 UTC (Fri) by marcH (subscriber, #57642) [Link] (23 responses)

Yes of course: "decentralized" means much harder to deal with spam, scams and other security challenges. That's definitely one of the ways decentralized systems "suck more".

The initial designs of Email and SMS made the huge mistake of not considering this enough, it was only bolted on much later. Yet there are many places and operators where they are more than usable now. That is, if you abandon the naive idea of random systems just showing up without any sort of registration and starting to send email, text or other messages, which makes them 100% indistinguishable from spammers. "Decentralized" should not imply "Wild West", there are middle grounds and trade-offs.

"Wild West" which has apparently... moved back East nowadays?
https://www.theverge.com/2022/6/1/23150243/google-rcs-ads...

But new, decentralized kids like Matrix have the benefit of hindsight. So, we should still not expect perfection but much better than the levels of email or SMS spam. What levels of spam do current Matrix users experience?

PS: I can't shake this analogy with democracy and dictatorships, sorry... In democracies with more "decentralized" power, you get "random" crime (random text scams) whereas in more "centralized" dictatorships, crime tends to be... much better centralized, structured and organized ("if it's free, you are the product"). Predictability is very important, it could be why some people prefer dictatorships.

What is the use case for decentralised messaging?

Posted Mar 14, 2025 19:06 UTC (Fri) by Cyberax (✭ supporter ✭, #52523) [Link] (22 responses)

There was no "design" in SMS. It was meant as a debug feature for the control plane of cellular protocols. It just happened to be popular, so billing and other features (MMS to move large data out of the control plane) were bolted on later.

RCS has no such excuse. It was designed from scratch to be unusable.

What is the use case for decentralised messaging?

Posted Mar 15, 2025 0:52 UTC (Sat) by marcH (subscriber, #57642) [Link] (21 responses)

> There was no "design" in SMS.

Good reminder, thanks.

> RCS has no such excuse. It was designed from scratch to be unusable.

I wonder what you mean.

RCS isn't perfect, it is for sure pretty basic compared to its "competitors" and I have zero idea how it works behind the scenes but from a naive user perspective it feels perfectly "usable".

Also, it's been a MASSIVE progress in the USA where teenagers and more have been excluding and/or pressuring their peers to buy an iPhone to avoid SMS and "green bubbles" (cause we apparently don't have enough billionaires and oligarchs yet). I suspect some still do that because iMessage still does more; but RCS did relieve a lot of that pressure.

What is the use case for decentralised messaging?

Posted Mar 15, 2025 1:35 UTC (Sat) by Cyberax (✭ supporter ✭, #52523) [Link] (20 responses)

> RCS isn't perfect, it is for sure pretty basic compared to its "competitors" and I have zero idea how it works behind the scenes but from a naive user perspective it feels perfectly "usable".

As a third party, you can't reliably use RCS without making agreements with EVERY carrier. It was true in the SMS world (and still is, to some degree), but there are providers like Twilio that do that integration for you. And given the SMS simplicity, the end result is fairly vendor-independent. Not so much with RCS. As an app developer, you can't directly use the RCS protocol, and vendor-specific APIs are all different.

Even for users, the situation is similar. Carriers are not exempt, and they have to set up gateways to exchange the RCS messages with each other. There's no guarantee that an RCS message from T-Mobile USA can reach Airtel in India. And that's not a hypothetical scenario: https://support.google.com/messages/thread/325910694/i-ca... RCS messages can (and do!) just silently fail.

And there are many, many, many other faults.

RCS

Posted Mar 15, 2025 4:32 UTC (Sat) by marcH (subscriber, #57642) [Link] (9 responses)

> As a third party,...

I'm aware there's a push to "sell" RCS to businesses but as a user I'm not sure I care much. On the contrary, less third-party success could mean less spam?

> ... you can't reliably use RCS without making agreements with EVERY carrier.

Interesting, is that a technical or a business "choice"?

> As an app developer, you can't directly use the RCS protocol, and vendor-specific APIs are all different.

Mass RCS adoption is fairly new, so that sort of API fragmentation is not too surprising. Things like these always consolidate after a while.

Thanks, this is interesting as someone working in IT and I would genuinely like to know a bit more about these "many, many" other faults but I'm afraid I don't care much _as a plain user_. As a user, it's a massive upgrade compared to SMS, groups work and I don't need to worry about costs anymore when chatting with people abroad (I never need to text anyone in India). If I ever run into some issue like the ones you describe, I'm confident it will fall back on SMS. RCS basic but it's free, vendor-independent and it's "universal" in all the countries I care about. If some other countries can't pull it off, well too bad for them. As long as there is a standard and no vendor-lock in, it must be their fault and it's universal enough for me.

> RCS messages can (and do!) just silently fail.

As opposed to SMS, RCS has acknowledgments enabled by default, nice.

> And that's not a hypothetical scenario: https://support.google.com/messages/thread/325910694/i-ca...

Come on, this post has a single upvote and two comments right now. RCS has billions of users.

RCS

Posted Mar 15, 2025 4:47 UTC (Sat) by Cyberax (✭ supporter ✭, #52523) [Link] (5 responses)

> I'm aware there's a push to "sell" RCS to businesses but as a user I'm not sure I care much. On the contrary, less third-party success could mean less spam?

Nope. Spammers can just get agreements with individual telecoms. They don't care about reaching _everyone_, they just need to reach _enough_ people. And telecoms gladly sell out their customers.

I want to use RCS for things like monitoring and alerting for my systems, and I can't do that easily.

> Interesting, is that a technical or a business "choice"?

It's hard-coded in the standard, as it was developed by (you guessed it) telecoms.

> Mass RCS adoption is fairly new, so that sort of API fragmentation is not too surprising. Things like these always consolidate after a while.

It'll take years, and the end result won't be pretty. Vendor lock-ins with rent-seeking.

It's already there. An app developer for an Android or iOS device can't implement RCS because this needs privileged communication with the baseband (you need your SIM card to sign authentication tokens). And Google even disables RCS on jailbroken phones.

> As opposed to SMS, RCS has acknowledgments enabled by default, nice.

Well, I guess it's at least some consolation when you can't send messages.

> Come on, this post has a single upvote and two comments right now. RCS has billions of users.

It happened to me, several times, when texting internationally. I just got a random message from Google as an illustration.

RCS

Posted Mar 16, 2025 23:31 UTC (Sun) by marcH (subscriber, #57642) [Link] (4 responses)

> I want to use RCS for things like monitoring and alerting for my systems, and I can't do that easily.

Forgot to ask: why try to use RCS for that if it sucks so much? You sounded like you spent a fair amount of time trying; more than a quick look. Is there no alternative? (besides SMS of course). It's a pretty specific need, for instance you don't need groups. So there should be some IP-based alternatives...?

One of the (very rare) advantages of SMS over other notification systems was: SMS can get through even without data access. That advantage is gone with RCS: it needs data access.

RCS

Posted Mar 16, 2025 23:52 UTC (Sun) by Cyberax (✭ supporter ✭, #52523) [Link]

Mostly out of curiosity, and to get some experience with what is supposed to become the next global communication standard. I wanted to make a fairly simple application: monitor the state of the system, and when an alarm threshold is breached, send a message with a graph, and two buttons to acknowledge the alert, or forward it up the escalation chain.

> That advantage is gone with RCS: it needs data access.

RCS is supposed to work even if the general data access is not available. Kinda like the classic MMS that can use separate billing and roaming arrangements.

> So there should be some IP-based alternatives...?

Oh, for sure. I'm using Telegram for a similar purpose.

Data access and SMS

Posted Mar 17, 2025 10:31 UTC (Mon) by farnz (subscriber, #17727) [Link] (2 responses)

SMS could only get through in places where RCS couldn't on GSM (2G, 2.5G) networks; on 3G and later network standards, SMS is normally carried in the same way as packet data.

Both RCS and SMS share one advantage over Internet services, though; they can be carried on dedicated data bearers (along with voice in 4G and 5G networks), rather than a general "internet" bearer, as a result, they can get through when the provider is struggling with Internet data routing, and can be prioritised above the local "data hogs".

Data access and SMS

Posted Mar 17, 2025 16:55 UTC (Mon) by marcH (subscriber, #57642) [Link] (1 responses)

> they can be carried on dedicated data bearers

Thanks, it is very good to know that RCS kept a bit of an advantage there. This is especially useful in temporarily congested areas (festivals, etc.) where the network is not designed for the current load and even more useful when you have a cheaper and lower priority virtual operator - assuming they benefit from that too.

Except... you wrote "can", which is worrying :-) Well, if it really is a time-sensitive message in a problematic area, not much harm trying SMS/RCS first in any case...

Data priority in 4G (and 5G networks) - everything since LTE, basically

Posted Mar 17, 2025 17:06 UTC (Mon) by farnz (subscriber, #17727) [Link]

Once you get to 4G (LTE) and later standards, it's all packet data for everything. The only distinction between a WhatsApp message and an SMS is that SMS is carried over the IMS bearer, while WhatsApp is carried over the general Internet bearer, but both bearers are just ways of carrying packet data between your handset and the telco (and in the case of the IMS bearer, that'll be an IPv6 network).

It's then up to the telco to decide who gets priority when - they can, for example, choose to prioritise a heavy spender's Netflix over SMS (or RCS) to a user of a cheap MVNO, or to prioritise a card terminal's data over all other users.

And note that this is true of SMS in 3G as well, since that's also a packet data service; 3G still supported circuit switched services as well, but they were only used for voice. It's only GSM networks where SMS had a guaranteed advantage even if your telco didn't pay attention, because it literally filled in some otherwise "empty" fields in signalling traffic.

RCS

Posted Mar 15, 2025 9:32 UTC (Sat) by Wol (subscriber, #4433) [Link]

> > As a third party,...

> I'm aware there's a push to "sell" RCS to businesses but as a user I'm not sure I care much. On the contrary, less third-party success could mean less spam?

The problem with that approach is that "less third-party success" is likely to equate to "sank without trace". I don't know what RCS is, but I get the impression that it's business-driven, so that is especially likely to be the case.

Cheers,
Wol

RCS

Posted Mar 15, 2025 20:47 UTC (Sat) by mathstuf (subscriber, #69389) [Link] (1 responses)

> I don't need to worry about costs anymore when chatting with people abroad (I never need to text anyone in India).

To be fair, in this specific case at least, you'd be far more likely to be using WhatsApp anyways given its network effects. The free video calling is critical for communicating with family overseas.

RCS

Posted Mar 16, 2025 15:51 UTC (Sun) by marcH (subscriber, #57642) [Link]

Video calls are much rarer than text messages with far fewer contacts and much less likely to require some "universal fallback". This is a separate topic. This being said, some neutral industry standard would not hurt either.

Having compared the two a fair bit, Google's backend for voice and video calls tends to have better latency and better handover than Meta's. Too bad Google lost all users by changing the app and other front end names all the time.

https://www.theverge.com/2021/6/21/22538240/google-chat-a...
https://arstechnica.com/gadgets/2019/04/googles-constant-...

Right now the most convenient way to make a Google voice or video call seems to be through gmail. Relatively well hidden! No doubt they will have moved it somewhere else in 6 months and again 6 months later.

What is the use case for decentralised messaging?

Posted Mar 15, 2025 14:20 UTC (Sat) by raven667 (guest, #5198) [Link] (7 responses)

Yeah, on my Google Fi Pixel 8a I had to turn RCS off because 1) the Google Messages app doesn't integrate the shared message history between SMS/RCS or allow use from the web so I'd lose my archive and 2) can't reliably communicate with iPhone users on AT&T. My Mother in Law has the same phone and service and was going mad missing texts from her friends trying to meet up for going out and such, falling back to SMS resolved all the issues because it's the lowest common denominator that "just works". In my experience even MMS has problems because it requires a working IP stack and web services, and SMS has fewer and more reliable service dependencies.

What is the use case for decentralised messaging?

Posted Mar 15, 2025 15:57 UTC (Sat) by marcH (subscriber, #57642) [Link] (6 responses)

> the Google Messages app doesn't integrate the shared message history between SMS/RCS

Weird, they're in the same history for me. Maybe you're talking about groups?

> or allow use from the web

Google messages does have a web interface compatible with RCS. However your phone needs to be online because unlike SMS, RCS messages are not stored in the cloud due to E2EE. So it works the same as web.whatsapp.com and others.

> falling back to SMS resolved all the issues because it's the lowest common denominator that "just works".

I've seen Google Messages automatically falling back on SMS when people were not online and there was no need to turn off RCS.

I'm sorry about your mother in law but these were either bugs and glitches or "PBKCs", not "features".

What is the use case for decentralised messaging?

Posted Mar 15, 2025 16:27 UTC (Sat) by raven667 (guest, #5198) [Link]

> I'm sorry about your mother in law but these were either bugs and glitches or "PBKCs", not "features".

But that's my point, it's a little chaotic and unreliable due to the remaining bugs and glitches between service and phone vendors, and non-computer people do not have the patience to accept that level of unreliability, there is no sense of "this tech is neat and cool" to offset the "I missed a date with a friend" frustration.

What is the use case for decentralised messaging?

Posted Mar 15, 2025 22:31 UTC (Sat) by Cyberax (✭ supporter ✭, #52523) [Link] (4 responses)

> Google messages does have a web interface compatible with RCS. However your phone needs to be online because unlike SMS, RCS messages are not stored in the cloud due to E2EE. So it works the same as web.whatsapp.com and others.

There's nothing preventing the E2EE messages from being stored in the cloud. The provider will just see an opaque encrypted blob.

That's how WhatsApp works, btw.

What is the use case for decentralised messaging?

Posted Mar 16, 2025 2:55 UTC (Sun) by marcH (subscriber, #57642) [Link] (2 responses)

The problem is not storage, i think it's decrypting them at multiple endpoints while preserving E2EE. WhatsApp requires the phone to be online. Before RCS, Google cloud SMS do not.

What is the use case for decentralised messaging?

Posted Mar 16, 2025 10:18 UTC (Sun) by Cyberax (✭ supporter ✭, #52523) [Link]

It's still doable. You won't be able to message to entirely new contacts while offline, but it's perfectly possible to send messages to existing contacts/groups. Matrix supports it.

What is the use case for decentralised messaging?

Posted Mar 16, 2025 11:07 UTC (Sun) by Wol (subscriber, #4433) [Link]

What about those people who DON'T WANT the phone on-line?

I really don't appreciate topping up my familys' phones (which they hardly ever use) only for the data to drain the top up in a few weeks while the phone is sitting unused in a drawer!

And if you configure the phone "no mobile data, wifi only" then it's unusable when they need it most - when they go out!

Cheers,
Wol

What is the use case for decentralised messaging?

Posted Mar 18, 2025 10:41 UTC (Tue) by paulj (subscriber, #341) [Link]

An opaque encrypted blob of the actual text, if you believe Facebook. They have the meta-data - who is sending to whom, from where, and when - in the clear.

What is the use case for decentralised messaging?

Posted Mar 15, 2025 14:37 UTC (Sat) by kleptog (subscriber, #1183) [Link] (1 responses)

> As a third party, you can't reliably use RCS without making agreements with EVERY carrier.

Which I guess explains why nobody cares about RCS in Europe. Europe has over 200 actual mobile carriers (excluding all the virtual carriers which use someone elses network). Anything that requires mobile carriers to actually make agreements with each other is an automatic non-starter. For comparison, the USA has only 5(!) carriers.

For example, right now, Vodafone in the Netherlands supports RCS on Android via Google, but there's no support for iPhones. This is something that has compete in a messaging space that is basically a solved problem. Solved by Skype, WhatsApp, Signal, Threema, etc more than a decade ago.

Even aside from the lack of E2EE as standard. The fact people still use SMS for personal communications must be the wet-dream of many spy agencies.

There is a case for decentralised messaging, but the telecommunication companies are not going to be the ones to deliver it.

RCS

Posted Mar 15, 2025 17:12 UTC (Sat) by marcH (subscriber, #57642) [Link]

> Europe has over 200 actual mobile carriers (excluding all the virtual carriers which use someone elses network). Anything that requires mobile carriers to actually make agreements with each other is an automatic non-starter.

I've been using RCS across the atlantic ocean just fine, not too bad for a "non-starter". As Cyberax wrote above, these hundreds of P2P agreements already existed for SMS, so extending them to RCS did not seem to have been a major stretch. Hundreds of P2P agreements are also needed for roaming BTW.

I'm sure there are RCS gaps and holes but it has near 100% reach in all the countries I care about so it universal enough for me - much more than WhatsApp, iMessage or else (again: universal != popular). Other countries and operators can and are gradually joining the show.

> This is something that has compete in a messaging space that is basically a solved problem. Solved by Skype, WhatsApp, Signal, Threema, etc more than a decade ago.

Funny how "universal messaging" is solved by... several, different "universal" solutions! XKCD 927?

RCS does not "compete" with WhatsApp, iMessage etc., no more than SMS did because it's an inferior, universal _fallback_ when you want to communicate with someone who did not install your favorite app. So instead of having to install 5 or 6 different apps on your phone, you can install only one and then fallback to RCS when needed.

As a universal fallback, SMS sucked _horribly_. RCS sucks *much* less, so it is a major progress. Sharing a laundry list of real RCS flaws and more debatable anecdotes is not going to change the fact that it sucks less than SMS. I've actually been impressed by the small number of bugs and glitches considering how new it is and how much it has to scale.

> There is a case for decentralised messaging, but the telecommunication companies are not going to be the ones to deliver it.

Agreed, and in fact Google and Apple delivered RCS, not the telcos. No software to ever expect from the latter. I sincerely hope we get rid of RCS in the future, replaced by either Matrix or something like it. Anything better. But the universal, instant messaging system of the future is useless in the present. So in the present, I'll keep enjoying RCS as a universal fallback - cause that's all there is and it's so much better than SMS.

What is the use case for decentralised messaging?

Posted Mar 14, 2025 7:36 UTC (Fri) by Wol (subscriber, #4433) [Link]

> SMS and RCS are by no means universal. I mean, they probably do work to contact the average person (assuming they have a mobile phone), but whether the average person actually uses them in practice is a much thornier question, and depends a lot on which part of the world we're talking about. Plenty of people use centralized services like WhatsApp and iMessage in lieu of SMS or RCS.

"assuming they have a mobile phone"

Lets change that. Assuming they *know* *how* *to* *use* a mobile phone (ie all the functionality beyond just using it as a phone).

You'd be surprised how many people don't. As I keep railing, the elderly and disabled all too often fall into exactly that category. Even something as simple as SMS - they've changed my app and deleted most of the functionality I considered "necessary" beyond the absolute basics! To me it's extremely annoying, to the people around me it could be a deal-breaker.

Cheers,
Wol

What is the use case for decentralised messaging?

Posted Mar 13, 2025 14:21 UTC (Thu) by marcH (subscriber, #57642) [Link]

> think that a self-hostable centralised model is a better design, as it avoids the complexity of decentralisation.

Less complexity on... the server side. Pushing it to every single user and forcing them to deal with countless accounts, passwords, user interfaces, OS and other compatibility issues and what not. Did this never bother you at all?

> or just email if you want something that works.

The answer was in the question :-)

IETF standard?

Posted Mar 14, 2025 9:01 UTC (Fri) by debacle (subscriber, #7114) [Link]

> Matrix is an open standard for a decentralized communication protocol.

What about their plan to get Matrix endorsed by the IETF?