When they say "social graph for Signal", afaik they don't mean 'on Signal servers' but 'social graph on your phone'. It's a personal social graph that exists on the end-user device.

I don't remember how the hash issue is dealt with, however.

> Signal is not peer-to-peer. It is a centralized, client-server architecture.

It's not a P2P mesh, but Signal's servers are involved only for certain functions. I think communication tx is P2P - to send a message via server (used to hide sender IP address from onlookers and the recipient), you need to enable relaying. Possibly finding the recipient still relies on the server - if I want to send a P2P message to Abel, to what IP address do I send it?

The official signal.org blog post I linked does actually explain how it works. They write that the client sends parts of hashed phone numbers to Signal:

> The client transmits those truncated hashes to the service. The service does a lookup from a set of hashed registered users. The service returns the intersection of registered users. The obvious problem with this method is that the hash of a user identifier can almost always be inverted. Regardless of whether the identifier is a phone number, a user name, or an email address, the “keyspace” of all possible identifiers is too small.

Also: Signal messages are currently never P2P. They always pass through Signal servers, which see (but apparently not retain) your IP and timing metadata. The Signal WebRTC calls are partially peer-to-peer, that is what the relaying in the Signal settings panel is about.