Opening up usernames (in the conventional sense) you will end up needing to verify and act as an arbiter. This is due to the fact that certain usernames have real world meaning behind them and you don't want to create an ecosystem where it is really easy to honeypot whistleblowing platforms (how do you ensure that CNN gets {CNN, CNN-News, CNNNews, etc}?). They've suggested that this might be the case given that the "Notes to self" and "Signal" users are verified with a blue checkmark. The issue is that verifying users not only makes Signal a more trusted platform but the act of verification requires obtaining more information about the user. It also creates special users. All things I'm very against. I'd rather hand out my phone number than have Signal collecting this type of information. So yeah, it isn't completely trustless, but I certainly don't want to move in the direction of requiring more trust.

And that's where I have to trust Signal, but as a protocol not a "trusted source" of information.

Addendum: also, there is nothing preventing this type of contact book data from being backed-up/synced to a new phone, like any other data and settings of any other app. iOS has this feature since like 7 years now. Android, too, I'm sure.

Or in other words: suppose the definition of "phone number" was expanded to include alphanumeric characters and @. What aspect of Signal's current design would break? By saying "without phone numbers, they can't use clientside contact lists", you seem to be suggesting that something would break, but I can't imagine how, unless it's as trivial as a database constraint that says "this field must contain only digits".

I don't understand why you state this, when you obvioulsy know that data is connectable and joinable across discrete sources. Being "the only social network available to service X" is the inherent case for every single online service on the entire planet when viewed as an isolated entity. But this isn't a case of anonymized UUIDs. It's a case of personal phone numbers.

Apart from using the device contact list (which contains email addresses as well as phone numbers) the client can also keep a private contact list.

E-mail as a complement should work fine and supported in all contact lists. It wouldn't change a thing wrt what you're describing.

Now they use a solution based on Intel SGX and server-side trusted computing [2].

[1] https://signal.org/blog/contact-discovery/

[2] https://signal.org/blog/private-contact-discovery/

- Having a server to hold your contacts

- Or having signal app to maintain contact list and sync it across devices

1. Support phone number contact discovery, with persistence provided by the contacts provider. This is seamless and causes the least amount of complaints.

2. Support username discovery, with persistence provided by passphrase-encrypted online storage. This is painful and risks backlash from people losing access to data. Also, now the threat model must account for or ignore weak derived keys (which is probably most of them).

- 2a. Enforce strong passphrase requirements. Many users will abandon the product.

- 2b. Sync usernames between linked devices (using a generated key). Requires multiple devices, risks people losing data, more complaints.

- 2c. Sync usernames using custom contacts provider fields (e.g. email). Nobody is accustomed to doing this, but it might work. Automatic discovery rates would be low. Possibly requires an odd workflow for people adding Signal contacts by their email/username.

That also sounds like a good way to limit adoption as well, at least for anyone with more the N contacts, particularly >= 2N as that means likely a minimum waiting period before you can transfer over "more" contacts since some people will never accept/reject the invite because they don't use the app much.

If it were me and I had to wait on others to accept or reject my invite before I can continue transferring contacts, I'm gonna move on.

On Telegram this is rampant, on average probably one person per day. It shifted from e-gold scams to sex since a few months, but both are still present. People that aren't in big groups (where the spammers scrape user IDs) have zero problems, so the trick is revealing your random identifier only to those you want to contact you. Phone number identifiers are the antithesis to spam protection: we keep our ranges just full enough that we can't shorten it by a digit, but empty enough that we have small growth possibilities. You're very likely to hit a subscriber, by design, by trying random numbers.

This makes sense for contact discovery, which is important for normal people who just want a chat app that works.

But there are a very important segment of signal users, people with an elevated threat model, who I would be willing to bet a good portion of them would gladly sacrifice contact lists if it meant not having to share their phone number.

Why couldn't they just keep using the current system, alongside usernames, for phone number contact discovery? Of course for those who opt into it; imo that's what it should be.

Could you please explain how Signal does not have a social network map, when 1) user accounts are equal to mobile phone numbers, and 2) Signal servers route messages between user accounts.

Also, everyone not sharing their contacts with the signal app already have that UX. Minus the privacy benefits of course.

  A) Most contacts have phone numbers
  B) Most contacts don't have email addresses?

Are you also assuming that it just adds a lot of complexity to be willing to search by both phone numbers and emails?

That's the part of your argument I'm not grasping. Signal has to be willing to intersect known-account-identifiers with this-device's-local-contact-handles, what's the problem with preferring phone numbers but allowing emails?

Is there a reason why a user's address book can't be encrypted as well?