No, Cloudflare's Matrix server isn't an earnest project¶

Yesterday, 2026-01-27, Cloudflare published a blog post announcing that they had built a Matrix homeserver that could run entirely on Cloudflare workers. This sounds amazing! Finally, serverless edge-computing for my chat protocol. In theory this brings great benefits, given Cloudflare's dominant global presence. It could even improve access, since lots of networks don't just blanket ban Cloudflare ranges. But, something far more sinister lies in wait.

Before anyone gets all hot and bothered, this post was written entirely in a personal capacity and views and opinions expressed in this post are purely my own and do not represent any other entity in any capacity. In short, all thoughts are my own.

Initial reception¶

At 15:07 UTC, @matthew:matrix.org (the CEO of Element) posted a message¹ in the Matrix weekly news room, #twim:matrix.org, linking to the Cloudflare blog, saying:

well, https://blog.cloudflare.com/serverless-matrix-homeserver-workers/ is interesting!

For context, links to interesting blogs and other materials do often get linked in this room, so this isn't abnormal. Usually, the TWIM room is also fairly low-traffic, receiving a few messages a week to post submissions for the weekly Matrix blog post (at https://matrix.org/blog), and occasionally a bit of chatter about entries before they're published.

It took a while for this message to get any attention - there was mostly silence, aside from a reaction at 15:11, until one of the TWIM editors, @kim:sosnowkadub.de commented at 15:13, highlighting that the Cloudflare blog post seemingly claimed that Matrix requires a $20/mo VPS to run, and that Cloudflare was "decentralisation-washing" (i.e. claiming to support decentralisation, while claiming that their monopoly does it better, more on that later), with comments from other room members further calling out seemingly false or otherwise absurd claims, such as @herkulessi:herkinf.de commenting, "If its goverments spying on you: YoU nEeD oUr MaGiC TLS, when they explain that they do terminate the TLS at the Worker (and therefor the worker can see the Traffic)"

@stratself:muoi.me's "i like how their entire postquantum feature is "just upgrade TLS" lol", and @tulir:maunium.net bringing light to their claim to using Tuwunel (a conduwuit/Conduit fork homeserver implementation), and @jade:ellis.link adding on that Cloudflare claimed Tuwunel used PostgreSQL and Redis (it does not, it uses rocksdb).

Overall, it looks like the initial reception of this was optimism met with educated skepticism.

Breaking down the Cloudflare blog post¶

The blog post was brought to my attention by a friend at 15:11 in a private room, which I saw at around 15:34. I was busy at the time, but I got around to reading the post at 15:40, and could immediately tell that this post was almost entirely AI generated. Why? Only a few days prior, I had been trying to figure out the story behind a sudden spike in stars on Continuwuity's GitHub mirror, and part of that involved market research, including SEO, ultimately meaning I ended up having a "chat" with Google's Gemini (and a few other LLMs on my way, but they all basically said the same things). A lot of claims in the Cloudflare blog post were almost 1:1 with claims I had read from Google Gemini. LLMs also love Tuwunel because of the "Enterprise" branding, which is presumably a keyword the CF blog author used. However, Tuwunel (which is a fork of the late conduwuit, itself a fork of Conduit) is rather new, so LLMs don't have an awful lot of training data. You know what they do have a lot of training data on though? Synapse! You know what homeserver implementation uses PostgreSQL and Redis? Synapse!

But we're getting ahead of ourselves here. Let's review some of the claims made by Cloudflare's blog post.

The Introduction¶

In one of their introductory paragraphs, they state:

But there is a "tax" to running it Traditionally, operating a Matrix homeserver has meant accepting a heavy operational burden. You aren't just installing software; you are becoming a system administrator. You have to provision virtual private servers (VPS), tune PostgreSQL for heavy write loads, manage Redis for caching, configure reverse proxies, and handle rotation for TLS certificates. It’s a stateful, heavy beast that demands to be fed time and money, whether you are sending one message a day or one million.

