Readit NewsThey are barred from doing so by credit card companies. That's why many smaller shops have "cash preferred" signs.
Deleted Comment
TL;DR: the only valid points here really are complaints about state resets (being addressed in https://matrix.org/blog/2025/07/security-predisclosure/) and canonical json edge cases (which are on the radar). We should probably also remove device_display_names entirely. Stuff about "you have to trust other people's servers when you ask them to delete data!" is not exactly earth-shattering, and the encryption & authenticated media issues mentioned got fixed in 2024.
Point by point:
> 1. the graph is append-only by design
Nope, Matrix rooms are designed to let server prune old data if they want - https://element-hq.github.io/synapse/latest/message_retentio... is how you configure Synapse for it, for instance. The DAG can also have gaps in it (see point 6 below).
> 2. if you do want to delete something, you can send a redaction event which asks other servers very nicely to delete the content of the event, but redactions are advisory
If you ask a server to delete data, you have to trust it actually deletes it. That goes for any protocol; it's nothing to do with Matrix.
> 3. however, servers that choose to ignore redactions, or fail to process them for some other reason, can leak supposedly-deleted data to other servers later on.
see above.
> 4. certain events, like membership changes, bans or pretty much any event that exercises some control over another user can't be deleted ever as they become woven into the "auth chain" of future events
This one's almost true. The fact that "events which exercise control over another use" (i.e. access control) can't be deleted should not be surprising, given access control that doesn't disappear from under you is generally considered a good thing. However, if you really do want to delete it, you could 'upgrade' the room by pointing it to a new room ID, and vape the previous one (although admittedly there's no 'vape room' API yet).
> 5. the only way to discard all of this spam complexity is to recreate the room.
...or upgrade it, which is increasingly a transparent operation (we've been doing a bunch of work on it in preparation for https://matrix.org/blog/2025/07/security-predisclosure/). Meanwhile, mitigating state spam is part of the scope of the ongoing security work mentioned there.
> 6. it's exceptionally hard to linearize history if you don’t know the entire history of the room partially.
Yup, this is a feature. We don't want servers to have to sync full room history; they're allowed to do it in chunks. The tradeoff is that ordering the chunks is a heuristic, although we're currently in the process of improving that.
> 7. it is also somewhat possible to insert messages into history by crafting events in the graph that refer to older ancestor events
Decentralisation means that servers are allowed to branch from old commits (in git parlance), much like git. This is desirable if you're handling delayed traffic from a network partition or outage; we're working on avoiding it in other scenarios.
> 8. another thing that is worth noting is that end-to-end encryption in matrix is completely optional.
Sometimes E2EE makes no sense (e.g. massive public rooms, or clients which don't implement E2EE). Any client that speaks E2EE makes it abundantly clear when a room is encrypted and when it isn't; much like https v. http in a browser.
> 9. the end-to-end encryption is also annoyingly fragile
Not any more; we fixed it over the course of 2024 - see https://2024.matrix.org/documents/talk_slides/LAB4%202024-09... or the recording at https://www.youtube.com/watch?v=FHzh2Y7BABQ. If anyone sees Unable To Decrypt messages these days (at least on Element Web or Element X + Synapse) we need to know about it.
> 10. sometimes these device list updates updates also leak information about your device
Clients send a default device name (e.g. "Element X on iPhone 12 Pro Max") to the server, to help the user tell their own sessions apart, and to give users on the same server some way of debugging encryption problems. Admittedly this is no longer needed (clients typically hide this data anyway), so the API should be cleaned up.
> 11. the spec doesn’t actually define what the canonical json form is strictly
This one is accurate; we need to tighten/replace canonical json, although in practice this only impacts events which deliberately exploit the ambiguities.
> 12. matrix homeservers written in different languages have json interoperability issues
See above.
> 13. [server] signing key expiry is completely arbitrary
Server signing keys are definitely a wart, and we're working on getting rid of them.
> 14. split-brained rooms are actually a common occurrence
Once https://matrix.org/blog/2025/07/security-predisclosure/ lands, things should be significantly improved.
> 15. state resets happen quite a bit more often when servers written in different languages interoperate
See above.
> 16. room admins and moderators have lost their powers over public rooms many times due to state resets
See above.
> 17. you can’t actually force a room to be shut down across the federation
Same as point 2 and 3, you can't force other people's servers to do anything on the Internet (unless we end up in some kind of DRM or remote attestation dystopia)
> 18. moderation relies entirely on the functioning of the event auth system
See above for upcoming state reset fixes.
> 19. media downloads are unauthenticated by default
Not since https://matrix.org/blog/2024/06/26/sunsetting-unauthenticate...
> 20. you can ask someone else’s homeserver to replicate media
Only if you're authenticated on it, as of https://matrix.org/blog/2024/06/26/sunsetting-unauthenticate...
> 21. media uploads are unverified by default
Yes, being an end-to-end encrypted comms system, the server can't scan your uploads given it can't decrypt them, by default. Clients can scan though if they want, although in practice few do.
> 22. you could become liable for hosting copies of illegal media
This is true of any federated system. If you run a mail server, and one of your users subscribes to a malicious mailing list, your mail server will fill up with bad content. Similarly if you run a usenet server. Or a git forge, and someone starts mirroring malicious content.
I've see this "critique" come up with multiple different protocols, and it's almost infuriating.
How does the protocol ensure the server removes the data in question from backups? How does the protocol handle someone copying the data off the server onto another device before deletion? How does the protocol handle servers that don't properly implement the data deletion portion of the protocol? How does the protocol handle wiping the neural synapses associated with the memory of that piece of data for each person who ever interacted with it? Without solving these problems, it seems to me the "delete" feature is nothing more than a suggestion, and therefor the protocol itself is fundamentally broken!!
Like, how do you take back something horrible you said to a friend? You don't. You fucking live with your mistake. Don't send shit to other people if you don't want them to, you know, have that information.
I am writing from an off-grid shack in rural CO where I have installed a fairly nice panel, storage, and inverter system (4kw panels, 15kwh batteries, 6kw inverter).
I'm about $10k into that project (though I did all the labor, and didn't count that), but the easement and company equipment would have been $25k-$35k... much more effecient from a money perspective to go with solar out here in the sticks.
I am sure that in places like space, where there are no gas stations (or much solid matter at all), solar is going to be an easier deal than petrochemicals.
I'm having trouble interpreting your statement any other way. And that statement is pretty vile.
Can someone explain this ideological whiplash?
Easily. It's called fascism, one of the cornerstones being the marriage of industry and state. It has long been the marching direction of the US power structures, whether the individual participants cop to it or not. It has been an unwritten rule for decades and now it's just becoming more blatant. Republicans are not experiencing whiplash as much as they are becoming self-aware of their actual desires. There is a minority of the republican party that actually values small government (my respect goes out to them), but most of the party's actions to this end have been an obscene minority compared to their constant desire to either regulate morality via government overreach or enshrine their big business butt buddies into monopoly status.
While I feel the democrats are guilty of many of the same things, they are still a faction of what I would call the "capitalist-imperialist party." The GOP has been splitting off into the "fascist-imperialist party" for many years, which is likely one of the reasons for the political divide.