Why not Matrix (2023)(telegra.ph)
telegra.ph
Why not Matrix (2023)
https://telegra.ph/why-not-matrix-08-07
73 comments
Yeah, agree. If you look at their list of SDKs things look great, but in my experience once you actually look into them, you find many are missing important features. The protocol is still getting changes that are, if not exactly backwards-incompatible, definitely backwards-inconvenient. There's also a catch-22 in that, due to this problem, usage is heavily skewed towards Element, which means that Element's behavior becomes a de facto spec.
+1
I also want to add, I'm using beeper and there new app is fantastic but the old desktop app (and current webapp) are based on element.
Which for me had the worst experience possible, startup times way beyond 1 minute, the webapp just runs into a chrome oom when I keep it open for longer than 1 hour and also the user interface is super unresponsive and laggy.
I tried element (without beeper) and had the same issues, that's why I never got into matrix.
I also want to add, I'm using beeper and there new app is fantastic but the old desktop app (and current webapp) are based on element.
Which for me had the worst experience possible, startup times way beyond 1 minute, the webapp just runs into a chrome oom when I keep it open for longer than 1 hour and also the user interface is super unresponsive and laggy.
I tried element (without beeper) and had the same issues, that's why I never got into matrix.
Points 2 and 3 seem to be a denial of reality: you never can delete something except by asking everyone else very nicely, and it's always possible that someone will repost something that they had that you didn't think they did.
Likewise point 8: there's nothing a protocol that isn't just a walled garden for a set of Trusted™ proprietary client binaries can do to prevent a client from doing whatever it likes with the decrypted information.
Likewise point 8: there's nothing a protocol that isn't just a walled garden for a set of Trusted™ proprietary client binaries can do to prevent a client from doing whatever it likes with the decrypted information.
There are no absolutes in security.
It’s not a perfect control by means, but if your objective is to minimise the amount of sensitive material just laying around, it definitely helps (and makes your adversary’s life a bit harder.)
It’s not a perfect control by means, but if your objective is to minimise the amount of sensitive material just laying around, it definitely helps (and makes your adversary’s life a bit harder.)
And how does a protocol enforce that, even in principle?
I use beeper which uses matrix under the hood so that I can talk to my friends who are using insta chats and since I don't want to use instagram just to chat with them.
It works really nicely, can recommend. The matrix protocol in that sense does work wonder.
There are new protocols like session, simplex (preferred?) but simplex has the issue that it is doing client side search for csam etc and I don't have a problem with csam search but then they will actually go into that group and shut that group, again I don't have an issue but their wordings have been extremely vague and it just seems like that anybody can report any server and they have the power to shut them down..., doesn't sound decentralized.
Again I am sure that csam is used as shield for privacy and yes I also would want to eradicate csam completely from the face of the earth but maybe in the process we would end up completely 1984.
I read into simplex protocol and the groups are honestly glue code tbh, you trust the nodes to give you safe info but in effect they can be malicious too. Simplex says that it is for 1-1 conversations but at that point, using something like tor based communication for live messaging is better.
The only use case of simplex I can find is 1-1 chats when the other person isn't online. But I guess I don't trust that either and at that point I would much rather use something like proton docs or proton drive as the storage layer...
Deltachat which is based on email looks really nice too.
There is this secuchat created by bkilm on gitlab which is worth a read actually. I am not finding this at the moment but I remember actually going through all of them and going on their matrix [1]
Both signal,matrix and maybe even simplex are good tbh.
Edit: Found it! [1]: https://bkil.gitlab.io/secuchart/
It works really nicely, can recommend. The matrix protocol in that sense does work wonder.
There are new protocols like session, simplex (preferred?) but simplex has the issue that it is doing client side search for csam etc and I don't have a problem with csam search but then they will actually go into that group and shut that group, again I don't have an issue but their wordings have been extremely vague and it just seems like that anybody can report any server and they have the power to shut them down..., doesn't sound decentralized.
Again I am sure that csam is used as shield for privacy and yes I also would want to eradicate csam completely from the face of the earth but maybe in the process we would end up completely 1984.
I read into simplex protocol and the groups are honestly glue code tbh, you trust the nodes to give you safe info but in effect they can be malicious too. Simplex says that it is for 1-1 conversations but at that point, using something like tor based communication for live messaging is better.
The only use case of simplex I can find is 1-1 chats when the other person isn't online. But I guess I don't trust that either and at that point I would much rather use something like proton docs or proton drive as the storage layer...
Deltachat which is based on email looks really nice too.
There is this secuchat created by bkilm on gitlab which is worth a read actually. I am not finding this at the moment but I remember actually going through all of them and going on their matrix [1]
Both signal,matrix and maybe even simplex are good tbh.
Edit: Found it! [1]: https://bkil.gitlab.io/secuchart/
Well, because hardly any of my friends are on Matrix. Most of them tried it at some point, but it doesn't stick as the user experience just isn't there.
Why not using correct upper case letters in your blog post and ease the pain of your readers?!
>> at this point it seems like most of the tech community is familiar with matrix
I have never heard anyone mention this, ever.
I have never heard anyone mention this, ever.
Weird. It's been around for years. A lot of open source projects use it, among other things.
Reddit uses it too as the backend for its Chat feature, which is also now used for private messages in general. It doesn't advertise this, though.
Thanks, Today I learned something new!
And many government agencies use it.
[deleted]
cool
https://matrix.org/blog/2021/07/21/germany-s-national-health...
tl;dr is that the French and German governments are really ahead of the curve then
tl;dr is that the French and German governments are really ahead of the curve then
What is the alternative in 2025?
https://bkil.gitlab.io/secuchart/
I read through this, joined their matrix server and talked.
Signal is decent enough to be used. (what I am using with my one friend lol)
it looks in this that simplex is good but I would argue its not when I actually looked into its protocol. Its group feature is actually experimental and you trust the original nodes and they can be malicious... and people could send messages behind your back too... So a no go.
Tor based are good too if you can manage to keep a device open but I have heard somewhere that tor can be tracked through bgp too but honestly tor might be the best option really :/
There are threat models. One has to find their threat model and work on it. There is not any "best alternative" in my honest opinion
I read through this, joined their matrix server and talked.
Signal is decent enough to be used. (what I am using with my one friend lol)
it looks in this that simplex is good but I would argue its not when I actually looked into its protocol. Its group feature is actually experimental and you trust the original nodes and they can be malicious... and people could send messages behind your back too... So a no go.
Tor based are good too if you can manage to keep a device open but I have heard somewhere that tor can be tracked through bgp too but honestly tor might be the best option really :/
There are threat models. One has to find their threat model and work on it. There is not any "best alternative" in my honest opinion
xmpp?
Another day, another matrix hit piece on the front page of HN. Unsure whether it's really my job as matrix lead to respond, but hey, let's go again.
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.
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.
>> 9. the end-to-end encryption is also annoyingly fragile
>Not any more; we fixed it over the course of 2024 [...] If anyone sees Unable To Decrypt messages these days (at least on Element Web or Element X + Synapse) we need to know about it.
You haven't "fixed" anything. I just opened Element X to an E2EE room hosted on a Synapse server, and I see a dozen "Waiting for this message"'s from three different people. Half the conversation in this room is people saying so-and-so's messages are unreadable, and of course it's a different person for everyone. Another client I have can see those people's messages, presumably because it was online at the time those people's clients joined / rotated their keys, because Matrix E2EE apparently depends on all parties' clients being online at the same time to be able to share keys.
This is exactly how it's been for years, in multiple rooms and clients, so it's hard to believe anything's changed, let alone been fixed.
The same thing happens with Element Web too, but at least that supports manually exporting and importing keys so that I can manually union all the working keys between all the clients. But of course Element X doesn't support that feature.
>Not any more; we fixed it over the course of 2024 [...] If anyone sees Unable To Decrypt messages these days (at least on Element Web or Element X + Synapse) we need to know about it.
You haven't "fixed" anything. I just opened Element X to an E2EE room hosted on a Synapse server, and I see a dozen "Waiting for this message"'s from three different people. Half the conversation in this room is people saying so-and-so's messages are unreadable, and of course it's a different person for everyone. Another client I have can see those people's messages, presumably because it was online at the time those people's clients joined / rotated their keys, because Matrix E2EE apparently depends on all parties' clients being online at the same time to be able to share keys.
This is exactly how it's been for years, in multiple rooms and clients, so it's hard to believe anything's changed, let alone been fixed.
The same thing happens with Element Web too, but at least that supports manually exporting and importing keys so that I can manually union all the working keys between all the clients. But of course Element X doesn't support that feature.
Also, malicious homeservers can add fake devices to rooms and the default client configuration is to send encrypted data to untrusted devices (and I have never seen anyone opt-in to "don't send to untrusted devices" because even with device signing, it breaks usability in most group chats).
Arathorn has argued before that this is "only an issue for malicious homeservers" but that is literally the entire threat model for E2EE -- if you didn't care about malicious servers you could just use TLS and avoid all of the "unable to decrypt message" issues.
Let's not get into the fact that even though they copied the Signal protocol (which is a good thing!), the amount of metadata stored by users' homeservers probably invalidates any of the deniability properties that motivated the development of OTR and Signal in the first place. Yes, the ability to keep chat logs forever is a key feature of Matrix, but you really have to ask whether trying to adapt the Signal protocol to their needs really made sense.
Arathorn has argued before that this is "only an issue for malicious homeservers" but that is literally the entire threat model for E2EE -- if you didn't care about malicious servers you could just use TLS and avoid all of the "unable to decrypt message" issues.
Let's not get into the fact that even though they copied the Signal protocol (which is a good thing!), the amount of metadata stored by users' homeservers probably invalidates any of the deniability properties that motivated the development of OTR and Signal in the first place. Yes, the ability to keep chat logs forever is a key feature of Matrix, but you really have to ask whether trying to adapt the Signal protocol to their needs really made sense.
I’ve never said this is “only an issue for malicious homeservers”.
I said that if you want to be sure who’s in your group you need to verify their identity, at which point you get warned very clearly if malicious devices get added and most clients will refuse to send messages in the room.
I said that if you want to be sure who’s in your group you need to verify their identity, at which point you get warned very clearly if malicious devices get added and most clients will refuse to send messages in the room.
And you need to opt-in to the global-and-off-by-default "don't send to unverified devices" setting, right?
Or is it no longer the case that even if you verify a user, unverified devices of that users' account will still receive peer keys and messages? (The description of the global knob implies that this still is the case. I don't have time to test this at the moment.)
Or is it no longer the case that even if you verify a user, unverified devices of that users' account will still receive peer keys and messages? (The description of the global knob implies that this still is the case. I don't have time to test this at the moment.)
Adding fake devices doesn't do anything since the homeserver doesn't have your key. It literally can't do that.
If you're sending encrypted to untrusted on a public room, you're trusting the homeserver.
It's literally like trusting a web server that it won't MITM you.
If you're sending encrypted to untrusted on a public room, you're trusting the homeserver.
It's literally like trusting a web server that it won't MITM you.
If a homeserver adds a fake device to an existing user of a room, the default behaviour of Matrix clients is to implicitly trust that device and send new messages to it. So any homeserver used by any user in a room could read future messages transparently and without any indication to the user that this is happening (unless all users in the room have opted-in to the "do not send to untrusted devices" knob).
This defeats the entire point of end-to-end encryption. The entire point is that you shouldn't have to trust intermediary servers. If Matrix clients had a giant red flashing warning if you disabled the "do not send to untrusted devices" knob, then maybe this would be excusable -- but they don't and it is off by default.
This defeats the entire point of end-to-end encryption. The entire point is that you shouldn't have to trust intermediary servers. If Matrix clients had a giant red flashing warning if you disabled the "do not send to untrusted devices" knob, then maybe this would be excusable -- but they don't and it is off by default.
Ugh, yes - i'd made the mental leap that https://github.com/element-hq/element-meta/issues/2700 had finished rolling out, whereas it looks like it's now delayed until October due to having to wait for the ecosystem to catch up. my bad.
To be clear -- I am very glad that this issue is finally being resolved after such a long time. I just wish that there had been a larger warning about it from the start (especially once E2EE stopped being marked as experimental).
Okay - as I said in the parent, this should not happen. Most people report UTDs as having gone away; i haven’t seen any myself in months, let alone any this bad.
The only scenario i can think of here is either you logged out of all devices on your account (so nobody could encrypt for you as you didn’t exist any more) or the room is impressively corrupt (state resets) or the server is impressively buggy (eg a beta) or the servers can’t actually talk to each other (eg messages are being replicated transitively but keys aren’t).
Please can you report with details so we can actually investigate?
As per the linked conference talks, we went on a gigantic mission to fix this, which based on our telemetry was successful.
The only scenario i can think of here is either you logged out of all devices on your account (so nobody could encrypt for you as you didn’t exist any more) or the room is impressively corrupt (state resets) or the server is impressively buggy (eg a beta) or the servers can’t actually talk to each other (eg messages are being replicated transitively but keys aren’t).
Please can you report with details so we can actually investigate?
As per the linked conference talks, we went on a gigantic mission to fix this, which based on our telemetry was successful.
Sounds frustrating. Report it for investigation, please.
I mean, you describe this as a "hit piece" but then go on to agree with most of the points (perhaps disagreeing that it is a problem, but not disagreeing with the factual basis of the statement) or point to incredibly recent developments which you say resolve those issues.
Matrix has been in development since 2014 (which is around when I first started using it) so pointing to solutions only just implemented in 2024 or "still being addressed" in 2025 as proof that this is a "hit piece" seems disingenuous to me (especially since this blog post is from 2023, and thus was correct at the time of writing according to your own comment). I understand that you are protective of your project, but having read your comments over the past decade, it seems that you feel the need to reply somewhat dismissively to any criticism.
I don't want to rehash the entire E2EE history here, but that decade-long saga has always bothered me.
Matrix has been in development since 2014 (which is around when I first started using it) so pointing to solutions only just implemented in 2024 or "still being addressed" in 2025 as proof that this is a "hit piece" seems disingenuous to me (especially since this blog post is from 2023, and thus was correct at the time of writing according to your own comment). I understand that you are protective of your project, but having read your comments over the past decade, it seems that you feel the need to reply somewhat dismissively to any criticism.
I don't want to rehash the entire E2EE history here, but that decade-long saga has always bothered me.
I call it a hit piece because it starts off with demonstrably bogus complaints (“if you ask servers to delete data they may ignore you!”).
The fact I then went through point by point to acknowledge that a few of the other points are still relevant shows that I’m not dismissing it.
Yes, I’m protective of the project, but I’m also irritated at folks who push fake information against it (especially if it’s padding out valid points).
p.s. sorry if this comes across as dismissive of your complaint O:-)
The fact I then went through point by point to acknowledge that a few of the other points are still relevant shows that I’m not dismissing it.
Yes, I’m protective of the project, but I’m also irritated at folks who push fake information against it (especially if it’s padding out valid points).
p.s. sorry if this comes across as dismissive of your complaint O:-)
> 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.
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'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.
Accidents happen, but that's exactly why the delete-as-suggestion feature exists.
Despite our frustration, you can’t deny that it’s among the top 10 requested features anywhere. Snapchat pretty much made its name on convincing people that they did it. Telegram and Signal have “Delete for me” and “Delete for everyone” options, etc.
One could argue that the right implementation is to not have a delete option at all. Having a delete option gives people the false idea that their data was deleted, but no one can guarantee you that. Pretty sure this makes people even more annoyed and outraged. Imagine the typical responses you will see on a HN post titled “Twitter now is refusing to let you delete your tweets” and Elon Musk saying something like your last sentence to people.
One could argue that the right implementation is to not have a delete option at all. Having a delete option gives people the false idea that their data was deleted, but no one can guarantee you that. Pretty sure this makes people even more annoyed and outraged. Imagine the typical responses you will see on a HN post titled “Twitter now is refusing to let you delete your tweets” and Elon Musk saying something like your last sentence to people.
So you trust that the client or the centralized service actually does what it says without inspection?
Then you also trust there's no lawful interception on those services anyway?
Then you also trust there's no lawful interception on those services anyway?
Ho did you even arrive at that bizarre conclusion
Hey, just want to say that I use and quite enjoy Matrix (I run a Synapse homeserver + Nheko on the desktop). Those who are dissatisfied are louder (as is normal), but they aren't by any means the only ones. Keep up the great work!
Just be aware that Nheko has still uses the deprecated libolm (which has known security issues and is unmaintained) and the maintainers have said they are not interested in moving to the supported replacement library[1] for the past year. As a fellow Matrix user, I would be cautious about using E2EE with any third-party clients -- the history of issues for the past decade speaks for itself.
[1]: https://github.com/Nheko-Reborn/nheko/issues/1786
[1]: https://github.com/Nheko-Reborn/nheko/issues/1786
The replacement library looks to be effectively Rust-only for now, so while I’m not thrilled with the E2EE situation there I can’t blame the maintainers for not wanting to complicate their build.
Right, they shouldn’t have to deal with complications just to ship a correct product.
(Massive /s in case it’s not obvious - they should suck it up and migrate)
(Massive /s in case it’s not obvious - they should suck it up and migrate)
Thanks for the heads up. I'm not so much interested in E2EE, but I'll have to look into the security issues. I use Nheko because I can't stand how bloated Element is (thanks, Electron), and appreciate the lightweight client. But I do want to not open security holes in the process, of course.
Aside: what is with the trend of omitting capitalization from blog posts? I get it when people are writing tweets/texts/whatever short-form media, but for a full blog post? I find it makes it harder to read. Am I alone in this?
Please don't complain about tangential annoyances—e.g. article or website formats, name collisions, or back-button breakage. They're too common to be interesting.
https://news.ycombinator.com/newsguidelines.html
https://news.ycombinator.com/newsguidelines.html
An entire article that omits capitalizing anything at all is likely noteworthy.
I found the lack of capitals in the whole article interestingly annoying actually.
Sorry, but I disagree. When the blog post omits the most basic spelling rules of the language it is written in, it is worth complaining, lest we end up normalising such behaviour.
>...it is worth complaining, lest we end up normalising such behaviour.
Discussions about spelling, grammar, and punctuation on other sites transgress the HN goal to normalize thoughtful, curiosity-driven discussion here.
Discussions about spelling, grammar, and punctuation on other sites transgress the HN goal to normalize thoughtful, curiosity-driven discussion here.
Then we can submit whatever random crap we find online in the name of "curiosity"? There is no filter whatsoever?
The thoughtful component that was mentioned is critical. For that I defer to one of pg's original statements: "Thoughtful in both senses: civil and substantial." The substantial aspect of thoughtful content is inherently absent from "crap."
https://news.ycombinator.com/newswelcome.html
https://news.ycombinator.com/newswelcome.html
Yeah, I tried to read the post and was immediately put off by the lack of capitalization. Then I came to the comments and had to fight the urge to ask “why not capitals”
OP uses bold text for emphasis like an ill-advised user of a marker pen and deploys a very bizarre collection of quotation marks. Sometimes "..." and sometimes “...”.
If you are going to studiously ignore convention, please do it consistently weirdly.
The list of issues is not a list.
Oh well. In the end the message is the thing and not the medium. Ideally the medium might be a bit more conventional to enable readers to follow the argument and not have to mentally adjust the text.
If you are going to studiously ignore convention, please do it consistently weirdly.
The list of issues is not a list.
Oh well. In the end the message is the thing and not the medium. Ideally the medium might be a bit more conventional to enable readers to follow the argument and not have to mentally adjust the text.
> In the end the message is the thing and not the medium
Ah, but to quote the philosopher Marshal McLuhan, the medium is the message. What does a tweet say? “This is a bite-sized idea that’s easy to understand.” What does a poorly-punctuated blog post say? “These ideas are sloppy.” What does a book say? “This is a more serious argument than you find online.” (alternatively, “I am looking for profit.”) What does a HN comment say? “This is my hot-take trying to sound smart.”
Ah, but to quote the philosopher Marshal McLuhan, the medium is the message. What does a tweet say? “This is a bite-sized idea that’s easy to understand.” What does a poorly-punctuated blog post say? “These ideas are sloppy.” What does a book say? “This is a more serious argument than you find online.” (alternatively, “I am looking for profit.”) What does a HN comment say? “This is my hot-take trying to sound smart.”
Since you didn't seem to get an actual answer, here is a discussion on this: https://news.ycombinator.com/item?id=43114156 . I can't find another discussion, but some folks seem to think a lack of capitalization also makes the post more informal.
I personally agree that it makes it much harder to read.
I personally agree that it makes it much harder to read.
why use many words when few do trick
"few do trick".
Are you implying, with that statement, that few words might trick a reader into a different interpretation from the one they might reach otherwise or that few words are enough (do the trick)?
I'm all in favour of parsimony but please deploy the bare useful minimum with an eye to clarity and not obfuscation. Also note that a full stop (period) is an indicator that you have finished dribbling.
Are you implying, with that statement, that few words might trick a reader into a different interpretation from the one they might reach otherwise or that few words are enough (do the trick)?
I'm all in favour of parsimony but please deploy the bare useful minimum with an eye to clarity and not obfuscation. Also note that a full stop (period) is an indicator that you have finished dribbling.
Just joke. No imply.
https://youtu.be/_K-L9uhsBLM
https://youtu.be/_K-L9uhsBLM
This is my first time seeing that, not fond of it
Make the LLM bulletpoint output seem more human that it is?
[deleted]
without autocorrect everything i type is in lowercase because it requires less effort think of all of the time and effort you wasted in life hitting the shift key why also punctuation
Counter argument:
Unless you are writing for yourself, then you are communicating with others. If you want others to be able to understand what you are saying, then you would benefit from doing what every presenter is taught to do for any event or slide deck - cater to your audience. In the case of long form written media, that means using punctuation and capitals.
Unless you are writing for yourself, then you are communicating with others. If you want others to be able to understand what you are saying, then you would benefit from doing what every presenter is taught to do for any event or slide deck - cater to your audience. In the case of long form written media, that means using punctuation and capitals.
and also why should we care about readers i mean they should be able to parse and backtrack through my sentences to figure out where one thought ends and another begins run on sentences are just propoganda by big puncutation and big english to sell more periods and why bother with roppper spelling or grammer it get in the way you can probably just infer what im trying to get at here so why should i expend any effor tto make life easier for my readers
WHY WITH VERY LITTLE EFFORT YOU CAN USE CAPSLOCK IT GETS MORE ATTENTION AND YOU CAN STILL ABSTAIN FROM PUNCTUATION
ihavedecidedtoskipspacestootowasteevenlesseffortinlifewhywasteprecioussecondshittibgthespacekey
Why? Because it makes reading significantly easier
I worked with a fellow who didn't believe me that the shift key upper-cased letters. The slippery slope continues sliding ever downwards.
Is this an attempt at performance art on HN? (given a couple of the replies)
Very brave.
Very brave.
Your commentary is a lesser derivative
https://www.youtube.com/watch?v=_K-L9uhsBLM
https://www.youtube.com/watch?v=_K-L9uhsBLM
On a phone sure, on a PC it's the same amount of time
To the project’s credit: A lot of work has gone into supporting better UX (QR code sign in, sliding sync) and the Rust library is also apparently pretty good.
Yet, somehow, there still hasn’t been an explosion of clients. IMO it’s because the protocol carries too much cruft and the standardization process (including vendoring) makes it hard to use new features when not using the official libraries, which are a) under-documented and b) only available from Rust, Swift and Android.