Almost none of this is true. "You have to provision virtual private servers (VPS)" is wrong, as you can run a Matrix server on almost anything. Some people in the Continuwuity community have even gotten our implementation running on some absurd hardware, like a PowerMac G5, and an Apple TV. There is absolutely no requirement for a cloud VPS, virtual machine, etcetera. I ran my own Synapse homeserver for about a year on a Raspberry Pi 4B, connected over WiFi 5, under my bed, in my bedroom, and it was absolutely fine. I also never had to tune PostgreSQL, although I do it now so I can marginally increase the performance of my server (but the kicker is, that's mainly because I have several write-heavy programs connected to my PG server). Redis is only required if you set up Synapse in polylith mode (with workers), but that isn't even necessary, and completely redundant if you deploy a different homeserver instead.

You also don't have to configure reverse proxies, as the blog claims - most Matrix homeservers are able to handle serving HTTP and TLS on their own.

The only statement here that is somewhat true is "[you have to] handle TLS". However, I feel like the difficulty of this is so negligible that it's not even worth mentioning, because:

1. Caddy is incredibly easy to configure², and automatically handles TLS certificates without any intervention required. It also means TLS terminates at your host rather than at Cloudflare, meaning there's less opportunity for prying eyes to see decrypted HTTPS content.
2. You will still need to handle TLS yourself anyway, unless you use Cloudflare in front of your domain and only want edge TLS (which is insecure, since that means the connection between Cloudflare and your origin is PLAIN TEXT!)

They then go on to say:

We wanted to see if we could eliminate that tax entirely.

Spoiler: We could. In this post, we’ll explain how we ported a complete Matrix homeserver to Cloudflare Workers. The result is a serverless architecture where operations disappear, costs scale to zero when idle, and every connection is protected by post-quantum cryptography by default.

This has little merit. I don't know much about Cloudflare's workers system, so I can't speak on the "operations disappear" - it might genuinely make running a service easier - but as an operator self-hosting 5+ Matrix server instances, I can tell you confidently the cost will not scale to zero when idle. There is no "idle". I serve over 15 million requests to my Matrix servers per week, most of that being server-to-server federation requests. How much would 15 million requests a week cost me with Cloudflare workers? Probably more than the £4/mo I pay Hetzner to host my ingress (which could be reduced to zero if I just port-forward at my house and run my ingress locally instead).

"From Tuwunel to Workers"¶

The first paragraph of this section is already full of demonstrably false information:

Our starting point was Tuwunel, a Rust-based Matrix homeserver designed for traditional deployments. PostgreSQL for persistence, Redis for caching, filesystem for media. Porting it to Workers meant questioning every storage assumption we’d taken for granted.

Tuwunel uses RocksDB, not PostgreSQL. RocksDB is a filesystem-local key-value database that excels at compression and speed, unlike PostgreSQL. Tuwunel forked from conduwuit, which itself only ever used RocksDB; conduwuit forked from Conduit, which at one point "supported" Sqlite, but was primarily also RocksDB, but more importantly, never at any point was PostgreSQL involved in this chain. Redis has also never been involved, and "[a] filesystem" is very loose considering an S3 FUSE mount works fine. There's also a claim later on that "Rust compiles to web assembly", which might be true, but Tuwunel certainly doesn't, and it turns out this is completely irrelevant anyway.

Oh, just a fun tidbit: the Tuwunel maintainers were not made aware of this Cloudflare project in any form until the blog post was shared in circles they're in. Make of that what you will.

"From monolith to serverless"¶

This entire section is basically just an advertisement for Cloudflare's workers service, I don't think there's actually much of substance here. There is, however, a lot of blatant misinformation.

We'll start off with their "Usage-based costs" point:

Traditional homeservers cost money whether anyone is using them or not. A small community server handling a few hundred requests per day still requires a typical VPS costing around $20/month running 24/7.

Workers pricing is request-based, so low-traffic homeservers cost just pennies. When usage spikes during active conversations, you pay for what you use. When everyone goes to sleep, costs drop toward zero.

I already mentioned in the previous section why this is complete rubbish. You can get away with one CPU core and 256 megabytes of RAM for a "small community" (although the definition of "small" and "community" differs and is not a valid metric).

Furthermore, Matrix is a very chatty protocol. There's efforts underway to reduce how much garbage is flying around the wires, but as it stands, it's still noisy. You will never have such low traffic that it will only cost "pennies" when you're charged by usage (but keep in mind that, despite serving nine figures monthly, I am yet to exceed 100GiB egress bandwidth of my 20TiB inclusive cap)

They then go on to advertise:

Built-in security: Matrix homeservers can be high-value targets: They handle encrypted communications, store message history, and authenticate users. Traditional deployments require careful hardening: firewall configuration, rate limiting, DDoS mitigation, WAF rules, IP reputation filtering.

We provide all of this by default. The Worker never sees attack traffic, because we filter it first. For a solo developer or small team, achieving this level of hardening on a Linux VPS is a full-time job. On Workers, it is the baseline environment.

This is just scaremongering to sell you something you don't need. Sure, some deployments like matrix.org might be high value targets, but that is because they have millions of monthly active users - you (probably) don't. Admittedly, setting up a server securely can be a chore that first-time admins should spend a decent amount of time researching, but Matrix only needs one port (443/TCP), so the firewall could just be a DENY * with ALLOW 443/TCP. Or, ufw allow 443/tcp. Regardless, definitely not "full-time job".

"Post-quantum protection without the complexity"¶

This entire section just yaps about TLS 1.3 with post-quantum keys which anyone can deploy without Cloudflare.

They also flash a fancy diagram and throw some more keywords in there before eventually saying:

The Worker terminates TLS, but what it receives is still encrypted — the Megolm ciphertext. We store that ciphertext in D1, index it by room and timestamp, and deliver it to recipients. But we never see the plaintext.

Which means all of this hullabaloo is basically meaningless since the content is still decrypted and presumably stored in a way that can easily be accessed in plain text by a process other than the server itself.

Also "we never see the plain text" is only true for end-to-end encrypted messages, which are then still vulnerable to store-now-decrypt-later attacks, just not over the wire.

"Two layers, independent protection"¶

More of a footnote than anything, but in this section they attempt to refute what I wrote above:

Here’s why this architecture matters: Even if Matrix E2EE is eventually broken by quantum computers, the message content was never transmitted in a quantum-vulnerable form. The TLS layer that carried the E2EE ciphertext was itself post-quantum secured.

But this is also meaningless, because if the megolm protocol is broken, all of that data is already at rest. And you know, "store now decrypt later", this would be the decrypt part. Doesn't matter if your transport layer is also encrypted at that point (since then all of your security relies on Cloudflare not intentionally or unintentionally providing the now decryptable payload data).

"Who sees what"¶

Any Matrix homeserver operator — whether running Synapse on a VPS or this implementation on Workers — can see metadata: which rooms exist, who’s in them, when messages were sent. This is inherent to operating the server. You’re the operator; you control the infrastructure.

Oh hey, we're talking about Synapse now! Took them long enough.

What no one in the infrastructure chain can see: message content. The E2EE payload is encrypted on sender devices before it ever hits the network. Cloudflare terminates TLS and passes requests to your Worker, but both see only Megolm ciphertext. Media in encrypted rooms is encrypted client-side before upload. Private keys never leave user devices.

The server processes ciphertext, not conversations. That’s true whether you’re self-hosting on bare metal or running on Workers.

This is dishonest at best. Encrypted events are only a fraction of the conversations you'll have on Matrix. Every single other event, including room state events (like your room name and topic!) and for some reason, reactions? are always plain-text and have to be stored as such so that servers can do some functions, such as full text search, relationship mapping and aggregation, and metadata population.

The data storage model¶

Cloudflare goes on to say that "D1 stores everything that needs to survive restarts and support queries: users, rooms, events, device keys. Over 25 tables covering the full Matrix data model." Thing is, 25 tables is nowhere near enough for Matrix, not if you want a homeserver that is fast and doesn't have to spend significant time doing roundtrips for more data as it finds it needs it.

Also,

D1’s SQLite foundation meant we could port Tuwunel’s queries with minimal changes. Joins, indexes, and aggregations work as expected.

As a reminder, Tuwunel uses RocksDB, a key-value database. It is structured NOTHING like a relational database.

They also said they removed foreign key constraints and enforce that at the application level since D1's eventual consistency was causing problems, which is hilarious, because I now have severe doubts about their data availability and reliability.

However, they then go on to say:

Some operations can’t tolerate eventual consistency. When a client claims a one-time encryption key, that key must be atomically removed. If two clients claim the same key, encrypted session establishment fails. Durable Objects provide single-threaded, strongly consistent storage

Which is funny, because didn't they just say the eventual consistency of D1 was causing them foreign key issues (which also then highlights atomicity issues)?

Oh, the "Complete E2EE, complete OAuth" section is also entirely halucinated. They didn't implment that endpoint at all, so their claim of "Point Element or any Matrix client at the domain, and it discovers everything automatically." is blatantly just false.

The "sliding sync for mobile" section¶

There's a lot of nuance lost in this section:

Traditional Matrix sync transfers megabytes of data on initial connection — every room, every state event, recent timeline for each. This destroys mobile battery and data plans.

This claim opts to ignore lazy loading, and sync filters as a whole. They aren't entirely wrong though, traditional sync can use an excessive amount of data, especially if you have a large account and just logged in.

But they then have the balls to say:

Combined with edge execution, mobile clients can connect and render their room list in under 500ms — even on slow networks.

Which... isn't impressive? I just timed an Element X iOS load and my room list loaded faster than my reaction time, I'd hazard at under 100ms. And that's roundtripping from my house, to my VPS in Germany, and then back to my house. I have like, inverse edge.

Their conclusion¶

When we started this project, the goal was simply to see if the pieces would fit. Could a protocol as complex and stateful as Matrix — designed for heavy iron and persistent file systems — actually run on an ephemeral, serverless edge?

The answer is yes, but the implication is bigger than just Matrix.

This architecture shifts the paradigm for self-hosting. It turns "running a server" from a chore into a utility. You get the sovereignty of owning your data without the burden of owning the infrastructure.

No, the answer is no, because everything you said was blatantly false, contradictory, or just marketing rubbish. And we haven't even looked at the code yet! Furthermore, how do you get the sovereignty of owning your data when your data is on drives owned by Cloudflare? See what I mean by contradictory?

Matrix on Workers runs in production today, handling real encrypted communications for our team. It is fast, it is cheap, and it is arguably one of the most secure ways to deploy a homeserver today.

They actually leaked their demo server (which has now been taken down), and I was able to register an account on it and chat to a friend. Ignoring the fact that most of the Matrix API was unimplemented, it did actually work, and I was able to register, create a room, send a message, and be invited to another room and join. Media also worked, although profiles didn't.

The kicker though, "it is arguably one of the most secure ways to deploy a homeserver today". Cloudflare's server had no authentication (at the time of publishing their blog).

Critical authentication components like signature validation, hash checking, and access control checks were merely TODO comments in the code, which allowed me, with my remote server, to pull the entire chat history and room state of any room I had the room ID of:

I did also manage to get a send_join in there, which allowed me to download the room's entire state and auth chains. This is slightly more valuable than the discovery I made later, which was that you could just download the state for any room without having any member in it, however this isn't as valuable as being able to send a join, as that gives you the auth chains too, meaning you effectively get every state event in the room. Or, it would do, if they implemented that.

However, they did have something more secure than other implementations! Their federation transaction handler uses a non-standard authentication scheme! This means no other standard Matrix homeserver software will be able to federate with Cloudflare's server (including the one I used to hand-craft the federation requests used to probe their API), which reduces the risk of being hacked there to near zero! Until someone patches their server to send the nonstandard auth.

Let's take a look at the code¶

So now that I've broken down the LLM-generated advertisement masqeurading as a blog post, let's take a look at the code that actually backed this post! Don't forget that at no point was it made clear that AI was used in any part of this project's development.

As before, I'll be referencing the first published version, which was released before the blog post went live. Several cover-up edits were made to the repository after significant backlash started.

First off, the repository is at https://github.com/nkuntz1934/matrix-workers. Why it's not under Cloudflare's org and is simply under the blog post author's personal account is beyond me, but whatever, let's take a look.

First thing you'll notice: matrix-workers is written in TypeScript. Huh? The blog post pretty much exclusively mentioned Rust... and they said they ported Tuwunel... a Rust homeserver.

Anyway, the first commit is here: https://github.com/nkuntz1934/matrix-workers/commit/72b92e

Interesting, a +30256 -0 commit. That's a lot of code to push all in one go! But benefit of the doubt, maybe it was originally a private repo that got squashed.

Unfortunately, not all content in this commit is available anymore. I'll cover what I can.

README¶

Their README states:

A production-grade Matrix homeserver implementation running entirely on Cloudflare's edge infrastructure. Implements Matrix Client-Server API v1.12 and Server-Server (Federation) API.

Strange version of the API to implement. We're on v1.17 now, why so old? Additionally, OAuth2/OIDC wasn't a thing in v1.12, so how would they have implemented it?

They also list a few supported endpoints, which for some reason includes /_matrix/federation/v1/key/server? Which has, as far as I know, never existed? The correct endpoint is /_matrix/key/v2/server. It also lists that /v1/send_join is implemented, which is not a good show, because /v1/send_join is deprecated and also proposed for removal entirely.

Codebase¶

First off, looking at the federation API, there's the obvious: federation transaction auth checks are merely TODO comments. There's also custom, non-compliant request auth on this endpoint specifically. If they actually persisted any data received here, any malicious remote server would be able to just take over any rooms they wanted, as we saw with two recent critical severity CVEs in Conduit-based homeservers.

There's zero access control checks on event-fetch and state-fetch endpoints, make_join doesn't check that joins are even allowed, and send_join does't do access control nor permission checks! I hope you didn't expect to have any private conversations using your post-quantum TLS encrypted edge server!

This wouldn't be a problem if matrix-workers implemented state resolution, one of the core concepts surrounding Matrix rooms. You know, the conflict resolution algorithm? Matrix-workers performs no conflict resolution or event authorisation. Just upserts.

Okay, the federation API is totally insecure. Maybe the client API is better?

calls.ts implements routes that have never existed in the Matrix spec, oidc-auth.ts exists despite spec v1.12 predating OIDC, rooms.ts creates invalid-depth events and allows you to join rooms while being banned, and even doesn't check power levels before allowing event creation (which means you can just join a room and demote admins).

Crikey.

The ensuing cover-up¶

Just a bonus, but the author left PII in and then removed it by adding a normal commit. You can see in this commit that the project was originally called tuwunel, and included credentials for a database. This is also where the demo server, m.easydemo.org, was found.

After the blog post caught steam, people quickly found out that a lot of important functionality was simply left as TODO comments, such as the entire federation transaction authentication process.

Luckily this didn't persist any data, but if it did, any server would've been able to send total garbage to the matrix-workers homeserver, and would've effectively been able to take over admin accounts and other functions. What was it they said earlier, most secure way to deploy?

Anyway, after getting ripped a new one for this glaring oversight, the author then pushed a commit that... removed the TODOs. Not fixed them or implemented them. Just removed them: https://github.com/nkuntz1934/matrix-workers/commit/0823b47

For obvious reasons, this then got put on blast, which resulted in that commit being rebased, reworded, and ultimately force-pushed back upstream, with the same content, but now with the commit message "Clean up code comments". Why become more vague, hm? https://github.com/nkuntz1934/matrix-workers/commit/2d3969d

After a few hours of mockery, the author finally updated the README to include:

• The server is a "proof of concept", not the previously advertised production-grade project.
• Claude Code Opus 4.5 was used (to "speed up [development]")

And there's been no activity since. It looks like the Cloudflare blog post was also updated to reflect that this is a "proof of concept" and not a production-ready implementation.

The thing is, the blog post still talks about this being some form of Tuwunel server. But, there's zero trace of Tuwunel in this project at all? Aside from in that one commit with PII, but even then that's only by name. So they're still actively lying on their blog post.

Response in other areas of the internet¶

While this low-effort AI-generated insecure garbage was pumped out and put on the front page of Cloudflare's blog, a hackernews thread was posted: https://news.ycombinator.com/item?id=46780837, which continued on at https://news.ycombinator.com/item?id=46781516.

While the blog and project were getting flamed in Matrix for being a joke, @jade:ellis.link took the time to break everything down on her fediverse account: https://tech.lgbt/@JadedBlueEyes/115967791152135761 (probably some useful insights there too!)

The Cloudflare CEO's response¶

On X, Cloudflare posted about the blog:

We ported a complete Matrix homeserver to Cloudflare Workers. No servers. No databases to manage. Just encrypted messaging running at the edge—with post-quantum cryptography protecting every connection. cfl.re/4r5vDIg

To which Aires replied:

@eastdakota how did this get green-lit?

And Matthew Price, the CEO of Cloudflare, responded:

It’s a proof of concept. Get off your high horse. 🙄

This tells us two things:

1. The CEO of Cloudflare endorses vibe-coding insecure projects (even if the "proof of concept" is to be believed)
2. The CEO of Cloudflare is complicit in the cover-up, because the original blog post advertised this as production-ready, and the origin tweet does not disagree or provide any indication of disageement with this.
3. Cloudflare is proud of this, otherwise this passive aggressive response wouldn't have been posted.

Conclusion¶

So, after sleeping on it, I've come to the conclusion that while not malicious, this was an incredibly insulting and degrading incident. Maintaining software for Matrix is no easy feat, and requires incredible amounts of dedication and skill. Having the gall to attempt to build on the legacy and reputation of existing implementations like Tuwunel and the immense amount of hard work, love, care, and attention put into them just to try to sell something with a side of scaremongering is in incredibly poor taste, and to do it by talking to your computer and passing it off as your own work is insulting. Doubling down on this and continuing to pretend there was anything of substance here makes it even worse.

The response from the Matrix.org Foundation¶

But oh boy, we're not done yet! There's more! At 1AM today (per their RSS feed), @matthew:matrix.org published a post to the matrix.org blog titled "Matrix on Cloudflare Workers".

Given the uproar in the TWIM room, and other related spaces, including comments from Matthew himself, you'd assume that this blog post wouldn't be in favour of the situation, right?

Wrong!

Instead, the post does some incredible gymnastics to spin this into a positive thing. It starts off pointing out that the Cloudflare post was "well-intentioned, but not without flaws".

While this is agreeable, it then goes on to say this:

On the Matrix side, we’d like to welcome Cloudflare to the ecosystem anyway - we just wish it had been a smoother entrance! Thank you for building on Matrix. The good news is that the demo successfully serves its purpose to illustrate how Cloudflare Workers operate, and the code could certainly be used as the basis for a working server in future. Meanwhile, there’s a whole host of other places where Matrix and Cloudflare could play nice together.

Which pains me to read. Personally I have my own grievances against Cloudflare, so I'm not going to pretend I can be even remotely unbiased in this part of my own blog post. However, let's just recap what has happened here: A Cloudflare employee has sat down with Claude Code, asked it to make a Matrix homeserver that can run on workers, write some advertising material in the form of a blog explaining what it is and why it can run on workers, and then seemingly pushed this with near enough zero review process.

Is this really what the guiding hand of the Matrix spec wants to welcome into the ecosystem? This feels like a massive middle finger to the huge base of contributors who have poured their hearts into improving Matrix. In fact, I genuinely didn't see a single person talking about this incident who was in Cloudflare's favour. This has come ENTIRELY out of left field, and if this is the quality of actor and code we want to welcome in, I am frankly disgusted.

We’re deeply flattered that a company with the size and reputation of Cloudflare is paying attention to Matrix and publishing implementations - and the post is a very cool demo, and does demonstrate effectively how you might go about implementing a Matrix server on Workers.

No, they are not paying attention to Matrix. If they were paying attention to Matrix, fundamental authentication requirements would not be TODO comments in the published "production" source code.

Also - it does not demonstrate effectively how you can go about implementing Matrix. If you were not aware, it was just last month that two critical severity zero-day CVEs were exploited that affected every Conduit homeserver and forked project, ironically due to a lack of validation - the same validation that is deliberately being omitted in this demo. Claiming that this should be a role model in any capacity is shameful in light of this. For a post that boasted about its security, it was straight up lying. Why is the Matrix.org Foundation endorsing such behaviour?

On the other hand, it’s unfortunate that the post severely overclaimed the scope of the project

This is massively underweighting the severity of what is being written about, based off of the tone of the rest of the post, likely intentionally. This also makes the issue seem like the Cloudflare blog post was an "oopsie we didn't know :(", not intentionally garbage produced solely to advertise more Cloudflare services.

The post then goes on to detail a lot of the problems with the matrix-workers server, which is good to see.

But then, that paragraph is followed by:

Honestly, we feel a bit bad for the author: if you’re using an LLM to prototype an implementation of an unfamiliar protocol, you might not know where to check where the agent is overstating the truth - and you might not be aware how sensitive folks are to problems caused by overenthusiastic use of LLMs, especially if they have invested lots of time and effort into understanding and building functional Matrix implementations themselves. And while some criticism is justified here, we’re not at all fans of the pile-on which has happened, and we sincerely hope the author can bounce back stronger from this.

How incredibly patronising! I was without words while reading this, but luckily this blog post is pre-meditated and somewhat planned, so I have plenty of words to say!

First off: "Honestly, we feel a bit bad for the author". Don't. The author has been nothing but irresponsible & negligent (pushing unchecked code marked as production ready), shady (attempting to cover up security problems when called out), inconsiderate (using AI to bang out a codebase and blog post and not even disclosing it), and what they did is abhorrent. I personally have zero sympathy, and I don't think other people should either.

Secondly, "if you’re using an LLM to prototype an implementation of an unfamiliar protocol, you might not know where to check where the agent is overstating the truth". What a HORRIBLE take. You should ALWAYS check what the LLM outputs because, this might be surprising to some people, LLMs are notorious for completely making stuff up. Which we have seen happen a LOT here! And it's not like this is a difficult task - the author could've just referenced the client-to-server spec page and ctrl+f'd some terms (this would've lead them to find out that a decent chunk of the endpoints they implemented, like /call or whatever, never actually existed in the first place).

