I really wanted matrix to succeed, but I've completely and entirely given up on it now.
State resolution is just a total mess. On the best of days it's a hideously complicated system that sucks crazy resources, and on the worst of days rooms get blown up and bricked. Supposedly it's not as bad as before, but the fact that rooms can get bricked in the first place is bonkers. Just computing the member list of a room is a disaster due to the complex resolution algorithm - I spoke to a homeserver admin once who found that the DB storage space of just the member list can easily reach multiple gigabytes for larger rooms.
I'm interested in hearing if anyone has used simplex and what kind of experience it is. It seems like simplex is going for a similar audience as signal but using a very different approach. I don't think they've really had a breakout though and haven't heard it talked about much.
I also wanted - and still want - matrix to succeed! But, i've also semi-given up. I still use it because there a small number of folks i still chat with; though that's dying off. I managed a synapse home server very early in matrix's life, for a few years, and yeah it was complex back then...and for me the security is fine. Sure, there are gaps and things to be address for security...but, overall the thing that grinds my gears are the heavy resources needed. I started returning to xmpp. Is xmpp "simpler" or "more secure"? I would reply: no. But, you know where xmpp is really great? Ridiculously low needs for resources for a server! I understand that in this day and age we have far more access to so much more computing power...But, why should we allow bloat just because we can? Sorry, nowadays if I'm just trying to provide for chat, I'm looking into xmpp. I have no experience with simplex, but i think i'll wait til it bakes a bit more (and also see the resources usage story in a year or so).
Its funny, I was such a matrix fan boy, and now i'm looking at a chat tech (xmpp) that has been around for tons of years - figure that!
At this point I just want them to die off completely so we could get something better. They have been unable to make real improvements that make using Matrix a nice experience. And their existence somehow inhibits other solutions from emerging in the OSS community chat space.
As someone who wants to care not at all about the implementation details: last week I tried to sign up and use Matrix. I just want it to die.
It's got all the downsides of both centralized and distributed chat systems. Matrix.org didn't have the username I wanted so I went through four different home servers before giving up.
Tried to install a cli app (Weechat). Homebrew wanted four or five scripting languages, a spell checker, and still no Matrix plugin (need to install an abandoned C library for that and then wrangle python). The web app is shit. I get hijacking Cmd+K (and despise it), but it also hijacks Cmd+`.
> I spoke to a homeserver admin once who found that the DB storage space of just the member list can easily reach multiple gigabytes for larger rooms.
This is nothing to do with state resolution; it's due to Synapse's implementation deliberately cutting corners on storage efficiency while trading off for speed. I showed how it could be fixed a few months ago here: https://youtu.be/D5zAgVYBuGk?t=1853, but we prioritised fixing state resets instead.
> Also years later, we still don't have custom emojis, user statuses, user bios, invite links etc
There are MSCs for all of these now, and implementations are starting to filter through. The reality is that the project has been in a funding crunch since 2023 and we've had to focus on survival by prioritising stuff people pay for (i.e. big servers for govtech deployments) rather than custom emoji.
If speed is a concern, why did you all stick with Synapse (essentially single-threaded due to the GIL) over moving to Dendrite? As far as I can tell, Dendrite is, for all intents and purposes, abandoned.
> This is nothing to do with state resolution; it's due to Synapse's implementation deliberately cutting corners on storage efficiency while trading off for speed.
It's specifically to increase the speed if *state resolution*. If it weren't for the convoluted state resolution system, there wouldn't be a need to store gigabytes worth of state groups in the database.
Simply fixes some of the many ways that rooms can explode or be bricked. Zero confidence that room brickings are totally fixed once and for all.
> There are MSCs for all of these now, and implementations are starting to filter through. The reality is that the project has been in a funding crunch since 2023 and we've had to focus on survival by prioritising stuff people pay for (i.e. big servers for govtech deployments) rather than custom emoji.
A funding crunch since 2023 yet those features have been necessary for many years before 2023.
I used it for a year or so, with the default servers, worked just fine. We tried to get a group chat over from Signal to SimpleX but were unsuccessful in the end for unknown reasons. It just petered out and I didn't reinstall it on a new phone.
I still wonder why my experience and the experience of my friends, community and family with Matrix has been so positive compared to what people describe all of the time. Maybe it's because something changed in ~2025 when I started using it again? Both Beeper (my main Matrix provider, the one that preconfigures WhatsApp, Signal, SMS etc. bridges) and Element (the new mobile app and EMS for hosting). I onboarded something like two dozend non-technical people to it, and they are all happily using it every day, mostly to use the bridges that come with Beeper. Haven't heard a single complaint, even switching devices just works now. Almost all communities I care about (GNOME and so on) have Matrix servers, and since the spaces feature launched it's been really competitive with Discord, even UX-wise thanks to the new apps on desktop and mobile. Yet all I hear on HN and elsewhere is people complaining about UX issues that just have not appeared a single time for myself. Maybe it's people using non-compliant clients, old servers, or some other strange configuration? It's a mystery to me.
My best theory here is that because Matrix is actually quite close to being really good, folks get very upset about the remaining flaws, especially when the last few years have had to prioritise development for public sector deployments over being a Discord killer, in order to keep the lights on.
Yes, that is my impression also. Extensively using for a couple of years, and only occasional quirks now and then, e.g. a profile verification issue (seeing the annoying red shields to each comment), but easily fixed. Or a UX update that doesn't necessary feel improvement (this is an Element thing, really).
It may not be good enough for your grandma, but certainly can support your software dev team, and there are countless of those active most probably. I really like Matrix as a daily driver. Also using Discord and Slack, and to me these look like a UX Christmas trees full of blinking lights, and far from anything you can call 'calm technology'.
Update: Seeing who I respond to, taking opportunity to mention these recent UX musings.. there used to be 'favorites' in one click in Element, now it is in a drop-down of filters not shown by default (I make distinction of 3 groups 'favorites', 'people', and 'rooms' for all/other. Not using spaces at all (except for the record)). And then there's paragraph spacing between replies given one after the other, is to small. Setting margin to 10px (think its 4px now) makes a world of improved reading already. Element web UI in firefox. Oh, I might add very long UI (re)loading times of a browser tab refresh of Element, as somewhat annoying and to avoid.
As an early adopter (signed up for the matrix.org riot instance some time in 2016) and someone who has run a homeserver on and off for nearly a decade, my primary issue with Matrix these days is that it still feels like there largely is stagnation in homeserver development because the spec oftentimes seems to follow features from Synapse instead of the other way around.
It seems like a lot of MSCs are implemented as experimental in Synapse while they are under active development, but sometimes it takes months or years for the MSC to be ratified in a way that is stable for other homeserver implementations to pick it up. One example that immediately comes to mind is sliding sync as well as threading and spaces. And in the case of sliding sync, the proxy deployment helped, I think only Synapse is the only server that actually supported (or maybe currently supports?) it and in terms of threads, that was more of a client-side issue of actually parsing and rendering m.thread events.
My feeling on it maybe isn't backed up by reality or the actual data of development but it makes developing on the ecosystem feel difficult.
The other real blocker to being a Discord-killer imo is the permissions model. Having power levels 0-100 is a lot less flexible than the RBAC-style model that Discord uses. Once Spaces were rolled out, a feature that would have been nice is to restrict access to certain spaces or rooms that are children of that space based on a role, which afaik still is not possible to do with the current permissions implementation.
I think you're partially correct. People are upset at the time it takes to land even the most basic of fixes. Replies being bright red might be one of the most indicative examples. So while the work towards public sector deployments has probably helped with some aspects, the user-facing side has stagnated and people dislike that.
My experience has been in an enterprise environment but Matrix still falls way short of common enterprise messaging suites like Slask or even Teams. The effort has mostly been in managing channels.
The recent mandatory room version upgrade required a lot of real coordinated effort across our org.
Yup, this makes sense. I host a Matrix server, and it's equivalent in quality to Discord or anything else. Except that I've had a single unread badge on my account on iOS for at least a year now. It drives me nuts.
Self hosting experience went well, but it was very confusing for people moving from Discord about a year ago. If it's still the same, there's literally no way to simply send a registration or channel invite link to someone, and have them onboard through your home server by default without the need to explain "Oh, you have to change this URL to that" etc.
My primary issue is that they changed the voice chat system, broke existing self hosted installs, and the new system was barely documented. I threw in the towel since I mostly hosted it for myself. Could never fix their livekit stuff.
Can also vouch for this ansible script. I just updated a very outdated homeserver, postgres, and switched from nginx to traefik, and it was extremely painless. I was dreading it, but it worked amazingly. I donated to the author yesterday because of how well it went.
For what it's worth, I have had zero issues with Matrix myself. Some friends and I use it to stay in touch and we have had a very smooth experience. I'm not trying to discount the issues people have had, but for me Matrix has Just Worked (TM).
It used to be much worse before Sliding Sync was in widespread use... often just logging in would be next to impossible for me depending on the exact client I used and how much old state there was to fast-forward to... many minutes would go by stuck at "logging in..." as it downloaded gigabytes of god-knows-what.
>Unlike any other existing messaging platform, SimpleX has no identifiers assigned to the users
Lies by omission. SimpleX doesn't mask your IP-address by default. It leaks to the server. The ENTIRE public SimpleX network is hosted by two companies, Akamai and Runonflux. Metadata of two conversing users running on the same VPS can be detected with end-to-end correlation attacks, so pray that the two are not PRISM partners or whatever has replaced that program.
I'd be fine with SimpleX if they
1) bundled Tor and had a toggle switch during initial setup.
2) were transparent about what the toggle switch does (lag/bandwidth vs IP masking)
This is crucial as they already have Tor Onion Service server infra set up, but they're not making it easy for a layperson to use those. Instead they lie by omission. Their
"SimpleX has no identifiers"
only means
"SimpleX does not add additional identifiers"
They don't give a damn about your router gluing your IP address, that's increasingly becoming a unique IPv6 address, to every TCP packet header.
> "SimpleX has no identifiers" only means "SimpleX does not add additional identifiers"
These two statements are identical. IP addresses are Internet user identifiers, not SimpleX identifiers. All other application-level networks have identifiers of their own, in addition to IP addresses.
The goal of the design is:
- to prevent correlation of which IP address communicates with which,
- to prevent IP address from servers not chosen by the users.
It is not supposed to protect IP addresses from all servers, and Tor does not achieve that either, as Tor relays are servers too.
>These two statements are identical. IP addresses are Internet user identifiers, not SimpleX identifiers.
You are promoting SimpleX as an metadata-privacy improvement over Tor Onion Service based messengers like Cwtch, that hides the IP address by default. IP-addresses can be linked to users, and users will have to blindly trust the server is not collecting them. TelCos and ISPs keep logs of those as per data retention laws, so it's not hard to determine who a SimpleX user is if SimpleX wants to disclose that information.
>to prevent correlation of which IP address communicates with which
Which Akamai can do, and Runonflux can do. With 50% probability on per-target basis I might add.
>It is not supposed to protect IP addresses from all servers, and Tor does not achieve that either
Tor relays actively mask the IP of previous node from the next node.
Tor relays do not have access to internal protocol of SimpleX queues etc. SimpleX servers do, so they can collaborate with better efficiency.
Tor relays are chosen at random by the user, and random collaborating entry/exit nodes expose 10 minute windows for ciphertext-only metadata collection without access to IPs. SimpleX has 50% chance same company runs the server of both users.
>Tor does not achieve that either, as Tor relays are servers too.
This is ridiculous. You're effectively arguing, that because Tor isn't literally magical in being able to send TCP packets without IP addresses in headers, it's not significant improvement. As I showed you last time, the NSA itself has admitted they will NEVER be able to deanonymize all Tor users all the time, and that nor are they able to do that on-demand. Which is quite different from your "we run servers on two VPS companies ourselves, but pinky promise, they don't aggregate and correlate information."
>I designed SimpleX network, and the founder of SimpleX Chat.
I know. We two have had a looong conversation about this, first in Reddit, then here, then in privacyguides forum, and now again, here. Every single time you run to the hills.
Link your open, honest, non-misleading threat model to your front page. Make sure it makes it extremely clear that "Unless you install and configure Tor, SimpleX client does not take actions to hide your IP-address from the server".
I mean, look how professional https://tryquiet.org/ looks when the treat model is up there in the title bar, and not as a fine print behind menus.
Do that and we're done. I won't call you out anymore.
We plain a private payment mechanism for the servers that will utilize blockchain for valid reasons - we call it Community Vouchers. But they are not coins, they are service credits that cannot be created out of nothing (as coins) and cannot be sold - they can only be used to pay for the servers.
Didn't knew. Do you have a source on that? Can't see any mention of coins in their blog. Are you maybe referring to the crypto exchange with the same name that normally appears on top of google searches?
I don't have opinions about Matrix (a more-secure version of Discord or IRC seems like a reasonable thing to want) but want to put a word in for reading the Nebuchadnezzar paper, which is kind of a master class in cryptanalyzing secure messaging protocols, and really drives the point home that the hard part of a group secure messaging system isn't encrypting messages (anybody can do that) but rather in securely managing group membership without trusting servers:
I just read through the Matrix protocol documentation, coming to it from never having heard of Matrix before, and I have to say, it is hot garbage, reading like someone with no distributed systems background and hasn’t heard of lamport clocks or virtual synchrony vibe-coded a shonky mashup of IRC and XMPP and then tried to copy-paste Signal’s crypto in the middle. There are early warning signs in which it extensively reinvents endpoint name resolution, by the time you get to the twelfth attempt to build consensus over group state by sorting a DAG you may, like me, realise their entire project is a lost cause.
Matrix for me just went from, “what is this?” to being, “not touching that with a barge pole”. You could probably build yourself a group chat more worthy of trust using NNTP+gnupg and a couple of shell scripts.
I think you're looking at the outcome of attempting to design a secure open federated system for 12 different major kinds of user, not so much a lack of understanding of distsys stuff. The real problem is federation.
Notably, though, very few systems get the group membership problem right; this is a thru-line of secure messaging research results.
I've been on Matrix for 6 years or so. Some of that time was painful (especially when the largest public server was overloaded by a surge of new users in 2020). It's better now. I can't remember the last time I saw a decryption failure.
I still have gripes about it. Improvements to the spec and software have been slow lately, due to funding issues. But they are still arriving. The official desktop client remains buggy, bloated, and cluttered. But there are lighter alternatives that do what I need 99% of the time. Much of the meta-data is not yet end-to-end encrypted. But that's still planned, and since it's not as important in my day-to-day chats as it might be if I were whistleblowing, I'm willing to wait.
I continue to use Matrix because there is nothing else offering the combination of features that I most value in it. Notably:
- decentralized
- 1:1 and group chats
- offline message delivery
- multi-device support
- end-to-end message encryption with well-understood ciphers and protocols
- easy enough that I have brought in non-tech-savvy contacts with very little assistance
- cross-platform, on every major desktop and mobile OS
- not tied to google services or libraries
- open-source
- free (in both senses)
- self-hostable
- reasonably anonymous; no need for a real name, phone number, or (depending on homeserver) even an email address
- (in development) scalable audio/video chat that looks very promising
Harder to quantify, but also worth acknowledging: The project lead seems very level-headed, demonstrating good judgment and tremendous patience, and consistently makes himself and the inner workings of this difficult project accessible to the public. This gives me the sense that Matrix continues to develop with sound guidance. Thanks, Arathorn!
Free, reliable, enduring servers supporting all the XEPs needed to approach Matrix functionality were scarce when I last surveyed the XMPP landscape. This alone made it not viable for global, general-purpose use.
Also, only a tiny handful of clients supporting those XEPs by default were easy to find and set up, and I don't think those few covered all platforms, making the problem worse.
(And I don't recall XMPP ever being great at mixing offline delivery with multi-device support, since messages cached on a server weren't guaranteed to be held until all devices retrieved them, but I suppose it's possible that might have been solved by now.)
I do miss the Jabber glory days, and I might still consider it for smallish communities where I could reasonably provide the server and tech support, but I don't see it challenging Matrix as a practical choice for the world's general messaging needs.
Moxie (Signal Founder) gave a talk about the issues with federation at CCC in 2020, he took a crazy amount of flak for it, a lot of it from the Matrix community. Lots of the issue highlighted are in this post.
Just gave it a listen. A lot of what he asserts seems pretty obvious with many examples e.g. the ones he give about IP, DNS, email etc. Centralized movers will always have the advantage of coordination, so decentralized systems have to have a damn good raison d'etre that's immediately obvious (e.g. Tor) or else be eventually consigned to niche use in highly idealistic communities.
The message I got was more "decentralized services have major coordination issues that prevent them from adapting to changing needs".
Also a major point in Signal's development philosophy is building a comms platform that doesn't require that you trust them, because the protocol is built in a way that leaks the absolute minimum of data about the user necessary to make the service usable for the general public.
I disagree so much. Yes Federation is hard and it brings lots of new challenges. But with things like Chatcontrol it's the only way we can continue to communicate securely in the EU. Everything that is not federated has a single entity managing it which can be threatened with punitive actions. With federation everyone can run their own server meaning too many people to go after.
I understand these guys don't want it and they have good reason but federation in general should not die.
Fair enough I haven't had a chance to read the whole thing through, just had to skim eg the Matrix criticism. But if it's completely decentralised, why are there servers that must be paid?
Anyway I'll read it tonight when I have more time.
Same. Also, see how cool Mastodon is. Sure, it has technical problems, for example discoverability is harder. But so what? Preventing centralization of control is more important than more mundane things like "discoverability".
And in fact, discoverability on Mastodon is only less immediate because you don't a central authority making these decision for you. Nothing prevents you from checking out someone who follows and see who follows them and who they follow. It's more work, but you end up with a better result.
People who says "discoverability on Mastodon is difficult" presumably also say "I don't want to have to decide who my friends are, I want a corporation to choose my friends for me"...?
My friends are in real life, not on Mastodon or Bluesky.
Not everyone interested in doing detective work to find accounts related to their interests. It’s perfectly reasonable to expect social media platforms to help with that discovery.
If preventing centralization is important to you, then you should care about the product experience of the decentralized platforms.
Mastodon doesn't do enough to prevent centralization of control - when you make an account to use the network, you're making that account on some specific server. This ties your ability to communicate on the network under that identity both to the server operator, and to the domain name of the server. A fediverse server can go down because its maintainers deliberately shut it down or lose interest and stop maintaining it; a domain name can be lost or taken by a government (see the queer.af debacle). The administrators of a fediverse server can also decide to censor your posts or remove your account if they don't like what you post - and it's hard to argue that they don't have the right to do so because they're the ones running the server and storing your account as a row in their database.
If you run your own single-user fediverse server, you are the admin yourself so most of these aren't problems (although you still don't control your domain name). But it's difficult for most people to maintain their own social media server, so most people don't do this, meaning that they are still subject to the petty tyranny of their social media provider. It's just that instead of Mark Zuckerberg or Elon Musk, it's whatever random person runs the server that they randomly picked to put their account on.
Readit News
State resolution is just a total mess. On the best of days it's a hideously complicated system that sucks crazy resources, and on the worst of days rooms get blown up and bricked. Supposedly it's not as bad as before, but the fact that rooms can get bricked in the first place is bonkers. Just computing the member list of a room is a disaster due to the complex resolution algorithm - I spoke to a homeserver admin once who found that the DB storage space of just the member list can easily reach multiple gigabytes for larger rooms.
Also years later, we still don't have custom emojis, user statuses, user bios, invite links etc. - very basic things that literally every messaging platform has. https://github.com/element-hq/element-meta/issues/339 https://github.com/element-hq/element-meta/issues/573 https://github.com/element-hq/element-meta/issues/426
I'm interested in hearing if anyone has used simplex and what kind of experience it is. It seems like simplex is going for a similar audience as signal but using a very different approach. I don't think they've really had a breakout though and haven't heard it talked about much.
Its funny, I was such a matrix fan boy, and now i'm looking at a chat tech (xmpp) that has been around for tons of years - figure that!
It's got all the downsides of both centralized and distributed chat systems. Matrix.org didn't have the username I wanted so I went through four different home servers before giving up.
Tried to install a cli app (Weechat). Homebrew wanted four or five scripting languages, a spell checker, and still no Matrix plugin (need to install an abandoned C library for that and then wrangle python). The web app is shit. I get hijacking Cmd+K (and despise it), but it also hijacks Cmd+`.
Makes me miss IRC really.
Not since https://matrix.org/blog/2025/08/project-hydra-improving-stat...
> I spoke to a homeserver admin once who found that the DB storage space of just the member list can easily reach multiple gigabytes for larger rooms.
This is nothing to do with state resolution; it's due to Synapse's implementation deliberately cutting corners on storage efficiency while trading off for speed. I showed how it could be fixed a few months ago here: https://youtu.be/D5zAgVYBuGk?t=1853, but we prioritised fixing state resets instead.
> Also years later, we still don't have custom emojis, user statuses, user bios, invite links etc
There are MSCs for all of these now, and implementations are starting to filter through. The reality is that the project has been in a funding crunch since 2023 and we've had to focus on survival by prioritising stuff people pay for (i.e. big servers for govtech deployments) rather than custom emoji.
If speed is a concern, why did you all stick with Synapse (essentially single-threaded due to the GIL) over moving to Dendrite? As far as I can tell, Dendrite is, for all intents and purposes, abandoned.
You guys gave up on the national security threat and caved.
Dont want authorities knocking my door down for using an app
when compared with the other concerns throughout the thread.
It's specifically to increase the speed if *state resolution*. If it weren't for the convoluted state resolution system, there wouldn't be a need to store gigabytes worth of state groups in the database.
* https://element-hq.github.io/synapse/latest/usage/administra...
* https://github.com/matrix-org/rust-synapse-compress-state
Maybe there's a way to calculate state without state groups, but I sure don't see one that I can use if I were to run a matrix server.
> Not since https://matrix.org/blog/2025/08/project-hydra-improving-stat...
Simply fixes some of the many ways that rooms can explode or be bricked. Zero confidence that room brickings are totally fixed once and for all.
> There are MSCs for all of these now, and implementations are starting to filter through. The reality is that the project has been in a funding crunch since 2023 and we've had to focus on survival by prioritising stuff people pay for (i.e. big servers for govtech deployments) rather than custom emoji.
A funding crunch since 2023 yet those features have been necessary for many years before 2023.
Maybe there was no migration?
It may not be good enough for your grandma, but certainly can support your software dev team, and there are countless of those active most probably. I really like Matrix as a daily driver. Also using Discord and Slack, and to me these look like a UX Christmas trees full of blinking lights, and far from anything you can call 'calm technology'.
Update: Seeing who I respond to, taking opportunity to mention these recent UX musings.. there used to be 'favorites' in one click in Element, now it is in a drop-down of filters not shown by default (I make distinction of 3 groups 'favorites', 'people', and 'rooms' for all/other. Not using spaces at all (except for the record)). And then there's paragraph spacing between replies given one after the other, is to small. Setting margin to 10px (think its 4px now) makes a world of improved reading already. Element web UI in firefox. Oh, I might add very long UI (re)loading times of a browser tab refresh of Element, as somewhat annoying and to avoid.
It seems like a lot of MSCs are implemented as experimental in Synapse while they are under active development, but sometimes it takes months or years for the MSC to be ratified in a way that is stable for other homeserver implementations to pick it up. One example that immediately comes to mind is sliding sync as well as threading and spaces. And in the case of sliding sync, the proxy deployment helped, I think only Synapse is the only server that actually supported (or maybe currently supports?) it and in terms of threads, that was more of a client-side issue of actually parsing and rendering m.thread events.
My feeling on it maybe isn't backed up by reality or the actual data of development but it makes developing on the ecosystem feel difficult.
The other real blocker to being a Discord-killer imo is the permissions model. Having power levels 0-100 is a lot less flexible than the RBAC-style model that Discord uses. Once Spaces were rolled out, a feature that would have been nice is to restrict access to certain spaces or rooms that are children of that space based on a role, which afaik still is not possible to do with the current permissions implementation.
Deleted Comment
The recent mandatory room version upgrade required a lot of real coordinated effort across our org.
My primary issue is that they changed the voice chat system, broke existing self hosted installs, and the new system was barely documented. I threw in the towel since I mostly hosted it for myself. Could never fix their livekit stuff.
I can only assume our experience in private servers is way different than people logging into the matrix.org server or in extremely populated rooms?
(0): https://github.com/spantaleev/matrix-docker-ansible-deploy
Lies by omission. SimpleX doesn't mask your IP-address by default. It leaks to the server. The ENTIRE public SimpleX network is hosted by two companies, Akamai and Runonflux. Metadata of two conversing users running on the same VPS can be detected with end-to-end correlation attacks, so pray that the two are not PRISM partners or whatever has replaced that program.
I'd be fine with SimpleX if they
1) bundled Tor and had a toggle switch during initial setup.
2) were transparent about what the toggle switch does (lag/bandwidth vs IP masking)
This is crucial as they already have Tor Onion Service server infra set up, but they're not making it easy for a layperson to use those. Instead they lie by omission. Their
"SimpleX has no identifiers"
only means
"SimpleX does not add additional identifiers"
They don't give a damn about your router gluing your IP address, that's increasingly becoming a unique IPv6 address, to every TCP packet header.
These two statements are identical. IP addresses are Internet user identifiers, not SimpleX identifiers. All other application-level networks have identifiers of their own, in addition to IP addresses.
The goal of the design is: - to prevent correlation of which IP address communicates with which, - to prevent IP address from servers not chosen by the users.
It is not supposed to protect IP addresses from all servers, and Tor does not achieve that either, as Tor relays are servers too.
The reasons not to embed Tor are listed here: https://simplex.chat/faq/#why-dont-you-embed-tor-in-simplex-...
Disclaimer: I designed SimpleX network, and the founder of SimpleX Chat.
You are promoting SimpleX as an metadata-privacy improvement over Tor Onion Service based messengers like Cwtch, that hides the IP address by default. IP-addresses can be linked to users, and users will have to blindly trust the server is not collecting them. TelCos and ISPs keep logs of those as per data retention laws, so it's not hard to determine who a SimpleX user is if SimpleX wants to disclose that information.
>to prevent correlation of which IP address communicates with which
Which Akamai can do, and Runonflux can do. With 50% probability on per-target basis I might add.
>It is not supposed to protect IP addresses from all servers, and Tor does not achieve that either
Tor relays actively mask the IP of previous node from the next node.
Tor relays do not have access to internal protocol of SimpleX queues etc. SimpleX servers do, so they can collaborate with better efficiency.
Tor relays are chosen at random by the user, and random collaborating entry/exit nodes expose 10 minute windows for ciphertext-only metadata collection without access to IPs. SimpleX has 50% chance same company runs the server of both users.
>Tor does not achieve that either, as Tor relays are servers too.
This is ridiculous. You're effectively arguing, that because Tor isn't literally magical in being able to send TCP packets without IP addresses in headers, it's not significant improvement. As I showed you last time, the NSA itself has admitted they will NEVER be able to deanonymize all Tor users all the time, and that nor are they able to do that on-demand. Which is quite different from your "we run servers on two VPS companies ourselves, but pinky promise, they don't aggregate and correlate information."
>I designed SimpleX network, and the founder of SimpleX Chat.
I know. We two have had a looong conversation about this, first in Reddit, then here, then in privacyguides forum, and now again, here. Every single time you run to the hills.
Link your open, honest, non-misleading threat model to your front page. Make sure it makes it extremely clear that "Unless you install and configure Tor, SimpleX client does not take actions to hide your IP-address from the server".
I mean, look how professional https://tryquiet.org/ looks when the treat model is up there in the title bar, and not as a fine print behind menus.
Do that and we're done. I won't call you out anymore.
We do not plan any coins.
We plain a private payment mechanism for the servers that will utilize blockchain for valid reasons - we call it Community Vouchers. But they are not coins, they are service credits that cannot be created out of nothing (as coins) and cannot be sold - they can only be used to pay for the servers.
It's covered here: https://simplex.chat/vouchers
Whitepaper on that design will be published in early 2026.
Disclaimer: I designed SimpleX network
Dead Comment
https://nebuchadnezzar-megolm.github.io/
Matrix for me just went from, “what is this?” to being, “not touching that with a barge pole”. You could probably build yourself a group chat more worthy of trust using NNTP+gnupg and a couple of shell scripts.
Notably, though, very few systems get the group membership problem right; this is a thru-line of secure messaging research results.
Happy holidays, HN… :)
I still have gripes about it. Improvements to the spec and software have been slow lately, due to funding issues. But they are still arriving. The official desktop client remains buggy, bloated, and cluttered. But there are lighter alternatives that do what I need 99% of the time. Much of the meta-data is not yet end-to-end encrypted. But that's still planned, and since it's not as important in my day-to-day chats as it might be if I were whistleblowing, I'm willing to wait.
I continue to use Matrix because there is nothing else offering the combination of features that I most value in it. Notably:
- decentralized
- 1:1 and group chats
- offline message delivery
- multi-device support
- end-to-end message encryption with well-understood ciphers and protocols
- easy enough that I have brought in non-tech-savvy contacts with very little assistance
- cross-platform, on every major desktop and mobile OS
- not tied to google services or libraries
- open-source
- free (in both senses)
- self-hostable
- reasonably anonymous; no need for a real name, phone number, or (depending on homeserver) even an email address
- (in development) scalable audio/video chat that looks very promising
Harder to quantify, but also worth acknowledging: The project lead seems very level-headed, demonstrating good judgment and tremendous patience, and consistently makes himself and the inner workings of this difficult project accessible to the public. This gives me the sense that Matrix continues to develop with sound guidance. Thanks, Arathorn!
Also, only a tiny handful of clients supporting those XEPs by default were easy to find and set up, and I don't think those few covered all platforms, making the problem worse.
(And I don't recall XMPP ever being great at mixing offline delivery with multi-device support, since messages cached on a server weren't guaranteed to be held until all devices retrieved them, but I suppose it's possible that might have been solved by now.)
I do miss the Jabber glory days, and I might still consider it for smallish communities where I could reasonably provide the server and tech support, but I don't see it challenging Matrix as a practical choice for the world's general messaging needs.
https://youtu.be/DdM-XTRyC9c
I go back and re-read this pretty much every time a decentralized thing has problems. It rings true.
Why federated protocols don't work (2016) - https://news.ycombinator.com/item?id=30314454 - Feb 2022 (130 comments)
The Ecosystem Is Moving [video] - https://news.ycombinator.com/item?id=21904041 - Dec 2019 (90 comments)
Reflections: The ecosystem is moving - https://news.ycombinator.com/item?id=11668912 - May 2016 (99 comments)
Which, is fair, but if absolute control of the client is required then there’s no benefit to E2EE.
Also a major point in Signal's development philosophy is building a comms platform that doesn't require that you trust them, because the protocol is built in a way that leaks the absolute minimum of data about the user necessary to make the service usable for the general public.
I disagree so much. Yes Federation is hard and it brings lots of new challenges. But with things like Chatcontrol it's the only way we can continue to communicate securely in the EU. Everything that is not federated has a single entity managing it which can be threatened with punitive actions. With federation everyone can run their own server meaning too many people to go after.
I understand these guys don't want it and they have good reason but federation in general should not die.
Anyway I'll read it tonight when I have more time.
And in fact, discoverability on Mastodon is only less immediate because you don't a central authority making these decision for you. Nothing prevents you from checking out someone who follows and see who follows them and who they follow. It's more work, but you end up with a better result.
People who says "discoverability on Mastodon is difficult" presumably also say "I don't want to have to decide who my friends are, I want a corporation to choose my friends for me"...?
Not everyone interested in doing detective work to find accounts related to their interests. It’s perfectly reasonable to expect social media platforms to help with that discovery.
If preventing centralization is important to you, then you should care about the product experience of the decentralized platforms.
If you run your own single-user fediverse server, you are the admin yourself so most of these aren't problems (although you still don't control your domain name). But it's difficult for most people to maintain their own social media server, so most people don't do this, meaning that they are still subject to the petty tyranny of their social media provider. It's just that instead of Mark Zuckerberg or Elon Musk, it's whatever random person runs the server that they randomly picked to put their account on.