I guess you still don't understand where this falls down yet:
> The contacts which would be shared would be Signal contacts, identified by some public identifier like their phone number
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!
So this protocol can only help people discover contacts they are not yet aware are Signal users. That would involve comparing their full set of on-device contacts and sharing mappings of which one of those are within the subset of known Signal contacts.
> You seem very invested in hating this idea
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.
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.
The latter is how we wound up with a pervasive ecosystem of unusable security tools that Signal is a refreshing departure from.
You are starting with a protocol, not thinking about the user experience, and declaring it a "solved problem". I'm not even convinced this protocol is the right tool for the job.
> 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?
> The contacts which would be shared would be Signal contacts, identified by some public identifier like their phone number
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!
So this protocol can only help people discover contacts they are not yet aware are Signal users. That would involve comparing their full set of on-device contacts and sharing mappings of which one of those are within the subset of known Signal contacts.
> You seem very invested in hating this idea
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.
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.
The latter is how we wound up with a pervasive ecosystem of unusable security tools that Signal is a refreshing departure from.
You are starting with a protocol, not thinking about the user experience, and declaring it a "solved problem". I'm not even convinced this protocol is the right tool for the job.