and you might not be aware how sensitive folks are to problems caused by overenthusiastic use of LLMs, especially if they have invested lots of time and effort into understanding and building functional Matrix implementations themselves

It feels like this section was written almost in anticipation of blog posts like mine, or potentially to belittle the existing vocalised complaints from the audience being named. I'm not sure which interpretation is worse. Regardless, this is also incredibly dismissive. Even if an LLM wasn't involved, I'd still be annoyed by the tone of the Cloudflare blog post basically just being an advertisement. But whatever.

The matrix.org blog post ends off with this:

Finally, it’s worth noting that The Matrix Foundation depends entirely on membership fees to fund our work to build out the missing communication layer of the open Web [...] All it takes is for a few large organisations like Cloudflare who benefit from Matrix to join the Foundation as members [...] we sincerely hope that folks like Cloudflare [...] will consider joining up, and so help accelerate Matrix to the point that it can truly provide a mainstream alternative to the centralised incumbents.

And there's the kicker, the real reason behind this entire blog post. This is why Matthew decided to butter up to Cloudflare here — money. Apparently, the Matrix.org Foundation values its ecosystem's community so little that it's willing to sell out to Cloudflare, who have just imposed an absolute monstrosity upon us, like a bull in a china shop. And listen I get it, I know the foundation is strapped for cash, but given the situation attempting to woo Cloudflare into joining like this is morally reprehensible and dishonest.

Furthermore,

help accelerate Matrix to the point that it can truly provide a mainstream alternative to the centralised incumbents.

Cloudflare's mission is antithetical to Matrix's. Their primary goal is centralising the web behind their product, and their increasing power over the world wide internet is a problem on so many fronts that I can't BELIEVE the Matrix.org Foundation would even consider working with them. It's already a hot topic that matrix.org utilises Cloudflare for their own homeserver, I sincerely doubt bringing them in even closer would go down well.

Actual conclusion¶

It's been over 24 hours since this started unfolding, and I can't say I'm any less disappointed, hurt, upset, or disillusioned. If this is the direction that open source is going to go, and it's going to be cheered along, then count me out. This is not what I've put blood, sweat, and tears into, and I hope I've been able to sufficiently convey just how much of a slap in the face this entire saga has been.

Everyone involved needs to do better.