The rationale is this: messaging platforms are social networks, all of them are based on contact lists, and all mainstream messengers besides Signal store contact lists on servers. Those contact lists are incredibly valuable metadata, probably the most valuable intelligence target outside of message contents themselves.

Signal uses phone numbers because Signal users already have contact lists outside of Signal. By piggybacking on phone contacts, Signal can avoid storing metadata about who's sending encrypted messages to whom.

Compare that with Wire, which is a fine system, but which also effectively stores a log of every pair of users that have spoken to each other on the platform, in a database, constantly available.

Not having that database is the win for phone number identifiers.

Meanwhile, while the loss from that decision is painfully felt by people who communicate on platforms like HN, it's hardly felt at all by ordinary users, who already communicate primarily on platforms that use phone numbers as identifiers. WhatsApp, the most popular messenger in the world, was created as a pin-compatible replacement for SMS.

Signal's decision here is not the decision I would have made, because I loathe phone numbers (and, for that matter, messaging people on my phone). But it was a smart, principled decision, and almost certainly the right one; I'd decide otherwise because protecting the most people in the most effective way might be my stated preference, but it wouldn't be the preference my own actions would reveal.

I don't see how account-based systems, or Wire in particular, must "effectively store[] a log of every pair of users that have spoken to each other on the platform, in a database, constantly available". As far as I can tell – and just like Signal – they just need to hold (destination-ID, blob) for all as-yet undelivered messages. And if the destination-ID isn't a phone-number, it's harder to correlated with other extant databases of (phone-number -> IMEI) or (phone-number -> person). That is, this undelivered-log has less metadata in an account-based system than a phone-number-based system.

I get that using the contact-lists, and the constant re-uploading of contact-lists, is great for Signal's bootstrapping. Anchoring IDs to phone numbers might also work as an abuse throttle.

But I don't see how it minimizes metadata. Can you clarify?

The contact graph isn't necessary to deliver messages, but it is necessary to make the system usable: when people open up the application, they expect to see a contact list. To make that feature work, most systems just store the contact list on the server; the aggregation of all those contact lists is the entire contact graph for the service. That's the thing Signal won't store.

Sure, it makes it more usable. (Though, I use Telegram & WhatsApp with many contacts just fine without sharing my contact list with them, neither once nor the repeated-uploads Signal wants.)

But Signal could still be keeping a database log of everyone who's actually ever sent a message to anyone else. (To the extent anyone's using 'sealed sender', it'd be harder – but apps like Wire could do something equivalent to 'sealed sender', too.) And that database is way more valuable to many attackers if it's keyed by the phone-numbers Signal has, compared to the aliases other systems have.

And to the extent the Signal client wants to keep re-uploading my entire contact-list, even a one-time, temporary compromise of their SGX-based system would reveal all my phone contacts.

The synchronized contact list feature of other messengers requires them to keep the contract graph stored. We don't have to wonder whether they're logging it; they have to be.