> If Alice and Bob are just comparing their directories of already-known Signal contacts, there's nothing for a discovery protocol to accomplish: Alice, Bob, and Charlie are already each other's contacts!

No, they are sharing (tel:+12025551212 signal:a31d79891919cad24f3264479d76884f581bee32e86778373db3a124de975dd86a40fc7f399b331133b281ab4b11a6ca) pairs. Alice and Bob determine that they both know Charlie; Alice and Bob then — since they both know one another and both know Charlie — feel good about sharing with one another what Charlie's Signal ID is.

> So this protocol can only help people discover contacts they are not yet aware are Signal users.

Which is exactly what Signal's current contact-sharing protocols does, in addition to helping Signal discover all of one's contacts.

> I would continue trying to give you what I thought were constructive technical criticisms, but apparently you interpret that as me being "invested in hating" the idea.

I will give you the benefit of the doubt and assume that your repeated failures to understand the protocol and its requirements are due to by own poor explanations, and further that you actually intend to be constructive.

> It's more like I'm invested in providing good user experiences for security tools, which often involves starting with the user experience you want to provide and working backward, not starting with a cryptographic algorithm and trying to bolt-on a good user experience.

I'm starting with a principle, not a protocol. That principal is that: online service providers must know the absolute minimum amount of information to do their jobs. Ideally, instant messaging would use some form of private information retrieval protocol so that server couldn't know who is talking to whom. Given Signal's current architecture, it must know to whom one is talking; there's no reason for it to also know everyone to whom one could be talking.

> The latter is how we wound up with a pervasive ecosystem of unusable security tools that Signal is a refreshing departure from.

Is it better to be usable but insecure than unusable but secure? I think the answer is mu: a product must be both usable and secure. Granted, security is always in the context of some threat, but it should be possible for users to intuitively grasp the security context.

> You are starting with a protocol, not thinking about the user experience

So, what do you think the user experience of contact discovery should be? I've already demonstrated that my proposal has an identical experience to Signal's, with the exception that one must manually register contacts not know to one of one's contacts. How would you implement contact sharing without giving OWS access to everyone's address book everywhere?