Moxie Marlinspike has a plan to reclaim our privacy

I think we need to agree on a common threat model because right now I'm getting the impression that you and I are assessing things from very different angles. If any of the 3-letter agencies decide to target John Doe specifically and expend significant resources on this task, I think we can agree that chances are they will succeed. Neither a centralized or a federated approach will protect John from that because, unless John is a security expert and very paranoid and careful in everything he does online, there will be many other attack vectors.

Signal's goal, however, is to protect the masses and, thus, society as a whole, by protecting as many people's privacy as possible. The things that are at stake here are not the data and the social graph of a handful of individuals, but the data and social graph of society as a whole. (I'm sure I don't have to mention the implications for democracy and social order.)

My perspective, therefore, was that of an average user. The reason I mentioned my personal situation and the fact that I myself spend quite a bit of time on making sure my systems are safe, was to emphasize that if the situation is already overly complicated for me, it will be much worse for the average user.

> In general, you should only have to trust a particular host with communications going to the specific contact that uses it.

I don't think the word "only" is appropriate here. Let's say John Doe has roughly ~1000 contacts. This means that, in the worst case, he would have to research ~1000 hosts and their privacy policies. Now the "accumulation effect" I mentioned previously will reduce that number quite a bit but there are still going to be dozens of different hosts. I doubt we could expect John to look into each and everyone of them before he gets in touch with his contacts. (Note that this gets even worse when people can freely switch between hosts, as suggested e.g. by other replies to my comment, as John will then have to repeatedly do the checking.) Therefore, I think it is reasonable to expect that a significant number (millions, if not billions) of users will end up residing on insecure and untrustworthy hosts and their social graph and metadata – and possibly even their data (see below) – won't be protected at all.

> With a centralized model, you generally have to unconditionally trust the central authority.

In the federated model, John has to do that, too. Sure, he can self-host but how many people are actually going to do that? Put differently, the vast majority of all acts of communication in the network is going to get routed not through self-hosted nodes but through the servers of providers whose trustworthiness is at least questionable. I hope you will agree that, for society as a whole, this exacerbates the trust problem you mentioned.

> A federated system offers much more flexibility. Metadata is likely to be spread piecemeal across multiple hosts and network paths, making it much more difficult for an adversary to analyze in the general case.

A federated system also makes it much easier for adversaries to enter the game, as they don't have to compromise a well-known provider like Signal that is under the close scrutiny of the public. Instead, they can just create new hosts (just like they do in the case of the Tor network). What's worse, in this case they won't just be able to access their user's social graphs but very likely also the content of their messages, as the key discovery problem is usually solved by hosts distributing their users' public keys.

So instead of giving a phone number I should register my Name, Address, Phone Number?

Sounds worse than buying a prepaid SIM if you ask me.

You are welcome to develop your argument and point out where in MTProto 2 you find fault or why using standard crypto primitives isn't enough and what you'd like to see from MTProto 2 to secure it in your mind.

The gp comment literally just posted a link to a deprecated comment that painted MTProto 1 as (rightfully) insecure.

That was not thorough research and it attaches the FUD associated with an unused protocol to MTProto 2, which I'd again like to remind you and everyone, not a single security researcher or otherwise has found fault in.

You haven't even glanced at the article, which tells us a lot about the fascinating life of a very interesting person, and to add insult to injury, you then link to a video that does nothing but state the obvious (with much melodrama) for 17 minutes. Frankly, this is the laziest dismissal I've ever seen.

I think after reading that...

Do the right thing poorly instead of the wrong thing correctly.