Drawbacks of P2P and a defense of Signal(changelog.complete.org)
changelog.complete.org
Drawbacks of P2P and a defense of Signal
https://changelog.complete.org/archives/10216-the-hidden-drawbacks-of-p2p-and-a-defense-of-signal
214 comments
> Signal would grow immensely in my eyes if they made the server code open source [SEE EDIT], and allowed an easy way to set the centralised server address in the Signal app. The current server would be the default, and perhaps changing the server would be hidden in Advanced Options for now.
I feel like this misses the point of what Signal is. It's not just software, it is the network as well. The client is a client that lets you communicate on the Signal network, which is operated centrally. A client that lets you choose a server endpoint is no longer a "Signal client", it's a Signal-compatible network client.
People seem to have an expectation that Signal server API is public, and that it should allow any compatible client to connect, or that a given client to connect to any compatible endpoint (in the spirit of public client/server internetty stuff). From what I can see, part of the whole point of the centralisation is to take that client/server API private so that the 'official' signal server only ever has to support a single client that they also control (hence allowing rapid iteration, avoiding legacy support etc).
> Unfortunately, you cannot change the server address in the app as downloaded from any app store, so my criticism remains.
What's preventing someone maintaining a client fork where you can do this? We have the code to run a Signal-compatible networks and software that can support this, so why does nobody?
I feel like this misses the point of what Signal is. It's not just software, it is the network as well. The client is a client that lets you communicate on the Signal network, which is operated centrally. A client that lets you choose a server endpoint is no longer a "Signal client", it's a Signal-compatible network client.
People seem to have an expectation that Signal server API is public, and that it should allow any compatible client to connect, or that a given client to connect to any compatible endpoint (in the spirit of public client/server internetty stuff). From what I can see, part of the whole point of the centralisation is to take that client/server API private so that the 'official' signal server only ever has to support a single client that they also control (hence allowing rapid iteration, avoiding legacy support etc).
> Unfortunately, you cannot change the server address in the app as downloaded from any app store, so my criticism remains.
What's preventing someone maintaining a client fork where you can do this? We have the code to run a Signal-compatible networks and software that can support this, so why does nobody?
>What's preventing someone maintaining a client fork where you can do this? We have the code to run a Signal-compatible networks and software that can support this, so why does nobody?
This is actively discouraged: https://github.com/libresignal/libresignal/issues/37#issueco...
This is actively discouraged: https://github.com/libresignal/libresignal/issues/37#issueco...
If you read the link, what's discouraged is using the non official client to connect to the Signal service, or using the "Signal" name on something that isn't produced / run by OWS.
There's nothing there about preventing anyone from running a signal-compatible service/network and shipping a fork of their own client to connect to it, which is my original point.
There's nothing there about preventing anyone from running a signal-compatible service/network and shipping a fork of their own client to connect to it, which is my original point.
It’t not discouraged.
In fact I’d say it’s actively encouraged to fork both the client and the server. What is not encouraged is just forking the client and using Signal’s servers.
“I'm not OK with LibreSignal using our servers, and I'm not OK with LibreSignal using the name "Signal." You're free to use our source code for whatever you would like under the terms of the license, but you're not entitled to use our name or the service that we run.“
In fact I’d say it’s actively encouraged to fork both the client and the server. What is not encouraged is just forking the client and using Signal’s servers.
“I'm not OK with LibreSignal using our servers, and I'm not OK with LibreSignal using the name "Signal." You're free to use our source code for whatever you would like under the terms of the license, but you're not entitled to use our name or the service that we run.“
> People seem to have an expectation that Signal server API is public, and that it should allow any compatible client to connect
That's because people have a reasonable assumption that a single actor (however good it is) should not have power over all of our communications. That's why we had federated networks in the first place (HTTP, SMTP, XMPP, DNS). Avoiding vendor lock-in is an important feature for most people.
That's because people have a reasonable assumption that a single actor (however good it is) should not have power over all of our communications. That's why we had federated networks in the first place (HTTP, SMTP, XMPP, DNS). Avoiding vendor lock-in is an important feature for most people.
Do people not realise that lots of single actors have power over all their communications°? Their ISP, for instance.
° Let's gloss over the fact that all here is hyperbole, unless you use a single mechanism / medium for communicating with everyone.
° Let's gloss over the fact that all here is hyperbole, unless you use a single mechanism / medium for communicating with everyone.
Of course they do. That's why millions of us have been pushing for years for DNSSEC, TLS (hopefully someday with DANE), Tor onion services, RPKI, etc..
A bad state of affairs is no reason to keep going in the wrong direction.
A bad state of affairs is no reason to keep going in the wrong direction.
DANE is a PKI whose roots are controlled by world governments, so pushing for it as an alternative to "single actors" doesn't make much sense.
ICANN's DNS roots are flawed by centralization, and DNS itself is a very insecure protocol. However, DANE is still a major progress over the browser CAs, because you can stop trusting random corporations and state agencies (the CAs, who are known to emit fake certificates) and instead trust your naming scheme.
Agreed DNS might not be the best candidate for this. However DNSSEC validation within the LAN (eg. on your local router, not @Google/CloudFlare) mitigates a lot of risks associated, and a new secure backward-compatible protocol like the GNU Name System (yes that's a thing) may eventually overcome those risks entirely in clever ways.
There's literature and actual deployments on tying name resolution to public key discovery in location-addressed protocols (eg. .onion, .i2p..) and it makes entire sense in my view. If such concerns interest you, check out the latest GNS draft RFC: https://lsd.gnunet.org/lsd0001
Agreed DNS might not be the best candidate for this. However DNSSEC validation within the LAN (eg. on your local router, not @Google/CloudFlare) mitigates a lot of risks associated, and a new secure backward-compatible protocol like the GNU Name System (yes that's a thing) may eventually overcome those risks entirely in clever ways.
There's literature and actual deployments on tying name resolution to public key discovery in location-addressed protocols (eg. .onion, .i2p..) and it makes entire sense in my view. If such concerns interest you, check out the latest GNS draft RFC: https://lsd.gnunet.org/lsd0001
No, DANE is a step back from CAs. When the Certificate Transparency logs show a CA has misissued, any of Google, Apple, or Microsoft can destroy that CA, as has happened with several of the largest CAs. Meanwhile, not only is there no such thing as Certificate Transparency for DANE, but you also can't revoke .COM at all.
Pretty much every way you look at DANE, it's a debacle.
Pretty much every way you look at DANE, it's a debacle.
I feel that's pretty disingenuous. Like you noticed the server-side code is active, and changing server address would be a niche-of-a-niche activity. Also, what would be the point of going after Signal's servers? Even if a/the government got a hold of all the data in there, it's encrypted with client keys. I mean sure, if they took over secretly and became a malicious MITM that's different, but it's still only for any future messages, not history. Not to mention I'd be inclined to believe they'd get the word out.
Signal's research and protocol is already used in, well, basically each and every discussion/video platform. WhatsApp, Telegram, Skype, Facebook Messenger, Google Messages, Duo... so it's hard to see Signal becoming more ubiquitous. Seeing the app more will probably happen naturally when events happen (like the WhatsApp privacy change) to drive people towards more secure platforms, but honestly I don't really see a major shift anytime soon.
Signal's research and protocol is already used in, well, basically each and every discussion/video platform. WhatsApp, Telegram, Skype, Facebook Messenger, Google Messages, Duo... so it's hard to see Signal becoming more ubiquitous. Seeing the app more will probably happen naturally when events happen (like the WhatsApp privacy change) to drive people towards more secure platforms, but honestly I don't really see a major shift anytime soon.
Telegram does not use Signal's protocol, Telegram's protocol is designed from scratch.
https://www.cryptofails.com/post/70546720222/telegrams-crypt...
https://www.cryptofails.com/post/70546720222/telegrams-crypt...
Ah true, MTProto is unique, looks like.
Server is open source too.
https://github.com/signalapp/Signal-Server
https://github.com/signalapp/Signal-Server
Only one branch: master
Last updated: 9 months ago
Unless I am missing something obvious in GitHub UI.
Last updated: 9 months ago
Unless I am missing something obvious in GitHub UI.
They don't actually develop on github, but code goes there every now and then. Not ideal, but better than nothing imo
And who knows if it's actually the software they deploy too.
> And who knows if it's actually the software they deploy too.
The whole literal point of the protocol is so that you don't have to trust the server, assuming you trust the client and protocol.
The whole literal point of the protocol is so that you don't have to trust the server, assuming you trust the client and protocol.
That's true for the fundamental part of sending and receiving messages, but at least one ancillary feature (contact discovery) requires trusting the server. They do have a setup with an Intel SGX enclave for remote attestation but I'm not knowledgeable on the limitations of this, although I understand that there are some.
https://signal.org/blog/private-contact-discovery/
https://signal.org/blog/private-contact-discovery/
Good point, I was just considering the messaging part. It'd be useful to be able to opt out of contact discovery, as I'm not sure you can do this on the current client.
look in their forums , few get it running an those who do discover that certain features like reactions etc don't work. So why exactly is happening on the server ??
> Similar can be said from everything like Scuttlebutt to GNU Jami; any service that operates on a P2P basis will likely reveal your IP, and tie your identity to it (and your IP address history). In some cases, as with Jami, this would be limited to friends you add; in others, as with Scuttlebutt and IPFS, it could be revealed to anyone.
Regarding Scuttlebutt (SSB), this isn't quite true. While IPFS requires a DHT, SSB's primary mode of updating content is via servers such as pubs and rooms, the DHT in SSB is optional and not the most common mode of updating content. In SSB you can and should choose the servers which you're connecting to, so in that sense it's closer to the federated model.
It's not entirely fair that the article equates "P2P" to "DHT", there are many ways you can do P2P connections, a DHT is only used for discovery. IP leakage is a problem in all these models (centralized, P2P, federated, etc): some computer somewhere will see your IP address, and you have to trust them not to do bad stuff with it.
For a comprehensive overview of privacy in DHTs and P2P, watch this talk: https://www.youtube.com/watch?v=nCCkwU4JPcY
Regarding Scuttlebutt (SSB), this isn't quite true. While IPFS requires a DHT, SSB's primary mode of updating content is via servers such as pubs and rooms, the DHT in SSB is optional and not the most common mode of updating content. In SSB you can and should choose the servers which you're connecting to, so in that sense it's closer to the federated model.
It's not entirely fair that the article equates "P2P" to "DHT", there are many ways you can do P2P connections, a DHT is only used for discovery. IP leakage is a problem in all these models (centralized, P2P, federated, etc): some computer somewhere will see your IP address, and you have to trust them not to do bad stuff with it.
For a comprehensive overview of privacy in DHTs and P2P, watch this talk: https://www.youtube.com/watch?v=nCCkwU4JPcY
https://SafeNetwork.tech is thoroughly p2p and doesn't reveal IP addresses because it's designed from the ground up to be decentralised, anonymous and censorship resistant.
zepto(1)
Can anyone chime in on their experiences hosting a synapse server? I have close to a dozen people on mine (although we don't federate much with the network as a whole, I set it up initially for a couple of groupchats/DMs with friends) and I'm not even close to hitting the limits of the $5/mo Digitalocean server I put it on. Does federating with the greater Matrix ecosystem cost that much extra processing power, that one user's chats are taking multiple gigs of RAM and gigabytes of space? It looks like the author's using multiple bridges, which could be a problem, but my understanding is that bridges are separate programs that hook into synapse via an API.
I will agree that voip/video isn't there yet, tried it with some friends and none of us could get anything working. I did go out and set up a TURN server afterwards, but once a piece of tech fails as badly as element did for us the damage is done. E2EE could definitely be done better as well, but in another post on here I saw a comment detailing a bunch of clients (many of which were abandonware) that didn't support E2EE at all. That's going to kill mass adoption, since you have no idea how many people are on those zombie clients that you still need to support. I wonder if the Matrix API has a way to define versions for these purposes, to advertise the highest supported version by both the client and server?
I will agree that voip/video isn't there yet, tried it with some friends and none of us could get anything working. I did go out and set up a TURN server afterwards, but once a piece of tech fails as badly as element did for us the damage is done. E2EE could definitely be done better as well, but in another post on here I saw a comment detailing a bunch of clients (many of which were abandonware) that didn't support E2EE at all. That's going to kill mass adoption, since you have no idea how many people are on those zombie clients that you still need to support. I wonder if the Matrix API has a way to define versions for these purposes, to advertise the highest supported version by both the client and server?
I have been running my own Matrix instance with federation on my 20 dollar/month Linode VPS for 5 years already.
I use between some friends and family and I'm also connected to massive channels like the official "Element Android" and "Element Web/Desktop".
And it runs... just fine. The server can be a bit performance hungry but I also host plenty of other services on my VPS (email, HTTP server, Seafile, VPN, etc) and I never noticed any degradation in performance in any of them.
They have been making a lot of progress in improving the performance of the Synapse server and it is very usable now. And it is not difficult to configure at all, it's easier than configuring Prosody.
I would say that the bottleneck now is more about improving the UX and the Voip capabilities of the clients.
I use between some friends and family and I'm also connected to massive channels like the official "Element Android" and "Element Web/Desktop".
And it runs... just fine. The server can be a bit performance hungry but I also host plenty of other services on my VPS (email, HTTP server, Seafile, VPN, etc) and I never noticed any degradation in performance in any of them.
They have been making a lot of progress in improving the performance of the Synapse server and it is very usable now. And it is not difficult to configure at all, it's easier than configuring Prosody.
I would say that the bottleneck now is more about improving the UX and the Voip capabilities of the clients.
I would be interested in average resource usage per user and/or per channel: CPU/RAM/disk, if you can provide the details.
I have been running a Synapse instance for nearly 3 years now. My instance is not for open registration but just for family and friends, currently it has around 7 users on it and federates with the rest of the Matrix ecosystem. I also have some experience writing apps that use the Matrix APIs.
The federation API on matrix is a little too chatty for my taste. But that in itself causes no problems. The problems start when a user on your homeserver joins a massive room on any other homeserver. Most commonly these are the bug rooms on matrix.org. Once someone joins one such room, synapse will start slowing down and taking tons of RAM. This has significantly improved in the last year, by huge leaps and bounds. It however does remain a memory hungry process.
VoIP / video on the other hand has been a success story for me. 1:1 calls run smoothly after installing a TURN server. Me and my users use the calling functionality multiple tines a day and don't seem to have any problems with it.
The federation API on matrix is a little too chatty for my taste. But that in itself causes no problems. The problems start when a user on your homeserver joins a massive room on any other homeserver. Most commonly these are the bug rooms on matrix.org. Once someone joins one such room, synapse will start slowing down and taking tons of RAM. This has significantly improved in the last year, by huge leaps and bounds. It however does remain a memory hungry process.
VoIP / video on the other hand has been a success story for me. 1:1 calls run smoothly after installing a TURN server. Me and my users use the calling functionality multiple tines a day and don't seem to have any problems with it.
I've been running one on my server for about 4 years. My server is a computer I got for free (some dell optiplex with an i3 in it), it eats 20W of power. It works more or less well depending on available bandwidth (on ADSL attachments were a pain).
These days it's mostly fine. The database is about 15GB (including media), there are scripts around the net to clean it up (rooms you've left, etc). Joining big, federated rooms is ram-expensive with synapse, though you now can specify a maximum complexity on your server to prevent joining those. Other small federated rooms are completely fine to join, and don't cost much more than a local room (IMO, there's little point in hosting a non-federated matrix server).
I use yunohost to simplify deployment, though it has some limitations. I did give access to a few friends, but I feel like I cannot guarantee uptime even though it has been pretty good so far. Once profiles-as-rooms land, that might change, as a user could just hop on another server if mine is down.
These days it's mostly fine. The database is about 15GB (including media), there are scripts around the net to clean it up (rooms you've left, etc). Joining big, federated rooms is ram-expensive with synapse, though you now can specify a maximum complexity on your server to prevent joining those. Other small federated rooms are completely fine to join, and don't cost much more than a local room (IMO, there's little point in hosting a non-federated matrix server).
I use yunohost to simplify deployment, though it has some limitations. I did give access to a few friends, but I feel like I cannot guarantee uptime even though it has been pretty good so far. Once profiles-as-rooms land, that might change, as a user could just hop on another server if mine is down.
I just set up synapse last week. The config file has 93,000 characters in it, which i joked is worse than IRCd. I'm running it on gentoo, pretty bare system, probably equivalent to double an rpi4. I did notice that the database file grows quickly. Currently the entire machine is using 272MB RAM, 0.8% CPU peaks, 0.01 15 minute load average.
Every part of setting up a server that will federate/host repeats again and again that you need a TURN server (and they recommend coturn) - which is another 26,000 character config file - in order to do VOIP. If you've ever run or used a pbx before, STUN is needed 100% of the time for nat traversal between clients. Coturn even says it won't run if it's NAT'd (it will, but that's irrelevant to most people.)
This is the fourth concurrent tech trial of chat daemons, with rocket.chat and mattermost being a couple of the other ones that we're testing. synapse/element/matrix has the benefit of forced e2ee by my configuration. I don't know of any other matrix federated servers, so i haven't tried that yet, but an associate says it works on my configuration - which means it's not as big of a pig as i thought it was based on the outlandishly, comically large config file - where whitespace matters!
Every part of setting up a server that will federate/host repeats again and again that you need a TURN server (and they recommend coturn) - which is another 26,000 character config file - in order to do VOIP. If you've ever run or used a pbx before, STUN is needed 100% of the time for nat traversal between clients. Coturn even says it won't run if it's NAT'd (it will, but that's irrelevant to most people.)
This is the fourth concurrent tech trial of chat daemons, with rocket.chat and mattermost being a couple of the other ones that we're testing. synapse/element/matrix has the benefit of forced e2ee by my configuration. I don't know of any other matrix federated servers, so i haven't tried that yet, but an associate says it works on my configuration - which means it's not as big of a pig as i thought it was based on the outlandishly, comically large config file - where whitespace matters!
Which file are you talking about? The homeserver.yaml?
Mine only has around 100 lines without comments.
Mine only has around 100 lines without comments.
Probably the homeserver.yaml file, as yaml is a standard format where indentation matters, and is always 4 spaces.
# cat /etc/matrix-synapse/homeserver.yaml|wc -l
1611
# cat /etc/matrix-synapse/homeserver.yaml| grep -v '^\s*#\|^$' | wc -l
101
I’ve been hosting my own homeserver for a few years on my own personal computer with a residential internet connection. It’s technically a violation of Verizon’s TOS but they don’t seem to care, probably since the traffic isn’t crazy.
I have about 20 users, with 5 of us being really active (but not much federation).
The computer is an Intel Kaby Lake i7 - really nothing special. I’ve never noticed crazy CPU usage.
I have about 20 users, with 5 of us being really active (but not much federation).
The computer is an Intel Kaby Lake i7 - really nothing special. I’ve never noticed crazy CPU usage.
Yes the federation completely killed my 5usd vps last time ive tried it. Ive been running synapse for 5+ years for about 20 active users.
I have it running on 4gb 8core arm sbc nowadays and i dont dare to federate. When somebody connects to a federated room with history and many users it explodes.
It seems future will be federated but with beefy servers.
Considering Matrix supposed to be the answer to decentralization... its mostly used on one main instance or in centralised silos like companies.
I have it running on 4gb 8core arm sbc nowadays and i dont dare to federate. When somebody connects to a federated room with history and many users it explodes.
It seems future will be federated but with beefy servers.
Considering Matrix supposed to be the answer to decentralization... its mostly used on one main instance or in centralised silos like companies.
I didn't try personally, but i heard from some hosting cooperatives they dropped synapse (and matrix entirely) because it was too resource hungry. for example disroot https://disroot.org/en/blog/matrix-closure
I run a non-federated instance on a tiny 2GB RAM ARM SOC. About 4-5 active users. Extremely light (under 80MB RAM usage) as long as you don't federate. Attempted enabling federation once - maxed out all cores, all mem/swap, and basically blew up the entire machine. Had to wipe away the database and start without federation.
Encryption UI is a mess. I have actively tried and failed to set up E2E encryption with at least one other technical user. Recommend disabling encryption unless you want non-technical users to abandon ship immediately.
Encryption UI is a mess. I have actively tried and failed to set up E2E encryption with at least one other technical user. Recommend disabling encryption unless you want non-technical users to abandon ship immediately.
A benevolent dictatorship would always be more effective than a democracy, but what happens once it stops being benevolent?
Same here. A centralized app (like Signal) is more effective than distributed/decentralized approach. But what would happen if Signal would ever stop being benevolent?
Remember the days Google were "do no evil"?
Same here. A centralized app (like Signal) is more effective than distributed/decentralized approach. But what would happen if Signal would ever stop being benevolent?
Remember the days Google were "do no evil"?
Isn't Signal a non profit? Much different incentives.
Are all non-profit organizations good? What stops Signal from becoming for-profit in the future?
Good point. OpenAI was a non-profit, but then they changed to be for-profit and were acquired by Microsoft. Same could happen to Signal.
> "[...] we've structured the project as a non-profit entity, so it can never be bought, has no investors, and isn't "owned" by anyone. We did this because we wanted to be "for" something other than profit, and we wanted to make sure the organization was only incentivized to create something that is in the best interest of the people who depend on it."
https://www.reddit.com/r/technology/comments/kt91qk/comment/...
https://www.reddit.com/r/technology/comments/kt91qk/comment/...
Yes, but I have structured my message so it can never be criticized :-)
Their intention is good, but I fail to see how it ensures that Signal, the project or the management of the app, would never fall into bad hands. Promising such a thing is somewhere between naive and misleading.
Their intention is good, but I fail to see how it ensures that Signal, the project or the management of the app, would never fall into bad hands. Promising such a thing is somewhere between naive and misleading.
Then you switch.
Same, what happens when your Matrix instance stops being benevolent? You switch.
Same, what happens when your Matrix instance stops being benevolent? You switch.
I'm annoyed that the comments here pile on the "ease of use" part, while largely ignoring what is more original here. (I don't know what I expected.)
The critiques of p2p identity leaking and big hungry servers are valid and I'm glad they are raised. As a Matrix user, I could respond to the first point that yes, it's a tradeoff depending on your threat model. I think that having a tractable identity is less bad than having one point of failure and moderation, on the broad social scale. If you are more concerned about very strong security now, you may decide differently. I think in the future, you could use an unfederated server of Matrix if you want something like Signal for sensitive connections. And yes, maybe pure p2p with no server nodes will never be viable for some use cases, with some threat models.
I do hope that in the future there will be an optimized Matrix server implementation in a faster language. (I'm saying Matrix, but of course my "loyalty" is ultimately more to the type of vision than some specific project.) I'm willing to cut some slack (pun unintended) to people having to iron out their big visions in an easier, more lenient language first. It's more important to have the features people want first.
As to the difficulty part, again, this is a legitimate concern, but I feel in HN comments and similar places it degenerated into a complete meme. All technology is "hard" for most/some people. I know older folks who drive to a clerk in a store to ask them to show how to do stuff on IPhone. There is always some greasing and other people having to tell you how to use it, not everything can be intuited. But you can simplify: point folks to a specific client (Element), which will point them to one server (Matrix.org). (Or, say, a random wallet like Ethereum does it?) I've done it with success with a bunch of "non-technical" people. No decisions needed on their part, but they could make them if they wanted to research (and not everyone has to want to!). It was no different in the era of email expansion and Outlook.
The critiques of p2p identity leaking and big hungry servers are valid and I'm glad they are raised. As a Matrix user, I could respond to the first point that yes, it's a tradeoff depending on your threat model. I think that having a tractable identity is less bad than having one point of failure and moderation, on the broad social scale. If you are more concerned about very strong security now, you may decide differently. I think in the future, you could use an unfederated server of Matrix if you want something like Signal for sensitive connections. And yes, maybe pure p2p with no server nodes will never be viable for some use cases, with some threat models.
I do hope that in the future there will be an optimized Matrix server implementation in a faster language. (I'm saying Matrix, but of course my "loyalty" is ultimately more to the type of vision than some specific project.) I'm willing to cut some slack (pun unintended) to people having to iron out their big visions in an easier, more lenient language first. It's more important to have the features people want first.
As to the difficulty part, again, this is a legitimate concern, but I feel in HN comments and similar places it degenerated into a complete meme. All technology is "hard" for most/some people. I know older folks who drive to a clerk in a store to ask them to show how to do stuff on IPhone. There is always some greasing and other people having to tell you how to use it, not everything can be intuited. But you can simplify: point folks to a specific client (Element), which will point them to one server (Matrix.org). (Or, say, a random wallet like Ethereum does it?) I've done it with success with a bunch of "non-technical" people. No decisions needed on their part, but they could make them if they wanted to research (and not everyone has to want to!). It was no different in the era of email expansion and Outlook.
> you could use an unfederated server of Matrix if you want something like Signal for sensitive connections
In the Jabber federation, we've had servers federating over tor onion services for about 8 years now, if that can be of interest to you (see prosody's mod_onions).
In the Jabber federation, we've had servers federating over tor onion services for about 8 years now, if that can be of interest to you (see prosody's mod_onions).
I use Element with some people and the reason they do not like it is that it takes a noticeable amount of time to send a message. It is annoying to me, too. What exactly is the reason for it? Can it be improved? This happens with both the desktop and Android client.
Yet another "Matrix isn't mature enough so just give up and use a centralized service" post that completely ignores the fact that XMPP is still alive and kicking. With multiple independent implementations (both client and server) that all work together pretty decently.
We're never ever going to tear ourselves away from this death by centralization if we keep inventing excuses for why we don't use the federated/distributed systems that we already have!
Edit: for those who are interested in using XMPP in 2021, there is a good list of public servers available at https://list.jabber.at/ and a list of clients that support modern OMEMO end-to-end encryption at https://omemo.top/
We're never ever going to tear ourselves away from this death by centralization if we keep inventing excuses for why we don't use the federated/distributed systems that we already have!
Edit: for those who are interested in using XMPP in 2021, there is a good list of public servers available at https://list.jabber.at/ and a list of clients that support modern OMEMO end-to-end encryption at https://omemo.top/
>Yet another [...] post that completely ignores the fact that XMPP is still alive and kicking
I didn't downvote but your comment doesn't help me because it's what I call "generic & enthusiastic evangelism" that does not actually engage any of the concrete arguments in the blog post. An example of another comment that does try to address the author's issues is the one from arathorn[1] and I hope that one gets upvoted to more visibility.
As an example of a concrete point you didn't engage with, he worries about the reliability scenario of sending a critical message such as "my car broke down".
You cite a link of XMPP servers. But here's another list of servers where many are colored pink (they're no longer online): https://www.jabberes.org/servers/
How does the average person curate your list and avoid choosing a server that will be offline pink in the future? Non-techie people don't want to keep switching servers because somebody quits their hobby of running a XMPP server.
That's an example of why directing friends & family towards Signal is less of a cognitive burden.
The author also mentions ease of voice & video calls on Signal. The cheerleading "XMPP is alive and kicking" doesn't address that either.
[1] https://news.ycombinator.com/item?id=25977828
I didn't downvote but your comment doesn't help me because it's what I call "generic & enthusiastic evangelism" that does not actually engage any of the concrete arguments in the blog post. An example of another comment that does try to address the author's issues is the one from arathorn[1] and I hope that one gets upvoted to more visibility.
As an example of a concrete point you didn't engage with, he worries about the reliability scenario of sending a critical message such as "my car broke down".
You cite a link of XMPP servers. But here's another list of servers where many are colored pink (they're no longer online): https://www.jabberes.org/servers/
How does the average person curate your list and avoid choosing a server that will be offline pink in the future? Non-techie people don't want to keep switching servers because somebody quits their hobby of running a XMPP server.
That's an example of why directing friends & family towards Signal is less of a cognitive burden.
The author also mentions ease of voice & video calls on Signal. The cheerleading "XMPP is alive and kicking" doesn't address that either.
[1] https://news.ycombinator.com/item?id=25977828
> generic & enthusiastic evangelism
I'm sorry my post has come across that way. I simply wanted to point out that framing the argument as "Matrix vs $PROPRIETARY_SERVICE" is unhelpful at best.
As an actual user of XMPP who has managed to get (some) of my contacts to join me in this brave old world of federation, I get frustrated when the conversation turns to "Matrix vs $CENTRALIZED_SERVICE_OF_THE_DAY" -- it's a false dichotomy that ignores that fact that 20 years later XMPP is still here and still hasn't died. IRC and SMTP are the only other standards for messaging that can claim that kind of longevity.
Of course XMPP is not perfect. But it's what we have to work with, and throwing our hands up in defeat and crawling back to the centralized platforms that keep letting us down is not the way forward.
I'm sorry my post has come across that way. I simply wanted to point out that framing the argument as "Matrix vs $PROPRIETARY_SERVICE" is unhelpful at best.
As an actual user of XMPP who has managed to get (some) of my contacts to join me in this brave old world of federation, I get frustrated when the conversation turns to "Matrix vs $CENTRALIZED_SERVICE_OF_THE_DAY" -- it's a false dichotomy that ignores that fact that 20 years later XMPP is still here and still hasn't died. IRC and SMTP are the only other standards for messaging that can claim that kind of longevity.
Of course XMPP is not perfect. But it's what we have to work with, and throwing our hands up in defeat and crawling back to the centralized platforms that keep letting us down is not the way forward.
Hmm.. I couldn't send "my car broke down" on Signal because it's one service was down for reasons entirely unrelated to my use.
One can use email and have an address at Google and one at work, and know these data points for a friend. One can use a phone and have multiple service providers (in some countries multiple sims for costs, in others legacy landlines.) One can use WhatsApp, Signal or Slack and then you need to synchronize on an entirely different backup service. None of them have the POTS guarantee and for the most part we (at least in my age demographic) don't even trust the POTS service with non-redundant numbers.
One can use email and have an address at Google and one at work, and know these data points for a friend. One can use a phone and have multiple service providers (in some countries multiple sims for costs, in others legacy landlines.) One can use WhatsApp, Signal or Slack and then you need to synchronize on an entirely different backup service. None of them have the POTS guarantee and for the most part we (at least in my age demographic) don't even trust the POTS service with non-redundant numbers.
> Hmm.. I couldn't send "my car broke down" on Signal because it's one service was down for reasons entirely unrelated to my use.
This happened to gmail recently, too, and my realtor couldn't send me contracts during a bidding war. In the case of gmail, it was an accidental reduction of provisioning to an internal service (perhaps easy to predict if you ignore the enormous complexity of the googleverse). In the case of Signal, it was a result of a scaling suddenly and faster than they could be expected to predict (perhaps easy to predict, but not a certainty; a risk in any case for a small operation like Signal).
This happened to gmail recently, too, and my realtor couldn't send me contracts during a bidding war. In the case of gmail, it was an accidental reduction of provisioning to an internal service (perhaps easy to predict if you ignore the enormous complexity of the googleverse). In the case of Signal, it was a result of a scaling suddenly and faster than they could be expected to predict (perhaps easy to predict, but not a certainty; a risk in any case for a small operation like Signal).
I'm happy to answer the technical criticism expressed in the blogpost relative to Jabber. Disclaimer, i'm a Jabber user and i'm a volunteer for the newborn https://joinjabber.org/ project.
> server implementation
In the Jabber ecosystem, there's a bunch of servers. Prosody and ejabberd are the most popular ones with easy configuration and extensibility, high reliability, support of all modern features (XMPP Compliance Suite 202X), and packaging for all distros. There's a lot more servers, but they may not be as reliable/complete.
> use matrix.org (...) or (...) will it be up (...) ?
There is no equivalent in the Jabber ecosystem, on purpose. Nobody wants to centralize all accounts, or wants to advertise services which may disappear some day. Jabber services, like web hosting and emails, is meant to be provided by hosting providers which will still be here decades from now. As with any protocol, you should never trust a provider of a single service (who doesn't deal with other protocols), unless they're the person developing this service and you want to support them. More often than not, these single services hosts are run by inexperienced volunteers who cannot guarantee they'll still have time and motivation to maintain the services years from now.
Some non-profits have been serving Jabber accounts for their members for more than a decade, like JabberFR here in France since at least 2005. And these "small" servers (JabberFR has ~700 parallel users and 2-3K servers federated with) take very limited resources and have much better uptime than most commercial messengers.
> Voice and video
This has been a long problem in the Jabber ecosystem because little people were working on it. Nowadays, 1-on-1 audio/video works perfectly across Conversations (mobile) and Gajim (desktop) and group AV works perfectly with Jitsi.
> Matrix is so hard to set up on a server
Jabber is really easy to setup on any server.
> Encryption isn’t mandatory in Matrix
Encryption isn't mandatory across the Jabber ecosystem, though some clients strongly encourage and facilitate it. This is the only criticism of matrix in this blogpost that equally applies to Jabber.
> How does the average person curate your list and avoid choosing a server that will be offline pink in the future?
That's a fair question. Registering with a hosting cooperative (not private corporation) which has a good track record is a good start. This is one of the reason we started the joinjabber.org project. Though we don't have a lot of servers recommended there just yet, we intend to curate services according to public criteria in the future.
> directing friends & family towards Signal is less of a cognitive burden
Not in my experience. This leads to questions like how can i talk to someone who doesn't have a phone number (you can't). Why is the service not working sometimes (smaller hosts have better uptimes). Why am i receiving phone calls from weirdos who took it from a groupchat i joined, i thought signal stood up for privacy. And hypothetically, in the future: why is Signal actively cooperating with law enforcement in my country. Why was Signal sold to a data-mining private corporation. Why is Signal going bankrupt and closing all services and where can i go...
I'd much rather take 5 minutes to explain to someone that Jabber is like email and they need to find a trustworthy, reliable provider, than spend hours and hours dealing with the mess and pain a centralized approach like Signal creates. Source: most of my friends and relatives are on Jabber; some have some moderate complaints about UX but it "just works".
> server implementation
In the Jabber ecosystem, there's a bunch of servers. Prosody and ejabberd are the most popular ones with easy configuration and extensibility, high reliability, support of all modern features (XMPP Compliance Suite 202X), and packaging for all distros. There's a lot more servers, but they may not be as reliable/complete.
> use matrix.org (...) or (...) will it be up (...) ?
There is no equivalent in the Jabber ecosystem, on purpose. Nobody wants to centralize all accounts, or wants to advertise services which may disappear some day. Jabber services, like web hosting and emails, is meant to be provided by hosting providers which will still be here decades from now. As with any protocol, you should never trust a provider of a single service (who doesn't deal with other protocols), unless they're the person developing this service and you want to support them. More often than not, these single services hosts are run by inexperienced volunteers who cannot guarantee they'll still have time and motivation to maintain the services years from now.
Some non-profits have been serving Jabber accounts for their members for more than a decade, like JabberFR here in France since at least 2005. And these "small" servers (JabberFR has ~700 parallel users and 2-3K servers federated with) take very limited resources and have much better uptime than most commercial messengers.
> Voice and video
This has been a long problem in the Jabber ecosystem because little people were working on it. Nowadays, 1-on-1 audio/video works perfectly across Conversations (mobile) and Gajim (desktop) and group AV works perfectly with Jitsi.
> Matrix is so hard to set up on a server
Jabber is really easy to setup on any server.
> Encryption isn’t mandatory in Matrix
Encryption isn't mandatory across the Jabber ecosystem, though some clients strongly encourage and facilitate it. This is the only criticism of matrix in this blogpost that equally applies to Jabber.
> How does the average person curate your list and avoid choosing a server that will be offline pink in the future?
That's a fair question. Registering with a hosting cooperative (not private corporation) which has a good track record is a good start. This is one of the reason we started the joinjabber.org project. Though we don't have a lot of servers recommended there just yet, we intend to curate services according to public criteria in the future.
> directing friends & family towards Signal is less of a cognitive burden
Not in my experience. This leads to questions like how can i talk to someone who doesn't have a phone number (you can't). Why is the service not working sometimes (smaller hosts have better uptimes). Why am i receiving phone calls from weirdos who took it from a groupchat i joined, i thought signal stood up for privacy. And hypothetically, in the future: why is Signal actively cooperating with law enforcement in my country. Why was Signal sold to a data-mining private corporation. Why is Signal going bankrupt and closing all services and where can i go...
I'd much rather take 5 minutes to explain to someone that Jabber is like email and they need to find a trustworthy, reliable provider, than spend hours and hours dealing with the mess and pain a centralized approach like Signal creates. Source: most of my friends and relatives are on Jabber; some have some moderate complaints about UX but it "just works".
XMPP is nice, but I have never see regular folks use it. Only tech peoples.
The fact that you can't "install and go" is killing decentralized solution because when you ask regular folks the "server url" (or even to choose on a server list), they give up because it's too complicated already.
It's already HARD enough to get them on Signal because they can't just click on the "Connect with Facebook" button. I got my mom on Signal and she actually converted other people to use it because it was not much harder than Whatsapp to set up.
XMPP nerver killed MSN back in the day's for the same reason...
It's already HARD enough to get them on Signal because they can't just click on the "Connect with Facebook" button. I got my mom on Signal and she actually converted other people to use it because it was not much harder than Whatsapp to set up.
XMPP nerver killed MSN back in the day's for the same reason...
We're smoothing onboarding (e.g. choose a server) with things like easy invitations: https://blog.prosody.im/great-invitations/
Support for creating invitations from within the app was recently added to Conversations (sponsored by the Snikket project). I'm hoping to see more servers deploy this functionality in the coming year, and more clients implement support.
Snikket is built around the idea of invite-first for onboarding onto self-hosted servers. As the dev I may be biased, but I've onboarded many people seamlessly this way.
Support for creating invitations from within the app was recently added to Conversations (sponsored by the Snikket project). I'm hoping to see more servers deploy this functionality in the coming year, and more clients implement support.
Snikket is built around the idea of invite-first for onboarding onto self-hosted servers. As the dev I may be biased, but I've onboarded many people seamlessly this way.
I use XMPP with "regular folks". At least on Android it works well to point someone to https://play.google.com/store/apps/details?id=im.quicksy.cli... and that's it.
Quicksy is the onboarding app we need for XMPP but until we have a perfect like for like Quicksy also available on iOS (like Element has) I can't in good conscience recommend my social circles join.
do you also use encryption with "regular folks" and verify each others devices?
YES !
first it automatically trust the devices but if you want you can improve it with manual verification :
https://gultsch.de/trust.html
"TLDR: Automatically trust all new devices of contacts that haven’t been verified before, and prompt for manual confirmation each time a verified contact adds a new device."
first it automatically trust the devices but if you want you can improve it with manual verification :
https://gultsch.de/trust.html
"TLDR: Automatically trust all new devices of contacts that haven’t been verified before, and prompt for manual confirmation each time a verified contact adds a new device."
That's the cool thing with Threema. If you verifyed the contact is so prominent, everybody want to verify each others key, even people who don't understand the concept. In Threema it is not hidden somewhere, it's just allways visible on each single contact with green or red dots.
Sounds similar to Element.
However, Threema does not yet have the problem of having to deal with verification with multiple devices, (which is what I was aiming at)
A few years ago, many regular folks were probably using it without even realizing it: Google Talk and AIM both had XMPP support and thanks to that, communication between the two platforms was possible.
The only value add of the "Connect with Facebook" button is identity provision.
I mean, surely there's a decent XMPP web client out there you could use with OAuth.
I mean, surely there's a decent XMPP web client out there you could use with OAuth.
As someone who in principle would like decentralized/federated cryptomessengers to win what usually blocks me from using them (over Signal) is that most of the people I would contact via messenger are not tech-savy. To make them switch the messenger has to be easy to setup and feature wise it has to be so promising that they don't feel like I lured them into something half baked.
While being federated is a huge plus for me, it still needs to be a good and usable messenger on all other fronts. If I can't imagine my mother using it, you are doing something wrong.
I am not usually of the "software must be usable by a baby"-front, but for a messenger adoption is key, and unless I only talk to my nerd friends it needs to be both simple and at least up to task with Signal (videocalls, groups, easy to find contacts, ...)
While being federated is a huge plus for me, it still needs to be a good and usable messenger on all other fronts. If I can't imagine my mother using it, you are doing something wrong.
I am not usually of the "software must be usable by a baby"-front, but for a messenger adoption is key, and unless I only talk to my nerd friends it needs to be both simple and at least up to task with Signal (videocalls, groups, easy to find contacts, ...)
People who make these sort of comments strike me as the same sort of people who box tick features in software development without ever giving consideration to UX. There’s always an open or decentralized alternative to whatever big bad closed/proprietary thing is being complained about. You can usually contrive together an argument for how it almost has feature parity. But only if stick your fingers in your ears and wilfully ignore the fact that the user experience is almost never up to scratch.
Just as a side node: I use Element currently and have done so for a while. My comment was about me not recommending this thing to my non-techie friends, not about me inventing an excuse why I won't use it.
And I want to be able to recommend it. I just currently can't, this was the point of my comment.
And I want to be able to recommend it. I just currently can't, this was the point of my comment.
Exactly. When network effect is in play, the bar for adoption must be set incredibly low. There is no way any of my non-tech friends is going to spend even 5 minutes investigating “XMPP” or whatever.
If it’s anything more than open app >> fill in phone number or create account >> see list of people to chat with, it’s already dead in the water.
If it’s anything more than open app >> fill in phone number or create account >> see list of people to chat with, it’s already dead in the water.
Quicksy is made to be as easy as you say to get an XMPP account and automatically recognize contacts :
https://play.google.com/store/apps/details?id=im.quicksy.cli...
https://quicksy.im/
https://play.google.com/store/apps/details?id=im.quicksy.cli...
https://quicksy.im/
I never really understood why Matrix invented their own thing instead of building on an already existing IETF Internet Protocol. Surely an "eventually consistent database" can be built on top of XMPP? It's just message passing.
When evaluating WhatsApp alternatives, this somewhat made me choose XMPP over Matrix. I recently uninstalled WhatsApp, Telegram and LINE (felt pretty good) and now use Conversations with most of my friends and family who were kind enough to try it out. Apparently Quicksy is free in the Google Play Store which is good news because nobody was willing to pay 2.50 EUR for Conversations and installing F-Droid just to install another app was quite a hurdle.
When evaluating WhatsApp alternatives, this somewhat made me choose XMPP over Matrix. I recently uninstalled WhatsApp, Telegram and LINE (felt pretty good) and now use Conversations with most of my friends and family who were kind enough to try it out. Apparently Quicksy is free in the Google Play Store which is good news because nobody was willing to pay 2.50 EUR for Conversations and installing F-Droid just to install another app was quite a hurdle.
> I never really understood why Matrix invented their own thing instead of building on an already existing IETF Internet Protocol.
Indeed. For sure XMPP has ugly corners (disclaimer I never implemented anything, mostly read some XEPs). I believe parts which are quite clean are the pub/sub part and the message archive (MAM). Afaik the current group chat extension (MUC) isn't so great (once you try to add history multi-device) and some people are trying to refactor it on top of pubsub (MIX) but it's not very active.
The matrix team clearly had precise ideas about the right way to do federated group chat and in fact (again afaik, my matrix knowledge is dated) their "rooms" seem to be quite flexible by not being completely tied to a particular server (several servers participate in hosting a room). Imho matrix has an edge in designing this from scratch and already knowing what the hard parts are from the beginning and i hope the good ideas will come over to XMPP. Perhaps some day an XMPP server will support matrix, making more clients available to the network (well integrated clients on every plateform is the real hard part for every distributed network).
Indeed. For sure XMPP has ugly corners (disclaimer I never implemented anything, mostly read some XEPs). I believe parts which are quite clean are the pub/sub part and the message archive (MAM). Afaik the current group chat extension (MUC) isn't so great (once you try to add history multi-device) and some people are trying to refactor it on top of pubsub (MIX) but it's not very active.
The matrix team clearly had precise ideas about the right way to do federated group chat and in fact (again afaik, my matrix knowledge is dated) their "rooms" seem to be quite flexible by not being completely tied to a particular server (several servers participate in hosting a room). Imho matrix has an edge in designing this from scratch and already knowing what the hard parts are from the beginning and i hope the good ideas will come over to XMPP. Perhaps some day an XMPP server will support matrix, making more clients available to the network (well integrated clients on every plateform is the real hard part for every distributed network).
It's a fundamentally different approach. You could in theory build it on top of XMPP, but it wouldn't actually interoperate sensibly, so what's the point?
> It's a fundamentally different approach.
Is it? (genuinely curious) Can't one see the matrix server-server state synchronization protocol as a transport layer for MAM archives? And pubsub nodes in XMPP are very matrix-room-like. This could be an XMPP extension allowing to multi-home pubsub nodes.
Also, there are recent matrix proposals [*] for representing several things (groups and user profiles) as rooms. Given the analogy room=pubsub, the user-profile-as-room seems to be the same thing as XMPP's PEP (used to share personal data, like public keys or avatar). And the group-as-room would be the MIX proposal.
[*] https://github.com/matrix-org/matrix-doc/blob/matthew/msc177...
[*] https://github.com/matrix-org/matrix-doc/pull/1769*
Is it? (genuinely curious) Can't one see the matrix server-server state synchronization protocol as a transport layer for MAM archives? And pubsub nodes in XMPP are very matrix-room-like. This could be an XMPP extension allowing to multi-home pubsub nodes.
Also, there are recent matrix proposals [*] for representing several things (groups and user profiles) as rooms. Given the analogy room=pubsub, the user-profile-as-room seems to be the same thing as XMPP's PEP (used to share personal data, like public keys or avatar). And the group-as-room would be the MIX proposal.
[*] https://github.com/matrix-org/matrix-doc/blob/matthew/msc177...
[*] https://github.com/matrix-org/matrix-doc/pull/1769*
And I cannot emphasize how nice it is that I have a selection of Jabber server implementations ready to use, and that using a version that is a couple of years old (say, from Debian stable) is not an automatic death-by-ostracization sentence.
Matrix today is more accessible than XMPP today. Matrix today has more communities than XMPP today. It's a pity that XMPP's hopes were dashed by the EEE of Google and Facebook, but I think if we want to make people move towards a decentralised protocol, we need to pick one, and I don't see a reason to spend my energy on reversing the direction of XMPP when Matrix is heading in the right direction.
Can XMPP do encrypted group chat yet?
I ran a medium-small sized XMPP community for many years, and eventually the community abandoned it and went back to IRC because it had better client/bot support. Matrix has a really good solution for end to end encrypted group chat, so I haven't seriously looked back at XMPP since then. They were the first ones with a decent solution to the most important feature I needed in decentralized group messaging, so they won IMO.
I tried a couple times to build out my own clients/bots etc for XMPP, and it just seemed way overly complex. I had to bundle something like 30 megs of jar files for a simple hello world app.
Also some silly things like ejabberd refusing to hash passwords in their user database because they were "already encrypted with SSL". It was all just a frustrating mess, and a security nightmare.
Matrix, with Element, has a pretty web frontend that does encrypted messaging right. If XMPP has anything like that, please do let me know, but every time I've glanced back at it, it seems stuck in the stoneage of messaging apps, still working on getting a committee together to form the standards for even the most basic functionality that everything else had 10 years earlier.
I ran a medium-small sized XMPP community for many years, and eventually the community abandoned it and went back to IRC because it had better client/bot support. Matrix has a really good solution for end to end encrypted group chat, so I haven't seriously looked back at XMPP since then. They were the first ones with a decent solution to the most important feature I needed in decentralized group messaging, so they won IMO.
I tried a couple times to build out my own clients/bots etc for XMPP, and it just seemed way overly complex. I had to bundle something like 30 megs of jar files for a simple hello world app.
Also some silly things like ejabberd refusing to hash passwords in their user database because they were "already encrypted with SSL". It was all just a frustrating mess, and a security nightmare.
Matrix, with Element, has a pretty web frontend that does encrypted messaging right. If XMPP has anything like that, please do let me know, but every time I've glanced back at it, it seems stuck in the stoneage of messaging apps, still working on getting a committee together to form the standards for even the most basic functionality that everything else had 10 years earlier.
> Matrix has a really good solution for end to end encrypted group chat
It's basically the same encryption scheme as Jabber/XMPP uses with OMEMO. The two were developed around the same time. On Jabber existing rooms need to be set to "members only" and "non-anonymous" for encrypted groupchat to take place because Jabber multi-user chats enable using nicknames (only the MUC operators know your address) which prevents clients from querying each other's key.
> I had to bundle something like 30 megs of jar files for a simple hello world app.
That sounds horrible. There's pretty good XMPP libraries around nowadays, like slixmpp if python is your thing. There's also a WIP Rust xmpp library if you'd rather.
> Also some silly things like ejabberd refusing to hash passwords
That sounds creepy. However, prosody does that very well though. And it seems ejabberd supports SCRAM authentication since 2007?
> Matrix, with Element (...) If XMPP has anything like that
ConverseJS is a web-based Jabber/XMPP client that does encrypted groupchat. It's supported by other clients as well (such as Conversations on Android). Movim, the more popular Jabber web client (because it has social features) does not support OMEMO yet unfortunately.
ConverseJS may not be as user-friendly as Element though because they don't have (yet?) the $$$$$$ of VC/government money matrix has.
> still working on getting a committee together to form the standards
There is a bureaucratic tendency around the XMPP Standards Foundation, because standardization is very important to avoid lock-in. However client devs have pushed features before/meanwhile publishing specifications and bureaucracy does not seem to be a concern for (some?) devs in practice.
It's basically the same encryption scheme as Jabber/XMPP uses with OMEMO. The two were developed around the same time. On Jabber existing rooms need to be set to "members only" and "non-anonymous" for encrypted groupchat to take place because Jabber multi-user chats enable using nicknames (only the MUC operators know your address) which prevents clients from querying each other's key.
> I had to bundle something like 30 megs of jar files for a simple hello world app.
That sounds horrible. There's pretty good XMPP libraries around nowadays, like slixmpp if python is your thing. There's also a WIP Rust xmpp library if you'd rather.
> Also some silly things like ejabberd refusing to hash passwords
That sounds creepy. However, prosody does that very well though. And it seems ejabberd supports SCRAM authentication since 2007?
> Matrix, with Element (...) If XMPP has anything like that
ConverseJS is a web-based Jabber/XMPP client that does encrypted groupchat. It's supported by other clients as well (such as Conversations on Android). Movim, the more popular Jabber web client (because it has social features) does not support OMEMO yet unfortunately.
ConverseJS may not be as user-friendly as Element though because they don't have (yet?) the $$$$$$ of VC/government money matrix has.
> still working on getting a committee together to form the standards
There is a bureaucratic tendency around the XMPP Standards Foundation, because standardization is very important to avoid lock-in. However client devs have pushed features before/meanwhile publishing specifications and bureaucracy does not seem to be a concern for (some?) devs in practice.
How much of the daily volume of internet chat-type messages do you estimate flow over XMPP versus alternative protocols and proprietary implementations?
I think it would be better if you made your point rather than asked it rhetorically. To me your argument reads like 'internet chat is currently proprietary so it always will be' but maybe I'm missing a step you'll need to fill in.
And I think part of internet discourse should allow to posit questions without actually having a big point to make. Why is it necessary to pontificate about everything?
In any case, if you want a point, whenever technical people bring up the technical superiority of X protocol or tool in a discussion, I like to ask myself this question. How many people actually use the thing that someone is telling me is so much better for the world? If it's so good, why is nobody using it for practical things? Have they used it before and there's a decline, or is it a new up and comer and it just hasn't caught on?
I think just asking the question sparks a valuable train of thought.
In any case, if you want a point, whenever technical people bring up the technical superiority of X protocol or tool in a discussion, I like to ask myself this question. How many people actually use the thing that someone is telling me is so much better for the world? If it's so good, why is nobody using it for practical things? Have they used it before and there's a decline, or is it a new up and comer and it just hasn't caught on?
I think just asking the question sparks a valuable train of thought.
> In any case, if you want a point, whenever technical people bring up the technical superiority of X protocol or tool in a discussion
They are not talking about "technical superiority" though, but about "alive and kicking" and "work together pretty decently" and you followed up with a question of daily volume as somehow being the indicator of the maturity of the technology itself.
There are multiple reasons for a lack in adoption, of course. Network effects, FOMO and walled gardens, financial might and power of dominating competitors to name a couple besides just the quality of the tech itself. And it doesn't help when many people off-handedly state the technology is not good, because it is not yet as broadly adopted as the centralized giants it is trying to be an alternative too :)
They are not talking about "technical superiority" though, but about "alive and kicking" and "work together pretty decently" and you followed up with a question of daily volume as somehow being the indicator of the maturity of the technology itself.
There are multiple reasons for a lack in adoption, of course. Network effects, FOMO and walled gardens, financial might and power of dominating competitors to name a couple besides just the quality of the tech itself. And it doesn't help when many people off-handedly state the technology is not good, because it is not yet as broadly adopted as the centralized giants it is trying to be an alternative too :)
Its not really a question though when everyone already knows the answer.
The 'why' you have here is a more open question and there's a lot in there. Companies trying to make money from it, users not having seen many real privacy implications on a wide scale, police presence being up and down etc. etc.
The 'why' you have here is a more open question and there's a lot in there. Companies trying to make money from it, users not having seen many real privacy implications on a wide scale, police presence being up and down etc. etc.
I would say XMPP may be the most widely-used chat protocol on the Internet. And it has many more uses, as it's a generic federated PubSub platform. Facebook, Whatsapp and many other popular proprietary solutions use the XMPP protocol. Even games and gaming platforms like League of Legends or Nintendo use XMPP. So do Firebase and others.
I'm not arguing in favor of these corporations. I'm a proponent of non-profit federated networks like the Jabber federation (based on XMPP protocol). Not that XMPP is better than ActivityPub/Matrix in all regards, but it has stable standards, rock-solid implementations with very good scaling stories, and there's a vibrant non-profit community working on:
- better, modern clients for chatting: Conversations, Dino.. - unified branding/UX across platforms with Snikket client/server distribution - social networking: Movim (web), salut-à-toi (multi-platform) - decentralized forging to replace github: salut-à-toi uses it for own development - onboarding people with prosody's mod_invite - federated chat over tor onion services with prosody's mod_onion
Matrix, SMTP and ActivityPub have other strong points going for them, but i could argue most of the Matrix criticism in the article does not apply to the Jabber ecosystem. Disclaimer: i'm a happy Jabber user and contributor to the https://joinjabber.org/ project (a new born in the ecosystem)
I'm not arguing in favor of these corporations. I'm a proponent of non-profit federated networks like the Jabber federation (based on XMPP protocol). Not that XMPP is better than ActivityPub/Matrix in all regards, but it has stable standards, rock-solid implementations with very good scaling stories, and there's a vibrant non-profit community working on:
- better, modern clients for chatting: Conversations, Dino.. - unified branding/UX across platforms with Snikket client/server distribution - social networking: Movim (web), salut-à-toi (multi-platform) - decentralized forging to replace github: salut-à-toi uses it for own development - onboarding people with prosody's mod_invite - federated chat over tor onion services with prosody's mod_onion
Matrix, SMTP and ActivityPub have other strong points going for them, but i could argue most of the Matrix criticism in the article does not apply to the Jabber ecosystem. Disclaimer: i'm a happy Jabber user and contributor to the https://joinjabber.org/ project (a new born in the ecosystem)
In my experience, IRC is more active than XMPP. I only get XMPP traffic from spammers and during open source conferences, whilst IRC is active daily.
Not nearly enough.
Based on some yearly port-scanning surveys [1], the developers of the Prosody XMPP server think there are over 50,000 servers running Prosody (out of a total of over 85,000 XMPP servers). There are a handful of large public servers and then what I imagine would be a very long tail of tiny private servers.
[1] https://blog.prosody.im/2020-retrospective/
Based on some yearly port-scanning surveys [1], the developers of the Prosody XMPP server think there are over 50,000 servers running Prosody (out of a total of over 85,000 XMPP servers). There are a handful of large public servers and then what I imagine would be a very long tail of tiny private servers.
[1] https://blog.prosody.im/2020-retrospective/
Email is another decentralized, distributed system that is often ignored. The only real difference between chat and email is that the interface makes it seem like chat is quicker. Nothing stops us from writing such interfaces for email as well, though.
For anyone wondering, there's https://delta.chat/en/. Discussed here days ago https://news.ycombinator.com/item?id=25893626.
I think some distinction is needed: The email protocol allows decentralization (in the sense of federation) and, theoretically, even full distribution if everyone were running their own mail server. But in practice, none of this is the case and email is one of the most heavily centralized systems humankind has come up with.
Back in 2016 I came across a computer science paper where the author had studied the decentralization vs. centralization phenomenon in various cases (not just in IT but also in real-life social networks, economic dependency graphs etc.) and concluded that every man-made decentralized system will eventually exhibit centralization to some degree as it will develop nodes that have orders of magnitude more edges than the average node. It seems to be a very natural phenomenon. I wish I remembered the author or the title…
Back in 2016 I came across a computer science paper where the author had studied the decentralization vs. centralization phenomenon in various cases (not just in IT but also in real-life social networks, economic dependency graphs etc.) and concluded that every man-made decentralized system will eventually exhibit centralization to some degree as it will develop nodes that have orders of magnitude more edges than the average node. It seems to be a very natural phenomenon. I wish I remembered the author or the title…
Yes, email and IM do have a lot in common -- in particular, XMPP is best visualized as an IMAP-like client/server protocol plus an SMTP-like server/server protocol that both share an XML schema (ugh) for describing the messages akin to how MIME (another ugh) functions for email.
As another commenter has pointed out, Delta.chat shows just how closely an email client can mimic the chat/IM interface.
As another commenter has pointed out, Delta.chat shows just how closely an email client can mimic the chat/IM interface.
One problem with email is that it lacks typing indicators, read receipt, and other niceties that people have become accustomed to. There can also be a bit of a delay between sending and receiving messages on different email providers.
Facebook messages are emails, I believe.
At least an email to the user's @Facebook email address gets picked up in messenger.
At least an email to the user's @Facebook email address gets picked up in messenger.
To easily get regular folks onboard you should recommand Quicksy (a Conversations spin off made by the same developper) :
https://play.google.com/store/apps/details?id=im.quicksy.cli...
It's as easy to use and to automatically recognize contacts as Whatsapp and Signal but it's federated to XMPP.
And people who don't use Quicksy host service can register to be easily recognize as a contact :
https://quicksy.im/#get-listed
https://play.google.com/store/apps/details?id=im.quicksy.cli...
It's as easy to use and to automatically recognize contacts as Whatsapp and Signal but it's federated to XMPP.
And people who don't use Quicksy host service can register to be easily recognize as a contact :
https://quicksy.im/#get-listed
You've commented at least 3 times pushing this service. From their home page:
> We charge a small fee to enter your Jabber ID and phone number into our directory. This cross financing allows us to make Quicksy completely free for its users. If you are a paying customer of the conversations.im hosting service, you can enter your number for free.
As stated on their home page, it's a fork of the Conversations (conversations.im) client with contact discovery which they're selling.
> Quicksy is a spin-off of the popular Jabber/XMPP client Conversations with automatic contact discovery.
So it's just a conversations.im client trying to make a buck with a contacts service based on what I can see. Edit: in context in case you didn't know, Matrix (at least via app.element.io -> vector.im) has a contact discovery service, and it already works with phone numbers and email addresses using a blind one-way lookup for privacy.
> We charge a small fee to enter your Jabber ID and phone number into our directory. This cross financing allows us to make Quicksy completely free for its users. If you are a paying customer of the conversations.im hosting service, you can enter your number for free.
As stated on their home page, it's a fork of the Conversations (conversations.im) client with contact discovery which they're selling.
> Quicksy is a spin-off of the popular Jabber/XMPP client Conversations with automatic contact discovery.
So it's just a conversations.im client trying to make a buck with a contacts service based on what I can see. Edit: in context in case you didn't know, Matrix (at least via app.element.io -> vector.im) has a contact discovery service, and it already works with phone numbers and email addresses using a blind one-way lookup for privacy.
This is a misunderstanding. Quicksy is free for anyone who signs up. And I'm not that commenter.
I'm surprised to hear xmpp on mobile works for people. I tried a few times with a friend. I'm on Android, she has an iPhone. And it always was too unreliable. The worst part is that half of the time messages are not delivered or very late. But there are also problems with attachments.
We tried different clients and servers.
Yes it works, there's a bunch of standards (XEPs) describing how a client/server should handle unreliable connections, push notifications, etc. However, not all servers respect these. If you're setting up your own, it's easy to enable though.
Also a problem is iOS clients. Developing on iOS requires lock-in into the Apple ecosystem and most XMPP folks are free-software people so nobody will bother to buy Apple hardware/software specifically to develop for their closed ecosystem (i.e. unpaid labor for a multi-billion corporation), although i'm sure a lot of folks would be happy to do just that if that was sponsored work (donations, grants).
On Android, Conversations (or its forks Quicksy/Snikket) is the best. ChatSecure on iOS has been buggy for years (every time i tried with someone with an iPhone), but nowadays Siskin appears to be a good iOS client, though i haven't had the hardware/system to try it myself.
Also a problem is iOS clients. Developing on iOS requires lock-in into the Apple ecosystem and most XMPP folks are free-software people so nobody will bother to buy Apple hardware/software specifically to develop for their closed ecosystem (i.e. unpaid labor for a multi-billion corporation), although i'm sure a lot of folks would be happy to do just that if that was sponsored work (donations, grants).
On Android, Conversations (or its forks Quicksy/Snikket) is the best. ChatSecure on iOS has been buggy for years (every time i tried with someone with an iPhone), but nowadays Siskin appears to be a good iOS client, though i haven't had the hardware/system to try it myself.
Isn't XMPP a horribly designed protocol and not very good for mobile devices, though?
I'm not someone implementing XMPP but I remember reading articles about it back in the day and I recall hearing that the consensus that it's not a good protocol for mobile. Mobile being probably 95% of messaging traffic.
I'm not someone implementing XMPP but I remember reading articles about it back in the day and I recall hearing that the consensus that it's not a good protocol for mobile. Mobile being probably 95% of messaging traffic.
The mobile problem for XMPP is solved since 2016 :
https://gultsch.de/xmpp_2016.html
https://gultsch.de/xmpp_2016.html
that leaves the problem of p2p being an overlay network and as such not being a solved problem for network operators (especially in wireless networks). http://www.spice-center.org/files/publications/90-305-1-PB.p...
Without the optimizations added since 2016, it is not a great protocol for mobile devices, but only because mobile devices are stupid and equate a background TCP connection with something bad and battery-heavy. That means they make it much more difficult (or impossible re: iOS) to do so.
That means apple & google are effectively dictating how you can use TCP (i.e. not outside of HTTP and friends), and everything is now terrible.
That means apple & google are effectively dictating how you can use TCP (i.e. not outside of HTTP and friends), and everything is now terrible.
> That means apple & google are effectively dictating how you can use TCP (i.e. not outside of HTTP and friends), and everything is now terrible.
Ok, but this is our reality. Windows has been the dominant desktop OS since 1995 or so (and MS-DOS was the one from 1985 until 1995 or so, from the same company).
Linux has been dominating the server space since about 2005 or so.
iOS and Android have dominated the mobile since about 2010.
I'm not holding my breath for any of these OSes disappearing from their niches before I die...
Ok, but this is our reality. Windows has been the dominant desktop OS since 1995 or so (and MS-DOS was the one from 1985 until 1995 or so, from the same company).
Linux has been dominating the server space since about 2005 or so.
iOS and Android have dominated the mobile since about 2010.
I'm not holding my breath for any of these OSes disappearing from their niches before I die...
I am not holding my breath either, and as I said, there are plenty of protocol optimizations which have been made to fit into that terrible state of things. To the point that Conversations, my Android XMPP client, uses less battery than Signal, despite seeing a lot more activity.
> if we keep inventing excuses
The article brings valid points that are not invented.
The article brings valid points that are not invented.
That's is so not what he says though. He says Matrix is not there yet, nowhere he says to give up.
there are 2 (maybe more?) ways in which matrix/riot (theoretically) could "compete[1]" against Signal, but are an utter failure on both accounts:
1) UE / ease of use for non-tech savvy users
2) a "killer feature" that gets people talking
While 1) is a no-brainer, 2) is a more difficult.
What does matrix offer to users other than "decentralization" (which is great for people on HN who like tinkering, but a usability drawback due to bootstrap time of joining a p2p network, and p2p in itself not offering a __security__ advantage[please ask to see the threat model when there are blanket claims that p2p is more secure]).
Signals claim to fame comes from actual subpoenae that returned no usable metadata. Matrix (so far) has never been tested in adversarial conditions[citation needed]. While matrix's e2ee is an often talked about feature, it is not part of most matrix-implementations. Only riot claims it does e2ee however the claims on voice security are vague. Not clear if p2p or multiparty voice are E2E encrypted. Also you can optionally encrypt text chat rooms (which means it's not the default and so it's either not used by non-tech savvy users and those who rely on it risk getting exposed due to the extra steps it takes).
I'm excited for decentralized technologies[3] but Riot is not in a state (yet) where I'd recommend it to exposed groups or individuals. So if neither e2ee is properly implemented, nor does it offer some radical new feature, nor is it actually more user-friendly - then why should anyone bother with it?
[1] compete = moderate attempt in getting a name for itself considering that Signal is stealing all the attention in comparison to all other "secure" messengers
[2] https://www.documentcloud.org/documents/3120046-Open-Whisper...
[3] cwtch: more bleeding edge than matrix, potentially buggy and certainly not ready for prime-time but they understand that: "your threat-model isn't my threat-model" https://docs.openprivacy.ca/cwtch-security-handbook/risk.htm...
1) UE / ease of use for non-tech savvy users
2) a "killer feature" that gets people talking
While 1) is a no-brainer, 2) is a more difficult.
What does matrix offer to users other than "decentralization" (which is great for people on HN who like tinkering, but a usability drawback due to bootstrap time of joining a p2p network, and p2p in itself not offering a __security__ advantage[please ask to see the threat model when there are blanket claims that p2p is more secure]).
Signals claim to fame comes from actual subpoenae that returned no usable metadata. Matrix (so far) has never been tested in adversarial conditions[citation needed]. While matrix's e2ee is an often talked about feature, it is not part of most matrix-implementations. Only riot claims it does e2ee however the claims on voice security are vague. Not clear if p2p or multiparty voice are E2E encrypted. Also you can optionally encrypt text chat rooms (which means it's not the default and so it's either not used by non-tech savvy users and those who rely on it risk getting exposed due to the extra steps it takes).
I'm excited for decentralized technologies[3] but Riot is not in a state (yet) where I'd recommend it to exposed groups or individuals. So if neither e2ee is properly implemented, nor does it offer some radical new feature, nor is it actually more user-friendly - then why should anyone bother with it?
[1] compete = moderate attempt in getting a name for itself considering that Signal is stealing all the attention in comparison to all other "secure" messengers
[2] https://www.documentcloud.org/documents/3120046-Open-Whisper...
[3] cwtch: more bleeding edge than matrix, potentially buggy and certainly not ready for prime-time but they understand that: "your threat-model isn't my threat-model" https://docs.openprivacy.ca/cwtch-security-handbook/risk.htm...
your evaluation is really out of date
https://matrix.org/blog/2020/02/01/on-privacy-versus-freedom...
Matrix on this topic and their view
Matrix on this topic and their view
This is mostly about anonymity. Signal is not really intended to provide anonymity. Most encrypted messaging is not intended to provide anonymity. That is because anonymity is harder to do than privacy and privacy is hard. Fortunately, most people do not need anonymity in their day to day lives. They just need to live in a country with good privacy laws to prevent the commercial exploitation of their data. So if you live in a place with little or no legal privacy protection like the USA things will be fundamentally different.
There are a bunch of XMPP servers running on Tor hidden services:
* https://gist.github.com/dllud/a46d4a555e31dfeff6ad41dcf20729...
... but the article talks about Matrix instead for some reason.
There are a bunch of XMPP servers running on Tor hidden services:
* https://gist.github.com/dllud/a46d4a555e31dfeff6ad41dcf20729...
... but the article talks about Matrix instead for some reason.
On the topic of anonymity I do like this stance:
> Just for the hell of it: Anonymity is fundamentally about removing context. You can't provide anonymity you can only provide protocols that endeavour to remove context. Attacks on anonymity system always come down to injecting or deriving context.
> In an adversarial environment (just so we are all on the same page, life is an adversarial environment), there are few limitations on the kinds of context attackers are allowed to inject or derive context from.
> No anonymity system is absolute because there is always context. The majority of my research in this space centers around the context that people add on top of robust protocols that ultimately undermine them. I'm interested in practical failures, not theoretical restrictions.
> Privacy will always been an active choice, not a passive tool. That doesn't make it impossible or out of reach or "dead", it makes it a fight worth fighting.
https://twitter.com/SarahJamieLewis/status/12737436308013711...
https://twitter.com/SarahJamieLewis Sarah Jamie Lewis @SarahJamieLewis Executive Director @OpenPriv
Anonymity hasn't the same requirements as secrecy does.
> Just for the hell of it: Anonymity is fundamentally about removing context. You can't provide anonymity you can only provide protocols that endeavour to remove context. Attacks on anonymity system always come down to injecting or deriving context.
> In an adversarial environment (just so we are all on the same page, life is an adversarial environment), there are few limitations on the kinds of context attackers are allowed to inject or derive context from.
> No anonymity system is absolute because there is always context. The majority of my research in this space centers around the context that people add on top of robust protocols that ultimately undermine them. I'm interested in practical failures, not theoretical restrictions.
> Privacy will always been an active choice, not a passive tool. That doesn't make it impossible or out of reach or "dead", it makes it a fight worth fighting.
https://twitter.com/SarahJamieLewis/status/12737436308013711...
https://twitter.com/SarahJamieLewis Sarah Jamie Lewis @SarahJamieLewis Executive Director @OpenPriv
Anonymity hasn't the same requirements as secrecy does.
Element/Matrix/Gitter is a great IRC-replacement and public chat, Mastodon is great as a decentralized Twitter alternative, IPFS is great for decentralized public file sharing. Default-public services like this probably have an easier time being decentralized. It'd actually be nice to see thoughtful integrations between these three IMO.
The greatest advantage Signal has is probably doing same-day updates for all clients while being dead simple to use well. A decentralized protocol could achieve these things, but none have yet. Still I hope someday soon we can have everything be decentralized, but like the blog post says, we can't let the perfect be the enemy of the good.
The greatest advantage Signal has is probably doing same-day updates for all clients while being dead simple to use well. A decentralized protocol could achieve these things, but none have yet. Still I hope someday soon we can have everything be decentralized, but like the blog post says, we can't let the perfect be the enemy of the good.
> Mastodon is great as a decentralized Twitter
Federated, not decentralized. Decentralized is peer2peer like torrents. Federated is like email where there are little fiefdoms like Gmail, yahoo, or self-hosted.
Federated, not decentralized. Decentralized is peer2peer like torrents. Federated is like email where there are little fiefdoms like Gmail, yahoo, or self-hosted.
that definition seems like a bit of a stretch: decentralized does not mean anything more than not being centralized.
Federation implies decentralization.
> Federation implies decentralization.
No it doesn’t. Gmail is a centralized instance of a federated network.
You can have a federated node that becomes so popular that it’s basically centralized.
This federated/decentralized distinction is pretty common.
You’re dwelling on literal definitions but there are more semantic differences those words have picked up in the communities involved.
No it doesn’t. Gmail is a centralized instance of a federated network.
You can have a federated node that becomes so popular that it’s basically centralized.
This federated/decentralized distinction is pretty common.
You’re dwelling on literal definitions but there are more semantic differences those words have picked up in the communities involved.
Be kinder, these semantics differences are newer(ish) developments and not everyone knows the area. It's a bit confusing to say federation does imply decentralization point blank.
For a long time, federated architecture was seen as special case of decentralized, for example in designing stuff for internal use. It still makes sense in that context.
In the context of larger external facing systems, I've found it useful to think of federated as "partly decentralized", and "decentralized" is short-hand for "fully decentralized".
For a long time, federated architecture was seen as special case of decentralized, for example in designing stuff for internal use. It still makes sense in that context.
In the context of larger external facing systems, I've found it useful to think of federated as "partly decentralized", and "decentralized" is short-hand for "fully decentralized".
Federation is decentralized. Peer-to-peer is distributed.
OK. How can you guarantee that your favorite three-letter agency does not have an agreement with Signal, so they can MITM you transparently, or deliver a custom-built app to you? Trustless is the only way to fly. I don’t need to trust any central authority to pay someone with Bitcoin or other cryptocurrencies. Why should I trust someone to route my messages?
It is actually possible because Signal is
1. Open source. 2. Has verifiable builds (just being open source isn't enough). 3. Uses end to end encryption.
You need all three of those to get what you want. Also you need to spend a ton of time building Signal from source and auditing it, which I doubt you're going to bother with but at least in theory it is possible.
1. Open source. 2. Has verifiable builds (just being open source isn't enough). 3. Uses end to end encryption.
You need all three of those to get what you want. Also you need to spend a ton of time building Signal from source and auditing it, which I doubt you're going to bother with but at least in theory it is possible.
[deleted]
4. Verification
> so they can MITM you
They can't, provided you verify the (reproducible) builds you download from the app store and check your verification codes.
Besides, it would be rather difficult for Signal to target just you and hand-deliver a custom build to you – Apple/Google would have to in on this, too. And if you use a Play Store alternative like the Aurora Store with a random Google account, this wouldn't work, either.
> Why should I trust someone to route my messages?
Unless you want to put the cables in the ground yourself and run the entire internet's infrastructure on your own, you'll always have to trust someone.
They can't, provided you verify the (reproducible) builds you download from the app store and check your verification codes.
Besides, it would be rather difficult for Signal to target just you and hand-deliver a custom build to you – Apple/Google would have to in on this, too. And if you use a Play Store alternative like the Aurora Store with a random Google account, this wouldn't work, either.
> Why should I trust someone to route my messages?
Unless you want to put the cables in the ground yourself and run the entire internet's infrastructure on your own, you'll always have to trust someone.
Most of these criticisms are solvable problems.
If you make a direct connection to other users, they see your IP address. So use Tor or a VPN.
Many P2P lookup systems assign identifiers for routing etc. So assign ephemeral ones for anything that doesn't need a persistent one, and make sure persistent ones aren't suitable for correlation, either by not using the same identifier for multiple services by the same person, or by using the same identifier for multiple services operated by a large number of unrelated people, or both.
If you make a direct connection to other users, they see your IP address. So use Tor or a VPN.
Many P2P lookup systems assign identifiers for routing etc. So assign ephemeral ones for anything that doesn't need a persistent one, and make sure persistent ones aren't suitable for correlation, either by not using the same identifier for multiple services by the same person, or by using the same identifier for multiple services operated by a large number of unrelated people, or both.
This response has been written a thousand times, but here goes again...
Using a VPN or Tor is not a viable option for the average person.
Using a VPN or Tor is not a viable option for the average person.
Using TCP/IP used to not be a viable option for the average person either?
Sure, but what about in 1992?
How much did you need to understand about TCP/IP when you got AOL? Very little.
And what happened when you got online? You could communicate online, suddenly reaching millions and then billions of humans. So learning just a little bit about IP (let's be real, you didn't need to know shit about TCP)
Compare that to a VPN or Tor. What do you need to understand to use it, and what is the payoff for knowing it? It's nowhere near the same situation as IP and the beginning of consumer internet.
How much did you need to understand about TCP/IP when you got AOL? Very little.
And what happened when you got online? You could communicate online, suddenly reaching millions and then billions of humans. So learning just a little bit about IP (let's be real, you didn't need to know shit about TCP)
Compare that to a VPN or Tor. What do you need to understand to use it, and what is the payoff for knowing it? It's nowhere near the same situation as IP and the beginning of consumer internet.
Yep all it took was some usability products and it was easier... See what I'm saying...
In this case centralization is the usability, just like AOL centralized internet access options for users? Maybe you're unfamiliar with AOL in the beginning but it was largely a walled garden that happened to have a web browser.
Centralisation didn't make it easier to use, ask yourself why AOL was in every household
I don't think it is comparable. In my opinion it would be comparable to if e-mail required you to be on the same server as your friends or you couldn't e-mail them OR to have compatible servers that could communicate across different protocols, which is a run to the bottom just as in e-mail where adding new security and removing legacy is near impossible.
> to have compatible servers that could communicate across different protocols, which is a run to the bottom just as in e-mail where adding new security and removing legacy is near impossible.
TLS was not in the original email RFC. Such a high percentage of email servers use it now that some have started refusing to communicate with ones that don't. And long before 100.0% of email servers support TLS, you can still use it whenever it's supported by the servers of the sender and recipient.
The DNS RFCs contain a specification for zone transfers, i.e. requesting all the DNS records in the zone instead of any given one. Some people don't like the idea of anybody being able to download their entire zone, and it was always a silly way to sync zones between DNS servers as opposed to using e.g. rsync, so most DNS servers on the internet refuse to do it and a lot of DNS server software doesn't even implement it. But the people still using it internally for whatever silly reason can carry on doing so indefinitely without hurting anybody else.
Nobody cares about the legacy cruft that nobody they care about uses. What having central control gets you is the ability to decree from the tower that something some people are still using shall be removed for everyone everywhere. That can be more of a bug than a feature.
The biggest actual problem with protocol ossification is stupid network middleboxes that manipulate or drop traffic and then break on protocol changes they don't understand. The way to fix this is for future protocols to be encrypted so the middleboxes can't mess with it.
TLS was not in the original email RFC. Such a high percentage of email servers use it now that some have started refusing to communicate with ones that don't. And long before 100.0% of email servers support TLS, you can still use it whenever it's supported by the servers of the sender and recipient.
The DNS RFCs contain a specification for zone transfers, i.e. requesting all the DNS records in the zone instead of any given one. Some people don't like the idea of anybody being able to download their entire zone, and it was always a silly way to sync zones between DNS servers as opposed to using e.g. rsync, so most DNS servers on the internet refuse to do it and a lot of DNS server software doesn't even implement it. But the people still using it internally for whatever silly reason can carry on doing so indefinitely without hurting anybody else.
Nobody cares about the legacy cruft that nobody they care about uses. What having central control gets you is the ability to decree from the tower that something some people are still using shall be removed for everyone everywhere. That can be more of a bug than a feature.
The biggest actual problem with protocol ossification is stupid network middleboxes that manipulate or drop traffic and then break on protocol changes they don't understand. The way to fix this is for future protocols to be encrypted so the middleboxes can't mess with it.
Why? You download a single program, run it, it unlocks forbidden content. There is nothing in this flow that people way below average already can't do.
[deleted]
Tor can be embedded into an application. Sadly, the service quality over Tor would be much worse than over a regular Internet connection.
So can VPN's! There is a reason why Opera still has market share in some countries.
Using a VPN given to you by a service provider from whom you are trying to hide your IP seems to not achieve the goal.
Letting users select their own VPN before using your service is too much friction. The advantage of Tor is that it's run by multiple parties and does not need any interactive setup.
Letting users select their own VPN before using your service is too much friction. The advantage of Tor is that it's run by multiple parties and does not need any interactive setup.
What if the Tor connection is built into the app and enabled by default.
That is however just another layer of complexity when the article already talks about the complexity of running a matrix server.
Running a Matrix server is complex because the software could be better, not from some inherent user-facing complexity.
Encouraging users to use a VPN can be as simple as bundling the WireGuard installer with your software and providing a list of recommended non-shady VPN providers.
This makes things less complicated for the user, because they benefit from having a VPN whether they use your software or not (to hide their current IP address from any centralized services they still use), but now they have someone they trust providing a vetted selection of them to choose from. And on top of that it gives a free software developer the opportunity to fund some development through the use of affiliate links.
Encouraging users to use a VPN can be as simple as bundling the WireGuard installer with your software and providing a list of recommended non-shady VPN providers.
This makes things less complicated for the user, because they benefit from having a VPN whether they use your software or not (to hide their current IP address from any centralized services they still use), but now they have someone they trust providing a vetted selection of them to choose from. And on top of that it gives a free software developer the opportunity to fund some development through the use of affiliate links.
The article never claimed they are impossible to solve.
It even mentions Tor.
You seem to trying to argue something different than what the article is actually about.
It even mentions Tor.
You seem to trying to argue something different than what the article is actually about.
> The article never claimed they are impossible to solve.
If they aren't impossible to solve then why should we not just solve them instead of abandoning decentralization?
If they aren't impossible to solve then why should we not just solve them instead of abandoning decentralization?
What about Matrix over I2P? Seems like an ideal pairing, especially since Matrix' robust history syncing may combine nicely with i2p delayed forwarding and other advanced traffic mixing strategies.
> The advantages of P2P are undeniable and profound, but few are effectively addressing the privacy implications. The one I know of that is, Briar, routes all traffic over Tor; every node is reached by a Tor onion service.
Bisq (p2p exchange) does the same thing.
Bisq (p2p exchange) does the same thing.
Between inefficient and bad for privacy P2P DHTs and completely centralized or federated models from which you can be banned very easily, there exists a solution that takes the best of both worlds: https://github.com/fiatjaf/nostr.
Basically it works like this:
> Everybody runs a client. It can be a native client, a web client, etc. To publish something, you write a post, sign it with your key and send it to multiple relays (servers hosted by someone else, or yourself). To get updates from other people, you ask multiple relays if they know anything about these other people. Anyone can run a relay. A relay is very simple and dumb. It does nothing besides accepting posts from some people and forwarding to others. Relays don't have to be trusted. Signatures are verified on the client side.
Basically it works like this:
> Everybody runs a client. It can be a native client, a web client, etc. To publish something, you write a post, sign it with your key and send it to multiple relays (servers hosted by someone else, or yourself). To get updates from other people, you ask multiple relays if they know anything about these other people. Anyone can run a relay. A relay is very simple and dumb. It does nothing besides accepting posts from some people and forwarding to others. Relays don't have to be trusted. Signatures are verified on the client side.
Why compare the privacy implications of IPFS and Signal? They are intended for entirely different purposes.
The Article compares p2p vs centralized and uses IPFS as an example and signal as the other example. Both distribute information. True this is a high level perspective...
> "Signal brings encryption and privacy to meet people where they’re at, not the other way around. People don’t have to choose a server, it can automatically recognize contacts that use Signal, it has emojis, attachments, secure voice and video calling, and (aside from the Musk incident), it all just works. It feels like, and is, a polished, modern experience with the bells and whistles people are used to."
Quicksy offer EXACTLY the same functionalities but it's federated and standardized, based on XMPP : you can discuss with people that are not using Quicksy and its services, people outside Quicksy even can link their address to their phone to make it automatically recognize as contacts using quicksy/XMPP : https://quicksy.im/#get-listed
And instead of Matrix, Quicksy IT IS THERE YET :
https://play.google.com/store/apps/details?id=im.quicksy.cli...
Quicksy offer EXACTLY the same functionalities but it's federated and standardized, based on XMPP : you can discuss with people that are not using Quicksy and its services, people outside Quicksy even can link their address to their phone to make it automatically recognize as contacts using quicksy/XMPP : https://quicksy.im/#get-listed
And instead of Matrix, Quicksy IT IS THERE YET :
https://play.google.com/store/apps/details?id=im.quicksy.cli...
The author specifically criticizes IPFS and others, who do not care for privacy, and rightly so. However, this is not inherent to the technology. There are others who do, such as https://gnunet.org
Also worth noting: https://briarproject.org
A great talk by Moxie on this very topic: https://www.youtube.com/watch?v=Nj3YFprqAr8&
Note that due to the way APNS works, the notifications path on things like Element/Matrix, as well as XMPP/etc must be centralized with the (iOS) app developer anyway, even if the server isn’t.
All apps that require a phone number are a scam, privacy-wise. Use Matrix.
What does "scam" even mean here? I know what I'm signing up for, privacy-wise, when I provide Signal my phone number and access to some of my contacts, and I clearly get something in exchange.
I would not call passing phone numbers (or reversivle hashes thereof) of my friends to a third part a scam. I would call it treason.
Why are you providing your phone number to anyone? Software should be free.
Signal is GPLv3 software, so it is free as in freedom.
I prefer free/libre software as well. I'm really not trying to sound inane when I say that I provide my phone number for the same reason I provide my phone number directly to my friends with whom I would like to communicate. It allows people I know to identify me among the billions of other people who have phone numbers.
To repeat my question, how are apps that require a phone number scamming users?
To repeat my question, how are apps that require a phone number scamming users?
> All apps that require a phone number are a scam, privacy-wise. Use Matrix.
…and leak my message content, IP address and social network to everyone who cares to look? You're making a very broad claim here and implicitly assume a very specific threat model. I can come up with dozens of other threat models that are more relevant to me and everyone I know and that completely invalidate your statement.
…and leak my message content, IP address and social network to everyone who cares to look? You're making a very broad claim here and implicitly assume a very specific threat model. I can come up with dozens of other threat models that are more relevant to me and everyone I know and that completely invalidate your statement.
> …and leak my message content, IP address and social network to everyone who cares to look
Would you care detailing this?
- Private conversations are E2EE by default now, group chats can be E2EE.
- IP addresses are not leaked except when videoconferencing. This is also the case on Signal, mind you, unless you opt-in to use their proxy in the settings.
- Social networks? Care to explain that?
- Who is everyone? Your server admin? Your ISP? Someone MITMing your HTTPS connections?
I do not doubt the rest of your post, but the above criticism is just unfair, given what I know of the Matrix protocol. Of course, I could be mistaken.
Would you care detailing this?
- Private conversations are E2EE by default now, group chats can be E2EE.
- IP addresses are not leaked except when videoconferencing. This is also the case on Signal, mind you, unless you opt-in to use their proxy in the settings.
- Social networks? Care to explain that?
- Who is everyone? Your server admin? Your ISP? Someone MITMing your HTTPS connections?
I do not doubt the rest of your post, but the above criticism is just unfair, given what I know of the Matrix protocol. Of course, I could be mistaken.
A bit annoying how servers meant to be run by people themselves are written in awfully slow languages. Python for matrix server is a terrible choice. Even worse for home assistant.
If it can't fit on raspberry pi it's useless.
If it can't fit on raspberry pi it's useless.
I see this bike-shedding comment about the language choice for the reference Matrix server implementation in every single post about Matrix on Hackernews. Every. Single One.
Millions of people use Matrix. It has been adopted by the French civil service, several German states, and the German armed forces. In a previous post I saw someone saying that American Airlines was looking at adopting Matrix for their employees.
I assure you that whether or not the reference Matrix server runs well on a raspberry pi did not factor into the decision making process that these organizations used when they picked Matrix.
Millions of people use Matrix. It has been adopted by the French civil service, several German states, and the German armed forces. In a previous post I saw someone saying that American Airlines was looking at adopting Matrix for their employees.
I assure you that whether or not the reference Matrix server runs well on a raspberry pi did not factor into the decision making process that these organizations used when they picked Matrix.
> It has been adopted by the French civil service, several German states, and the German armed forces. In a previous post I saw someone saying that American Airlines was looking at adopting Matrix for their employees.
Do you really think "but enterprise organizations don't mind running it" is a great argument? By that measure, JIRA is also perfect software :D
I know plenty of places running their own Matrix servers, and while it's certainly not unusable (proven by the fact that they keep running it), it's a common refrain among their admins that Synapse is one of the more annoying pieces of software they run in their infrastructure. That's not "bikeshedding", but operational experience, which has an impact on if it's recommended or not. See also the ... varying ... quality of matrix's bridges to other ecosystems, even the ones that are provided officially by the Matrix project. So yes, there are actual issues with Synapse performance - "rewrite it in Rust!!111" is of course not necessarily the correct response :D
Do you really think "but enterprise organizations don't mind running it" is a great argument? By that measure, JIRA is also perfect software :D
I know plenty of places running their own Matrix servers, and while it's certainly not unusable (proven by the fact that they keep running it), it's a common refrain among their admins that Synapse is one of the more annoying pieces of software they run in their infrastructure. That's not "bikeshedding", but operational experience, which has an impact on if it's recommended or not. See also the ... varying ... quality of matrix's bridges to other ecosystems, even the ones that are provided officially by the Matrix project. So yes, there are actual issues with Synapse performance - "rewrite it in Rust!!111" is of course not necessarily the correct response :D
Its a valid comment. I tried to run synapse on a reasonable VM and it was unusably slow. Essentially you either use the main server or you are a large org that can pay for a powerful machine to run it. The average person can not run a matrix server.
> The average person can not run a matrix server.
Please don't repeat falsehoods like this. The average person can not run anything because software is black magic to them. If you meant the average knowledgeable computer engineer (or similar, as opposed to a large org), then you are simply wrong.
I'm running a Synapse instance for ~25 people (friends and family). We are federated and joined to many large rooms. Synapse is using about 400-600M memory (RSS, varies depending on circumstances) and about 8-10% CPU. This is all on a 2 core Hetzner VPS which costs less than 20 USD per month.
Please don't repeat falsehoods like this. The average person can not run anything because software is black magic to them. If you meant the average knowledgeable computer engineer (or similar, as opposed to a large org), then you are simply wrong.
I'm running a Synapse instance for ~25 people (friends and family). We are federated and joined to many large rooms. Synapse is using about 400-600M memory (RSS, varies depending on circumstances) and about 8-10% CPU. This is all on a 2 core Hetzner VPS which costs less than 20 USD per month.
“Please don't repeat falsehoods like this.”
You accuse the parent commenter of making a falsehood, but then you go on to confirm their statement as true.
You accuse the parent commenter of making a falsehood, but then you go on to confirm their statement as true.
> Essentially you either use the main server or you are a large org that can pay for a powerful machine to run it.
To be perfectly clear, the above was the original statement I was referring to and it is completely false.
To be perfectly clear, the above was the original statement I was referring to and it is completely false.
That statement isn’t strictly true in the most literal sense, but neither is it a clear falsehood, specially given that it is prefixed with the word ‘essentially’, meaning that it is a generalization.
It’s also not going to remain true over time.
But it’s not a false characterization in practical terms for most people.
It’s also not going to remain true over time.
But it’s not a false characterization in practical terms for most people.
I'm saying it's not true in the general case either. In fact, taking into account other things I've said, my claim is that Synapse can easily run on a home computer or a relatively cheap/weak VPS.
In what sense is it then true that you have to be a large organization and have a powerful machine to be able to run it?
In what sense is it then true that you have to be a large organization and have a powerful machine to be able to run it?
The fact that you are disputed in saying this by multiple comments on this thread suggests it’s not as simple as just accusing someone of spreading falsehoods.
Here is a quote:
“speaking as the project lead for Matrix.
1. It's true that Synapse can use a lot of RAM.”
Here is a quote:
“speaking as the project lead for Matrix.
1. It's true that Synapse can use a lot of RAM.”
I was not contesting that, I was contesting the claim that you have to be a large organization and/or have a lot of money to be able to run Synapse. This is untrue. Stop moving the goalposts.
This has not been my experience. I run three servers in separate VMs on a Lenovo T420 laptop. These laptops run for about $200USD on Ebay though you'll need to upgrade the ram and the HDD to an SSD, so the cost is about $300USD.
Do you federate or these are silos for few users?
The three servers are federated with each other and the one of them is federated to the broader matrix.org network.
I've found that loading the larger rooms from the matrix.org network can cause a bit of lag for the few dozen or so users on my servers but once the rooms have synced up that issue goes away.
I don't administer the servers personally so I don't know exactly what the issue is but I have a feeling it's due to the limited ram that is provisioned to the VMs running the instances of synapse as there are many other VMs running on that same laptop.
If the instances of Synapse were the only things running on the laptop and they had 12gb of ram each (1/3 the total 32gb limit of the laptop) I would imagine that this issue would go away.
I've found that loading the larger rooms from the matrix.org network can cause a bit of lag for the few dozen or so users on my servers but once the rooms have synced up that issue goes away.
I don't administer the servers personally so I don't know exactly what the issue is but I have a feeling it's due to the limited ram that is provisioned to the VMs running the instances of synapse as there are many other VMs running on that same laptop.
If the instances of Synapse were the only things running on the laptop and they had 12gb of ram each (1/3 the total 32gb limit of the laptop) I would imagine that this issue would go away.
Is seems that this just helps the argument of how inefficient Synapse is. 12GB ram is quite beefy server. the issue is that when you want to federate your server needs to be able to handle similar loads as the server you are federating with....
So not like email where you can have tiny server and still be part if the network.
So not like email where you can have tiny server and still be part if the network.
You're right, let me explain my perspective.
I have an old laptop running a bunch of different services, three of which are matrix servers. The matrix servers generally run fine with the modest amount of ram provisioned to them (2-4GB IIRC) with the exception of hiccups that occur when a user joins large federated rooms (we're talking several thousand users) and these hiccups only last for a few seconds and until the room has finished syncing to my server. The hiccups manifest as "Unable to connect to server" messages on clients which only delays messages from being transmitted to the server by a few seconds.
From my understanding once a single user has joined these rooms and triggered the server side sync these hiccups will not happen again once another user on my server joins the same rooms as the data is already synced on the server. Furthermore there are relatively few rooms that have the number of users necessary (1000s) to trigger the issue one time join issue.
To remedy this issue and for general network reorganization purposes I intend to migrate non-synapse VMs off of the laptop and onto other hardware and then I would simply delegate the old laptop for the matrix servers and scale the three VMs to give them 1/3 of the available ram whether they need it or not. I mispoke last night when I said 12gb by the way, as the laptop only holds 32gb ram so the available ram could be (32 - (ram for hypervisor) / 3)
To bring it all back to the thing I care most about which is the over all cost, if the laptop cost $300USD and I run 3 servers on it my hardware cost per server is $100 which I consider to be trivial. This is 20 cups of fancy coffee and more importantly many hobbyists already have a spare laptop sitting around or can find one for quite an affordable price.
I hope this clarifies my comment.
I have an old laptop running a bunch of different services, three of which are matrix servers. The matrix servers generally run fine with the modest amount of ram provisioned to them (2-4GB IIRC) with the exception of hiccups that occur when a user joins large federated rooms (we're talking several thousand users) and these hiccups only last for a few seconds and until the room has finished syncing to my server. The hiccups manifest as "Unable to connect to server" messages on clients which only delays messages from being transmitted to the server by a few seconds.
From my understanding once a single user has joined these rooms and triggered the server side sync these hiccups will not happen again once another user on my server joins the same rooms as the data is already synced on the server. Furthermore there are relatively few rooms that have the number of users necessary (1000s) to trigger the issue one time join issue.
To remedy this issue and for general network reorganization purposes I intend to migrate non-synapse VMs off of the laptop and onto other hardware and then I would simply delegate the old laptop for the matrix servers and scale the three VMs to give them 1/3 of the available ram whether they need it or not. I mispoke last night when I said 12gb by the way, as the laptop only holds 32gb ram so the available ram could be (32 - (ram for hypervisor) / 3)
To bring it all back to the thing I care most about which is the over all cost, if the laptop cost $300USD and I run 3 servers on it my hardware cost per server is $100 which I consider to be trivial. This is 20 cups of fancy coffee and more importantly many hobbyists already have a spare laptop sitting around or can find one for quite an affordable price.
I hope this clarifies my comment.
Because nobody except for HN commenters cares what lamguage it's written in. It's about as easy to use and flexible as it gets so development is fast and people can contribute easily and it's entirely fast enough if you run it on reasonable hardware (for proof see other comments around here).
The fact that it doesn't run on your toaster is probably a feature, not a bug. To get it running on a Pi, even if written in a compiled language, things would have to be stripped down, making the overall software worse - a for what reason?
Running a Matrix server on a Pi in your closet is about the worst thing you can do. It's slow, unstable, has zero redundancy, needs constant maintenance, is physically in your home, on a residential connection.... If the point were for users to run this themselves, something like a local NAS (Synology has 1-click apps, I believe) would be the lowest-end reasonable option, but the whole idea of running your own Matrix server at home is insane! At the very least, it should have basic redundancy for uplink, data and power, which are already near-impossible to achieve at home.
And why should servers hosted by individuals? That would be horribly wasteful and inefficient, as well as raising the bar for users. I'll guarantee you that anyone who has enough skill and experience running and maintaining servers will have more than just a Pi available to them and anyone who doesn't have that experience should really not be running such an important service themselves.
The fact that it doesn't run on your toaster is probably a feature, not a bug. To get it running on a Pi, even if written in a compiled language, things would have to be stripped down, making the overall software worse - a for what reason?
Running a Matrix server on a Pi in your closet is about the worst thing you can do. It's slow, unstable, has zero redundancy, needs constant maintenance, is physically in your home, on a residential connection.... If the point were for users to run this themselves, something like a local NAS (Synology has 1-click apps, I believe) would be the lowest-end reasonable option, but the whole idea of running your own Matrix server at home is insane! At the very least, it should have basic redundancy for uplink, data and power, which are already near-impossible to achieve at home.
And why should servers hosted by individuals? That would be horribly wasteful and inefficient, as well as raising the bar for users. I'll guarantee you that anyone who has enough skill and experience running and maintaining servers will have more than just a Pi available to them and anyone who doesn't have that experience should really not be running such an important service themselves.
They're working on a Go server impl, "Dendrite" which is supposed to be far faster and use less RAM.
I was hoping for Rust, and I think there is a 3rd-party Rust server, but anything's better than Python. Node.js would probably be better than Python.
I was hoping for Rust, and I think there is a 3rd-party Rust server, but anything's better than Python. Node.js would probably be better than Python.
The 3rd party Rust server is Conduit: https://conduit.rs
> Note: This project is work-in-progress and is still missing some features like joining private rooms over federation
I'm hopeful it will get there somewhere, but I hestitate to recommend it while "easy to get working without issues" is a bar that it doesn't yet reach.
I'm hopeful it will get there somewhere, but I hestitate to recommend it while "easy to get working without issues" is a bar that it doesn't yet reach.
https://github.com/matrix-org/dendrite
/aside: this is a curious comment in their readme:
"A PostgreSQL database engine, which will perform better than SQLite with many users and/or larger rooms"
/aside: this is a curious comment in their readme:
"A PostgreSQL database engine, which will perform better than SQLite with many users and/or larger rooms"
I can't take any of these server Python projects seriously. It's like mocking up a car in styrofoam and then just...releasing that mockup as the actual product.
Ah yes, all those styrofoam cars such as Instagram, Reddit, Bitbucket, Eventbrite.....
Notice how the load balancers, databases, and caching layers at those places are _not_ written in Python. They then have to run a wasteful amount of instances to keep their Python services afloat. Modern computers can do an amazing amount of work in a given time slice, but it's a shame when so much of that is thrown away because someone decided to implement it in Python.
Yes, because those layers aren't theirs. They are products of other companies that specialise in high-performance and stable software. They can afford to use annoying languages because performance is one of the main things they compete on.
But for something like a social network, performance isn't something they care about. They care about being able to develop and roll out new features as fast as possible. The overhead of working in a language makes things hard and/or has poor tooling is far greater than the increased server cost of working in something like Python (or, as much as I hate to admit it, Node).
(note, that I'm not talking about the client side here. developers should serve their users and a slow fronted is bad for users. a slow backend, however, is not something users care about)
And since we're specifically talking about an open source project here, look at the difference in community contributions between any two equally popular projects where one is written in something ridiculous like C++ and the other in JavaScript.
Even Go and Rust, which are as close to modern as it gets in the world of compiled languages, are still decades behind Java, Python and Node in features, tooling and support. So until those catch up, anything that doesn't need performance above all else is probably going to stick to more friendly languages and not lose sleep about wasted CPU cycles - after all, we built computers specifically to simplify our work and that's exactly what these languages are doing.
But for something like a social network, performance isn't something they care about. They care about being able to develop and roll out new features as fast as possible. The overhead of working in a language makes things hard and/or has poor tooling is far greater than the increased server cost of working in something like Python (or, as much as I hate to admit it, Node).
(note, that I'm not talking about the client side here. developers should serve their users and a slow fronted is bad for users. a slow backend, however, is not something users care about)
And since we're specifically talking about an open source project here, look at the difference in community contributions between any two equally popular projects where one is written in something ridiculous like C++ and the other in JavaScript.
Even Go and Rust, which are as close to modern as it gets in the world of compiled languages, are still decades behind Java, Python and Node in features, tooling and support. So until those catch up, anything that doesn't need performance above all else is probably going to stick to more friendly languages and not lose sleep about wasted CPU cycles - after all, we built computers specifically to simplify our work and that's exactly what these languages are doing.
You may want to look at Dendrite which is an alternative implementation that is being developed. It's implemented in Go, and is supposedly a lot lighter on system resources.
https://matrix.org/docs/projects/server/dendrite
https://matrix.org/docs/projects/server/dendrite
Python shouldn't be blamed here, because the real reason that the Matrix homeserver is so slow is due to fundamental protocol design issues. It doesn't matter what language you write it in, it's going to be a resource hog by design.
Python is slow as dirt. If the protocol is heavy, all the more reason a more efficient language should be used.
This is all a bit depressing, speaking as the project lead for Matrix.
1. It's true that Synapse can use a lot of RAM.
- The biggest cause of this is due to spikes in RAM during state resolution (the merge resolution algorithm used to converge your server's view of a room with the other servers in a room), which Python doesn't always recover nicely. We fixed the main cause of this in Synapse 1.26, which was released on Wednesday: https://github.com/matrix-org/synapse/issues/8622 is interesting reading on the details.
- Another cause is that by default we cache a lot of data in RAM in order to avoid hammering the DB. Currently you have to manually tune the size of that cache, which should be done automatically - we're hoping to get to this shortly.
- The other main cause is that the resource requirements depends on the complexity of the rooms its users participate in, not the number of users on the server. So a single user server can use serious RAM if that one user goes and joins a bunch of busy rooms with hundreds of thousands of users in them. This can be surprising to sysadmins, and we haven't figured out a good way of solving it other than just keeping making Synapse go faster.
- Finally, even though we're continuing to polish Synapse hard, we're also working on Dendrite, which uses roughly 5x less RAM than Synapse (thanks to relying on the DB for caching, using a smarter DB schema; passing all strings around as enums called NIDs, and Go's GC being smarter than Python's). For instance, dendrite.matrix.org uses a relatively stable 480MB of RAM, despite being in thousands of rooms spanning tens of thousands of users. It's still beta, but progressing fast.
2. In terms of choosing a Matrix server: "Well, you could just tell a person to use matrix.org. But then it spent a good portion of last year unable to federate with other popular nodes due to Synapse limitations." - yes, at the beginning of 2020 we hit a performance ceiling on Synapse on matrix.org which caused federation to fall behind during heavy traffic. *So we fixed it*. https://matrix.org/blog/2020/11/03/how-we-fixed-synapses-sca... has the details. Meanwhile, more and more other folks are spinning up reliable Matrix providing services.
3. In terms of "Voice and video calling are not there yet in Matrix", again: we've been working our asses off to fix this. Since September we've had a dedicated fulltime VoIP team going through reworking 1:1 VoIP, implementing the work at https://github.com/matrix-org/matrix-doc/blob/dbkr/msc2746/p.... This has been landing over the last few weeks (although there's still some stuff left), but it should already be noticeably more robust. Meanwhile, integration to Jitsi for video conferencing has also improved a bunch - we're counting on it for running FOSDEM next weekend, after all. In terms of NAT: yes, you have to correctly set up a TURN server. We're building https://github.com/matrix-org/voip-tester to help folks test that they've got it right.
4. "Matrix is so hard to set up on a server that there is matrix-docker-ansible-deploy". This is bogus, imo. The ansible project is useful if you want to quickly run tonnes of bridges without understanding how to admin them, but for a typical Matrix server you should be able to `pip install matrix-synapse` and off you go. It's a fair point that Synapse doesn't yet ship with an admin tool, just an admin API, but there are folks filling this gap (https://github.com/Awesome-Technologies/synapse-admin is good).
5. "Encryption isn’t mandatory in Matrix". This is because, unlike Signal, Matrix supports public chatrooms. It makes *NO* sense to end-to-end encrypt a public chatroom which by definition is intended to be indexed and visible and smeared all over the wider world. All it would do is waste significant CPU on the clients, and hit up against resource limits given how large public chatrooms can get. Meanwhile, all private conversations are E2EE by default, assuming your client supports E2EE.
TL;DR: It feels like we're being judged on Matrix as it was in early 2020, ignoring all the sprinting we've been doing throughout the last year to address these criticisms, so it's all rather frustrating.
1. It's true that Synapse can use a lot of RAM.
- The biggest cause of this is due to spikes in RAM during state resolution (the merge resolution algorithm used to converge your server's view of a room with the other servers in a room), which Python doesn't always recover nicely. We fixed the main cause of this in Synapse 1.26, which was released on Wednesday: https://github.com/matrix-org/synapse/issues/8622 is interesting reading on the details.
- Another cause is that by default we cache a lot of data in RAM in order to avoid hammering the DB. Currently you have to manually tune the size of that cache, which should be done automatically - we're hoping to get to this shortly.
- The other main cause is that the resource requirements depends on the complexity of the rooms its users participate in, not the number of users on the server. So a single user server can use serious RAM if that one user goes and joins a bunch of busy rooms with hundreds of thousands of users in them. This can be surprising to sysadmins, and we haven't figured out a good way of solving it other than just keeping making Synapse go faster.
- Finally, even though we're continuing to polish Synapse hard, we're also working on Dendrite, which uses roughly 5x less RAM than Synapse (thanks to relying on the DB for caching, using a smarter DB schema; passing all strings around as enums called NIDs, and Go's GC being smarter than Python's). For instance, dendrite.matrix.org uses a relatively stable 480MB of RAM, despite being in thousands of rooms spanning tens of thousands of users. It's still beta, but progressing fast.
2. In terms of choosing a Matrix server: "Well, you could just tell a person to use matrix.org. But then it spent a good portion of last year unable to federate with other popular nodes due to Synapse limitations." - yes, at the beginning of 2020 we hit a performance ceiling on Synapse on matrix.org which caused federation to fall behind during heavy traffic. *So we fixed it*. https://matrix.org/blog/2020/11/03/how-we-fixed-synapses-sca... has the details. Meanwhile, more and more other folks are spinning up reliable Matrix providing services.
3. In terms of "Voice and video calling are not there yet in Matrix", again: we've been working our asses off to fix this. Since September we've had a dedicated fulltime VoIP team going through reworking 1:1 VoIP, implementing the work at https://github.com/matrix-org/matrix-doc/blob/dbkr/msc2746/p.... This has been landing over the last few weeks (although there's still some stuff left), but it should already be noticeably more robust. Meanwhile, integration to Jitsi for video conferencing has also improved a bunch - we're counting on it for running FOSDEM next weekend, after all. In terms of NAT: yes, you have to correctly set up a TURN server. We're building https://github.com/matrix-org/voip-tester to help folks test that they've got it right.
4. "Matrix is so hard to set up on a server that there is matrix-docker-ansible-deploy". This is bogus, imo. The ansible project is useful if you want to quickly run tonnes of bridges without understanding how to admin them, but for a typical Matrix server you should be able to `pip install matrix-synapse` and off you go. It's a fair point that Synapse doesn't yet ship with an admin tool, just an admin API, but there are folks filling this gap (https://github.com/Awesome-Technologies/synapse-admin is good).
5. "Encryption isn’t mandatory in Matrix". This is because, unlike Signal, Matrix supports public chatrooms. It makes *NO* sense to end-to-end encrypt a public chatroom which by definition is intended to be indexed and visible and smeared all over the wider world. All it would do is waste significant CPU on the clients, and hit up against resource limits given how large public chatrooms can get. Meanwhile, all private conversations are E2EE by default, assuming your client supports E2EE.
TL;DR: It feels like we're being judged on Matrix as it was in early 2020, ignoring all the sprinting we've been doing throughout the last year to address these criticisms, so it's all rather frustrating.
> For instance, dendrite.matrix.org uses a relatively stable 480MB of RAM, despite being in thousands of rooms spanning tens of thousands of users.
That's impressive, congrats!
I hear your frustration, and I think only time can solve this problem, and it does eventually. It's the same with Signal and the initially poor user experience.
> It makes NO sense to end-to-end encrypt a public chatroom which by definition is intended to be indexed and visible and smeared all over the wider world.
Even if you don't want encryption, authentication is still good to have, so quick question: who authenticates messages when you deactivate E2EE in Matrix? In the case of a public room hosted on server S, A sends a message M1, then sends another M2. Assuming that S is not actively MITM until after the first message (so any initial key exchange can happen), can I be sure that the second message will not be tampered with?
IIUC a Signal group where a client would then broadcast all messages to the world would still provide such a guarantee. Is that the case as well for Matrix?
That's impressive, congrats!
I hear your frustration, and I think only time can solve this problem, and it does eventually. It's the same with Signal and the initially poor user experience.
> It makes NO sense to end-to-end encrypt a public chatroom which by definition is intended to be indexed and visible and smeared all over the wider world.
Even if you don't want encryption, authentication is still good to have, so quick question: who authenticates messages when you deactivate E2EE in Matrix? In the case of a public room hosted on server S, A sends a message M1, then sends another M2. Assuming that S is not actively MITM until after the first message (so any initial key exchange can happen), can I be sure that the second message will not be tampered with?
IIUC a Signal group where a client would then broadcast all messages to the world would still provide such a guarantee. Is that the case as well for Matrix?
So you’re right that (a subset of) E2EE in a public room could be used to provide sender authentication; atm you trust the sending server not to be spoofing it. Full E2EE would be overkill.
An interesting aside as a casual observer (thank you for all your work, I see you post here a lot) I found it very interesting that the new Rocky Linux project stood up Mattermost (chat.rockylinux.org) instead of Matrix. When I Google "Mattermost vs Matrix" (because I'll be honest, they seem the same to me as a casual) the insta-Google popup result/excerpt inline is this article:
https://www.troopmessenger.com/blogs/mattermost-vs-matrix
That's a year old, so Google isn't doing y'all a service by highlighting that as it's insta-hit, we need something updated out there for 2021 for Google to latch onto.
I've created a Mattermost account for Rocky stuff and honestly, as a casual I can't tell why I'd want one vs. the other, they seem pretty much the same to me (even the UI is kinda the same). Matrix touts a lot of extra privacy stuff I think, that's about it...
$0.02 from the peanut gallery! :) I'm just using web clients and not the mobile clients (per my preference for this stuff) and use app.element.io as a comparison.
https://www.troopmessenger.com/blogs/mattermost-vs-matrix
That's a year old, so Google isn't doing y'all a service by highlighting that as it's insta-hit, we need something updated out there for 2021 for Google to latch onto.
I've created a Mattermost account for Rocky stuff and honestly, as a casual I can't tell why I'd want one vs. the other, they seem pretty much the same to me (even the UI is kinda the same). Matrix touts a lot of extra privacy stuff I think, that's about it...
$0.02 from the peanut gallery! :) I'm just using web clients and not the mobile clients (per my preference for this stuff) and use app.element.io as a comparison.
I'm the guy that wrote the blog article that got posted here. So, I'm dusting off my really old HN account, to step up and say that I am very sorry it felt depressing to you, because that was not my intent.
In fact, as I said in the post, I use Matrix, I love Matrix, I evangelize Matrix (especially to Discord people), it has made a lot of strides lately. I had a previous post on distributed offline-capable IMs at https://changelog.complete.org/archives/10205-roundup-of-sec... and I got so much feedback to "don't let people use Signal, switch to Matrix!" that I specifically was addressing Matrix as a Signal replacement in the post. (I regret it wasn't super clear that's what I was doing.)
I'm going to address your points in a sort of different order, starting with:
#5, encryption. The benefit to Signal here is that encryption is NOT optional. A user just knows everything is going to be encrypted. 1-to-1 chatting, group chats ("rooms" to Matrix), voice and video calling, attachments, EVERYTHING is E2E encryption and user error can't result in things being sent in plaintext.
Now as you say there are reasons that, say, #fx-desktop-community:mozilla.org with its 1100 users shouldn't be using E2EE. However, when talking about Matrix *as a Signal replacement*, the fact that E2E is only default but not mandatory for 1-to-1 chats, and optional but not default for multi-user chats (in Element), this makes it a lot easier for non-tech-savvy end users to goof and send messages in plaintext. A secure replacement for Signal needs to not have that option. Perhaps a "secure everything" mode in Element would help.
2. Fundamentally, there is a deeper issue here: for every Matrix user, there exists at least one, and possibly more, single points of failure. As far as I know, Synapse itself isn't clusterable, so for every Matrix homeserver, the failure of, say, a single CPU will render everyone on that server unable to communicate. I say "possibly more" because many people probably will run a singleton PostgreSQL instance also, though PostgreSQL can be clustered. Or even an upgrade to Synapse there would take people offline, etc.
For me to be able to recommend an IM to people, it must pass the "I can rely on this thing to get help if my car breaks down at night" test. Right now, Matrix doesn't give me that level of comfort. Yes, it's getting better. Yes, various hosting options exist. But still, if the homeserver you're using has a bad CPU or Synapse OOMs it or whatever, your messages aren't going through in a timely manner.
3. I am glad to hear that voice and video calling are getting so close. However, I want to still add that having two different VOIP systems -- one that can handle precisely 2 participants and another that can handle more -- is jarring for end users and admins alike. People are used to being able to tap "add participant" to their calls and this is a UX issue for people coming from other IM systems.
1. I'm glad to hear these RAM issues are getting better. I've spent a fair bit of time tuning that cache parameter, from its default of 0.5 down to 0.2 (which resulted in drastically unacceptable performance) up to the other recommendation of 2.0 (which still resulted in OOMs). I am in some large Debian, Firefox, and Matrix rooms, with over a thousand participants each -- though some of those, at least, are gated from IRC where such a scale is a non-issue.
I've been following Dendrite's "are we Synapse yet?" page with interest and excitement. I am looking forward to it being ready to use! But as I stated in my post, and as you are surely aware, it's not there yet, at least based on the "are we Synapse yet?" page.
4. It's not actually that simple. A person is most likely going to want at LEAST Synapse and Element Web. Most are probably also going to need coturn, Dimension, Jitsi, synapse-admin, and maybe an identity/directory server. The downloading of the software is the easy bit. The hard bit is getting all the bits talking to each other properly, with various JSON config files, keys, DNS entries, SSL certs, well-known files, ports, etc.
I set up my own Matrix server due to difficulties with the integrations at t2bot, some limitations in the IRC bridge I had to work around, etc.
Also to those wondering why Matrix and not XMPP: I used to run ejabberd and an XMPP service. XMPP has (or at least, HAD) a real issue when being used with multiple clients - delivering messages to the wrong place, not syncing history, etc. Matrix is far better with those things. Also Jingle in XMPP land barely ever worked, last I checked.
An aside: I try not to comment on non-federated corporate-control sites (of which HN is an example), but hopefully if you reply I'll get an email or something. You are also welcome to engage me on my blog or on Mastodon, where I first surfaced many of these ideas (and did tag the Matrix Mastodon account). Or email me.
Once again, thanks for what you do. Matrix is great for many use cases and will be great for more in the future. But I want to be clear-eyed about how it compares to Signal for the secure IM use case, today.
In fact, as I said in the post, I use Matrix, I love Matrix, I evangelize Matrix (especially to Discord people), it has made a lot of strides lately. I had a previous post on distributed offline-capable IMs at https://changelog.complete.org/archives/10205-roundup-of-sec... and I got so much feedback to "don't let people use Signal, switch to Matrix!" that I specifically was addressing Matrix as a Signal replacement in the post. (I regret it wasn't super clear that's what I was doing.)
I'm going to address your points in a sort of different order, starting with:
#5, encryption. The benefit to Signal here is that encryption is NOT optional. A user just knows everything is going to be encrypted. 1-to-1 chatting, group chats ("rooms" to Matrix), voice and video calling, attachments, EVERYTHING is E2E encryption and user error can't result in things being sent in plaintext.
Now as you say there are reasons that, say, #fx-desktop-community:mozilla.org with its 1100 users shouldn't be using E2EE. However, when talking about Matrix *as a Signal replacement*, the fact that E2E is only default but not mandatory for 1-to-1 chats, and optional but not default for multi-user chats (in Element), this makes it a lot easier for non-tech-savvy end users to goof and send messages in plaintext. A secure replacement for Signal needs to not have that option. Perhaps a "secure everything" mode in Element would help.
2. Fundamentally, there is a deeper issue here: for every Matrix user, there exists at least one, and possibly more, single points of failure. As far as I know, Synapse itself isn't clusterable, so for every Matrix homeserver, the failure of, say, a single CPU will render everyone on that server unable to communicate. I say "possibly more" because many people probably will run a singleton PostgreSQL instance also, though PostgreSQL can be clustered. Or even an upgrade to Synapse there would take people offline, etc.
For me to be able to recommend an IM to people, it must pass the "I can rely on this thing to get help if my car breaks down at night" test. Right now, Matrix doesn't give me that level of comfort. Yes, it's getting better. Yes, various hosting options exist. But still, if the homeserver you're using has a bad CPU or Synapse OOMs it or whatever, your messages aren't going through in a timely manner.
3. I am glad to hear that voice and video calling are getting so close. However, I want to still add that having two different VOIP systems -- one that can handle precisely 2 participants and another that can handle more -- is jarring for end users and admins alike. People are used to being able to tap "add participant" to their calls and this is a UX issue for people coming from other IM systems.
1. I'm glad to hear these RAM issues are getting better. I've spent a fair bit of time tuning that cache parameter, from its default of 0.5 down to 0.2 (which resulted in drastically unacceptable performance) up to the other recommendation of 2.0 (which still resulted in OOMs). I am in some large Debian, Firefox, and Matrix rooms, with over a thousand participants each -- though some of those, at least, are gated from IRC where such a scale is a non-issue.
I've been following Dendrite's "are we Synapse yet?" page with interest and excitement. I am looking forward to it being ready to use! But as I stated in my post, and as you are surely aware, it's not there yet, at least based on the "are we Synapse yet?" page.
4. It's not actually that simple. A person is most likely going to want at LEAST Synapse and Element Web. Most are probably also going to need coturn, Dimension, Jitsi, synapse-admin, and maybe an identity/directory server. The downloading of the software is the easy bit. The hard bit is getting all the bits talking to each other properly, with various JSON config files, keys, DNS entries, SSL certs, well-known files, ports, etc.
I set up my own Matrix server due to difficulties with the integrations at t2bot, some limitations in the IRC bridge I had to work around, etc.
Also to those wondering why Matrix and not XMPP: I used to run ejabberd and an XMPP service. XMPP has (or at least, HAD) a real issue when being used with multiple clients - delivering messages to the wrong place, not syncing history, etc. Matrix is far better with those things. Also Jingle in XMPP land barely ever worked, last I checked.
An aside: I try not to comment on non-federated corporate-control sites (of which HN is an example), but hopefully if you reply I'll get an email or something. You are also welcome to engage me on my blog or on Mastodon, where I first surfaced many of these ideas (and did tag the Matrix Mastodon account). Or email me.
Once again, thanks for what you do. Matrix is great for many use cases and will be great for more in the future. But I want to be clear-eyed about how it compares to Signal for the secure IM use case, today.
Let me just quote n-gate:
Signal is having technical difficulties January 15, 2021 (comments) Signal (business model: "Uber for texting") falls over. Most communications protocols are federated, and would survive one company's servers eating dirt, but Signal's owner/operator has decided this would degrade the user experience, presumably worse than the entire service shitting the bed out loud. Hackernews assumes that Signal is incapable of paying its hosting fees, and comes to the rescue by sending their money to a company that can't spin up cloud nodes fast enough to serve text messages. Other Hackernews bemoan the fact that once again they look like idiots, since they just conned half their friends and family into signing up for this mess.
Signal is having technical difficulties January 15, 2021 (comments) Signal (business model: "Uber for texting") falls over. Most communications protocols are federated, and would survive one company's servers eating dirt, but Signal's owner/operator has decided this would degrade the user experience, presumably worse than the entire service shitting the bed out loud. Hackernews assumes that Signal is incapable of paying its hosting fees, and comes to the rescue by sending their money to a company that can't spin up cloud nodes fast enough to serve text messages. Other Hackernews bemoan the fact that once again they look like idiots, since they just conned half their friends and family into signing up for this mess.
Signal needs your phone number and is run by a "former" Twitter person. It just smells funny.
On the other hand Signal is encouraged by people like Edward Snowden (who I assume is paranoid enough about American big corps). The clients are open source and feature a strong E2EE, which is called the Signal protocol and is used by many other clients nowadays because it has such a good reputation. There are lot of efforts to reduce metadata further.
Just dismissing it as "smells funny" is not a valid criticism.
Just dismissing it as "smells funny" is not a valid criticism.
> The clients are open source
But you can't verify that the open-source matches what's on the Play Store, you can't link to the official server with your own build, and you can't run your own because the server is no longer open source. (Last released a year ago)
But you can't verify that the open-source matches what's on the Play Store, you can't link to the official server with your own build, and you can't run your own because the server is no longer open source. (Last released a year ago)
> But you can't verify that the open-source matches what's on the Play Store
According to their blog, builds are reproducible[0]. Am I missing anything?
> you can't link to the official server with your own build
Why not? (I know Moxie discouraged publishing custom builds while linking them against the official Signal server but this is not the same thing.)
[0]: https://signal.org/blog/reproducible-android/
According to their blog, builds are reproducible[0]. Am I missing anything?
> you can't link to the official server with your own build
Why not? (I know Moxie discouraged publishing custom builds while linking them against the official Signal server but this is not the same thing.)
[0]: https://signal.org/blog/reproducible-android/
Rosenfeld’s admitted that they don’t NEED need your phone number, so why does he still need it? I didn’t give Zucc my phone number, I didn’t give it to Suzy, Jeff, Larry, or Sergei. So why’s Rosenfeld need it? He doesn’t, but he does. It’s “easier” this way.
They started Signal "to support, accelerate, and broaden Signal's mission of making private communication accessible and ubiquitous". Yes, Marlinspike is highly talented and worked on the security at Twitter. I don't see anything bad about that.
Signal started of with not ONLY privacy in mind. In the beginning the app required even Google Play Services, which was dropped because of pushback from the community. It seems that his experience in sillicion valley startups, also reflects on how Signal manages growth and thinks about user adoption of their product. On top of that, they try to apply as much privacy as possible. If they would have started the other way around, they wouldn't have gotten so far. A certain spirit seems to be necessary to give privacy to the masses.
Next to that, they are paving the way to no longer require phone numbers: https://signal.org/blog/signal-pins/
Signal started of with not ONLY privacy in mind. In the beginning the app required even Google Play Services, which was dropped because of pushback from the community. It seems that his experience in sillicion valley startups, also reflects on how Signal manages growth and thinks about user adoption of their product. On top of that, they try to apply as much privacy as possible. If they would have started the other way around, they wouldn't have gotten so far. A certain spirit seems to be necessary to give privacy to the masses.
Next to that, they are paving the way to no longer require phone numbers: https://signal.org/blog/signal-pins/
Agree. Googles in bed with the Government and they make sure to make near impossible to have any normal search experience while using Tor.
Wasn’t it Google that wanted to make all information available on the web through their site? This is almost as bad as censorship.
Wasn’t it Google that wanted to make all information available on the web through their site? This is almost as bad as censorship.
Signal would grow immensely in my eyes if they made the server code open source [SEE EDIT], and allowed an easy way to set the centralised server address in the Signal app. The current server would be the default, and perhaps changing the server would be hidden in Advanced Options for now. But the capability would be there. That way, if x government chooses to go after Signal's servers, the availability of all the code needed to run a replacement is already available.
As it stands, we are placing a lot of trust in the Signal Foundation for communication (assuming we rely on the Signal app/service). I have no problem with a central server being used for communication if I can communicate data in a zero-trust way. But I want assurance that that server can be quickly and easily replaced in the event it goes down.
EDIT: I stand corrected. Server code is here: https://github.com/signalapp/Signal-Server Unfortunately, you cannot change the server address in the app as downloaded from any app store, so my criticism remains.