In short, yes, building a standard takes some effort, but that serves your users and to future-proof your solution. Moxie's post boils down to "1- I know better than my users and I don't need input to protocol-design, 2- I'm not willing to put in the effort to standardize and document, 3- I reserve the right to change the deal for whatever reason if I ever feel the need" which is not a good look
As for Moxie's post: all three points feel completely valid for a service they're offering for free. Moxie does know better than most users (most users don't know the first thing about software, programming, protocol design, or UX design) and it's a companies choices that drive users to their platform in the first place. Users who don't like it can choose from the dozens of other chat apps instead.
As for the second point, Matrix's ever-moving target of a protocol makes selecting a client or server that covers all of your needs a massive pain. Currently, Matrix's primary server software, Synapse (which is also at the base of the matrix.org server many people default to when joining the network), is violating the Matrix protocol, making it impossible to invite users to chat if they are on compliant Matrix servers. On the XMPP side, there are two different methods of achieving E2EE communication, with seemingly no standard mechanism to support the use case "I want to log in to my chat on my laptop and be able to decrypt the messages in the group chat". I can't blame Signal for not wanting to deal with issues like that. One piece of server software, one set of client versions, with fixes ready to deploy when they're called for: Signal's current design saves a lot of time and effort.
As for the third point, that's part of the reason I use Signal in the first place. I like federated networks as much as the next nerd and I like open standards even more, but the decisiveness behind the company, even when I disagree with their decisions sometimes, is what makes it clear what you can and cannot expect.
On the XMPP defence: yes, I believe what they are saying, XMPP could in theory be a good product, just like Matrix could be, and like Signal is. However, currently, it isn't. XMPP is currently losing in terms of public marketshare to Matrix, which I also wouldn't exactly call a great success.
could you expand on this in detail?
I'm certainly not willing trade a theoretical minor annoyance in exchange for my (literally) vital messaging needs to be subject to enshittification, or abuse by a single actor (which controls whether I can access the network, when, whom I can speak with, what features I am allowed to use, and whether it's time to rope me into buying some cryptoshitcoin).
Related thread: https://news.ycombinator.com/item?id=21936929
I didn't say it needed to be federated, I said the infra automation code needs to be opened.
(Note that I don't care about cryptocurrencies except for the cryptography behind it)
There are fully anonymous cryptocurrencies using ZKP where it's not possible to tell if a transaction sent is a transfer of the cryptocurrency itself or a message. It's decentralized and it's also impossible to tell who the transaction is made for (anyone with a copy of the chain can potentially be the recipient of either the money transfer or the encrypted message).
If people were really serious about privacy and secure messaging they'd look into this instead of constantly attacking the concept.
But then of course there are entire armies of shills who have a vested interest in pushing a narrative explaining that services, at best, collecting metadata and, at worst, being backdoored are offering "secure messaging".
I'm only using Telegram and I don't believe for a second it's secure and private (it's got, supposedly, "one on one" E2EE but not for groups). But at least they're not posturing as the most secure and private messenger on earth.
https://docs.getsession.org/contribute-to-the-session-networ...
As far as I can see, you can invote people to a group chat using QR flyers, but your Signal profile is visible to everyone in a chat, so everyone knows what Tina in marketing thinks about it.
Because nobody is going to have a burner phone with a data plan for a separate Signal identitiy.
For most people and use cases, either will probably do, but if you're a human rights activist or journalist in an oppressive country, I'd stick to Signal.
So that the state actor can listen on the edge of the network and infer with whom you are taking and when? Or maximize their chances of finding a 0-day in the client considering that it's the same client that everyone else's using? Or throwing it all away anyways when it's using Apple/Play services for notifications delivery?
I mean, as opposed to using something like XMPP which you can completely use over Tor and never even reveal which server you use/that you use XMPP, from a client running a secure and minimalistic OS and no service-in-the-middle ?
Some would label Signal as a honeypot and it would be difficult to falsify that.
What do you mean by "all"
Apple, at least, maintained a historical database of your phone's notifications, that it did not clean up after they expired. That includes all notifications from Signal telling you that person XXX has sent you a message that starts YYYY <facepalm>
Anyway, I'm not OP, and they have a mad setup (XMPP via Tor) which is a flaky solution most people wouldn't go for. In general, if you're not going to such extreme measures of hiding among the crowd of Tor users to mask your metadata, you're better off directly connecting and hiding among the crowd of Signal users, rather than hosting your own instance.
This is the whole point. Signal actively prevents me from using it outside of the Apple-Google duopoly. Other messaging apps are not like this.
SimpleX, Delta Chat, Matrix
Signal app can update itself at any time
The app is constantly phoning home to Signal servers checking for updates even when it has not been launched and is not being used
That means the client could change at any time, for any reason, unbeknownst to the user
If the advanced user is free to write, edit and compile source code for a Signal client, software developers might call this a "third party client" because there is allegedly some "business transaction" between Signal Corporation and the user where Signal Corporation and the user are first or second parties (although, curiously, the Signal app and service are free)
But it's arguable the more important use of the term "third party" in this context, i.e., "secure" communications, is to indicate a party that is not a first or second party to the communication, a potential eavesdropper
Signal Corporation is a third party to the communication
Because it forces users to use its closed source client software that can be updated at all times for any reasons when it's installed on a user's computer, there exists the potential for remote code execution and, for example, eavesdropping
For example, a US corporation subject to US law could be legally forced to eavesdrop on a particular user. This could be done with an "update"
The point I was making is that this goes against Signal's terms of service, and can get your user account terminated. That's a very oppressive clause in practice, you may want to use a non-signal client for all kinds of legitimate reasons (porting to a non supported platform, to adapt for accessibility needs, for privacy, for compliance, to remove nagging and dark patterns, etc). Signal don't want that, they want to control your user experience, even if this makes it worse for their user.