# PIP-0002 · Oblivious hashing

Move identifier hashing off the operator so a member does not send the identifier in the clear.

## 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.