Oblivious hashing

Why

Identifier hashing protects the database, not members from the network. The pepper is server-side. A member sends an identifier in the clear and the operator sees it in order to hash it. Calling that zero knowledge is false.

This PIP proposes the replacement: the member hashes, the network never sees the preimage, and Finder still works.

What must not change

SONAR still answers which member holds a key. RESOLVER still answers what that destination accepts. FINDER remains both, composed on the client. A directory remains a club. This PIP does not open the register.

Sketch

1. The member derives a lookup key from the identifier and a public network parameter.
2. SONAR is queried with that key, not with the identifier.
3. The operator stores only the derived key. It cannot reverse it.
4. Until a network ships this, implementations must keep saying the hashing is server-side.

Compatibility

v0.1.0 stays honest. Networks that already hash server-side keep doing so until they publish a rulebook clause and a dated switch. A silent swap would make two members unable to find each other.

Refusal conditions

Any text that claims the current hash is zero knowledge. Any design that lets the operator reconstruct the identifier. Any design that moves SONAR onto the operator as a single party who sees both the search and the answer.