Moxie as far as I know is still involved in the project and is the source of decisions such as requiring a phone number. My understanding is he is leaning hard on "encryption for anyone and everyone" over all other considerations such as decentralization.
A common criticism is "huh, not very anarchist of him!" Which, maybe? If decisions like that can get Signal into as many hands as possible, and if Signal can continue to operate in such a way as to have basically nothing to offer governments that demand data other than account join date, I think that's an improvement in material conditions.
Your bio has a pretty frank indication of the maximally decentralized, encrypted alternative, and how user hostile that still is:
> If you want to DM, I am generally open to chat. Generate a https://SimpleX.chat invite and paste it into a file simplex-invite.txt, then run the commands below and include pasted contents of DM.txt in one of your comments in any thread we're both participating in.
Session is a decentralized Signal fork that creates the account on the device without associating it with a phone number.
See also maqp2's comment here regarding Simplex:
https://web.archive.org/web/20250302182017/https://reddit.co...
I'll just say that the main issue with SimpleX is that it lies in its marketing material that it has no identifiers. What they really mean is that they're not adding new identifiers in the app, it doesn't mean they're actively removing existing identifiers, that is, your IP address. The client currently routes messages through two hosting providers which reduces incidental metadata collection. But it does fuck all if the hosting providers collaborate unbeknownst to the users.
That being said, SimpleX has really good support for Tor, in that if you just install tor package to Linux over apt or whatever, and configure like two items in the app's proxy settings, the client will automatically switch to SimpleX Onion Service servers instead of routing to clearnet servers through exit nodes. I can respect that.
What I can't respect is the threat model being treated like a fine print that's buried beneath menus: When you claim to be the most private messenger out there you need to act the part.
A SQL query would defeat the purported anonymity in many cases. An ai model would look at the other cases where IPs of VPNs or Tor are used, uncover much, and yawn.
Now another set of servers are operated by Flux. That helps. But you know how BFFs are with each other, inter-team access to data sinks.
These posts on Reddit and this orange reddit over here by maqp are high quality. They should be read thoroughly.
On the other side of this, the ability to change the receiving server with zero-interaction by remote contacts does lay a cornerstone for effectively anonymizing users. The option to add additional servers used by a SimpleX profile is another cornerstone.
But the mainline user interface hasn't been updated to use these effectively.
What I do like about SimpleX is it is, with a massive asterisk, distributed. SimpleX in practice lives somewhere between decentralized and distributed right now. SimpleX as used by the unwashed masses and disregarding everyone else, is decentralized, or quasi-decentralized.
SimpleX is not confined to a centralized permissioned namespace like Signal 501c3's service which is total vendor lock-in, for fools (yes if you are using that service, you have been had).
SimpleX has shirked the manual processes that XMPP+OMEMO users need to proactively do for a distributed experience.
The audited core Haskell code is hard to argue with. Looking forward to a successor in Lean.
But today, both SimpleX and the better XMPP clients are best enjoyed with community-managed container compose files.
I have read in places apparently originated from more than two minds some zero knowledge approaches that do functionally mitigate any usable identifiers, sans where users are of a small crowd and rarely ever change source IPs, so as much as may ever be practicable with current generations of IP (Reticulum with no source addresses looking better and better). Will be cool to see these implemented.
There may also be a way to do multiple redundant server paths that may be more efficient.
Much waiting to be done, things simply throwing an LLM at won't achieve.
I am convinced by the behavior of some degenerates that one of among those things is not a polished iOS app. iOS is a total cancer. iOS, for which no source code is available outside of Apple and its puppeteers, is for slaves. Voluntarily use of iOS, is an explicit admission cybersecurity-illiteracy.
> The main reason I said to avoid Session, all those months ago, was simply due to their decision to remove forward secrecy
I often see this complaint. But it seems to me that, since Session allows users to generate a new private key arbitrarily on the device (and without even associating it with a phone number on a central server) it benefits less from the feature.
> Forward secrecy protects past sessions against future compromises of keys or passwords. By generating a unique session key for every session a user initiates, the compromise of a single session key will not affect any data other than that exchanged in the specific session protected by that particular key.[0]
I think this is exactly what he wanted, as these were the complaints levelled against the service when he was still in charge.
From 2018: https://drewdevault.com/blog/Signal/
> Moxie knows about everything I’ve said in this article. He’s a very smart guy and I am under no illusions that he doesn’t understand everything I’ve put forth. I don’t think that Moxie makes these choices because he thinks they’re the right thing to do. [...] Moxie can’t come out and say it openly, but he’s made the decisions he has made because they serve his own interests.
And it looks like it's working. The Signal social network is growing. Revenue is growing (revenue pays for ongoing maintenance). Alternative servers are not sapping user metrics. It's still easy to push both security fixes and eye-catching new features because one central server, and client upgrades are aggressively pushed. Spam is not a plague because registration remains expensive - you need a genuine phone number you control, or Google to vouch for you (who in turn have their own robust defences against account creation).
If it was a free sign up where you just need an IP address to play, spammers would have hundreds of millions of accounts and you'd get as much nuisance friend requests as you get email spam. Most people would leave. You've seen the scraperpocalypse, every sketchy person on the planet has money to fund a million sign ups each from a unique US residential IP (thanks to "smart" TV vendor neglect/corruption allowing residential proxies), IP reputation is worthless.
Personal instances of Signal would hide until spammers found them but you'd better have your own locked down registration because you can't hide forever. Not to mention that sending ongoing traffic to your own server tells everyone where and when you're posting, moreso than using Signal's centralised services.
Its tradeoffs all the way down.
> I think this is exactly what he wanted
You think, users should be required to carry a cell phone or make use of a debit card or credit card, in order to message another user, is exactly, what Matthew wanted?
A self-described anarchist who described the original cypherpunks as his teenage heroes?
When XMPP+OTR had already been, among competent people, the prevalent norm for over half a decade when he gave that DEF CON 18 talk?
That is just crazy, man.
In that DEF CON 18 talk, Moxie talked about scope of choice and how the scope of choice changed to "do I want to carry a cell phone, or not?". A notion that Matthew's dream was to impose on the world a demand to carry a cell phone or a debit/credit card transaction on others, such a tax, to enjoy what he and his friends and colleagues already on top of pure Internet Protocol, is on its face absurd.
_
> Spam is not a plague because registration remains expensive
The issue of spam is fully mitigated with an invite token, a 16 byte string ; "is", not "can be", because other systems in production have already been doing this.
The way it works is simple. If Alice wants to receive a message from Bob, Alice can share a connection string username+token to Bob. Then Bob can message Alice and for that time not other users of the hosted centralized namespace.
Very simple concept.
Simple enough for a mediocre dev to implement without an LLM.
The spectre of spam does not justify the demand for "checking in" with your local PSTN tower, nor the friction involved with an uninvolved and unwanted third party named Google (love Google overall but this is such a bastardly and disgusting concept), nor does it justify demanding a debit/credit card transaction become involved.
The spectre of spam does not justify any of this horse shit.
"Hey Bob, here is my username to message me, provided you subject yourself to this horse shit", where such horse shit antithetical in a fundamental way to the values espoused founder of Signal.
The new, grossly degenerated Scope of Choice.
Perhaps some who call themselves "hackers" or software developers may have been actually fooled by this false spectre of spam. I was never among them.
Even worse, the phone numbers, Google Play accounts, debit cards and credit cards, these are cheap. Among the scammer underworld these are a plenty and fungible.
An invite token personally sent by Alice or read aloud by Alice to Bob, is not.
But if somebody wants to harass a specific user on Signal, that's relatively cheap to do.
_
> Not to mention that sending ongoing traffic to your own server tells everyone where and when you're posting
Uncle Jeff, AWS, who doesn't tell exactly everyone but a lot of people, not excluding ICE at any given time, knows when you are posting, from where, and to what other users. The last of which is specifically obviated by a separate namespace hosted on a separate server.
On the occasions I have run Signal's server software, I and other users did mitigate these concerns. We do appreciate that others also have these means, or not.
Another messaging system, you may have already read its name actually, has already solved these problems in a way that they are successfully mitigated in a wholly transparent way for casual users.
_
> Alternative servers are not sapping user metrics.
This imperative is not the users' problem and runs counter to the best interests of the users.
_
> Its tradeoffs all the way down.
Right. In Matthew's view, the horse shit is a tradeoff.
I believe there are other tradeoffs available that are ethical, not more ethical, but ethical, and carry much less technical complexity.
The Signal client software is open source and some of the clients have reproducible builds. The Signal server software is open source, though has a history of being over a year out of date at some points. Other deployments of this server software for production use are rare.
Suppose you configured an instance of the Signal server software and others you know ran also a somewhat modified Signal client that could access that instance of the Signal server software.
But the centralized namespace of the hosted Signal service hosted by the incorporated 501c3 named Signal would not be accessible through that server instance now would it.
And, as dictated by the incorporated vendor of the centralized namespace, and other reasons, in practice, this client would have to run as a separate piece of software. "Another app".
This is vendor lock-in.
The service hosted by the 501c3 named Signal seems widely open yet is a permissioned namespace. A physical location tracking number aka phone number or a credit/debit card is required to access the namespace. This is for slaves. The profane.
This vendor is abusive.And, I don't think this is what Moxie wanted.
Signal 501c3 is a centralized service. XMPP and Matrix are decentralized/federated. SimpleX is distributed.