Zero-Knowledge Architecture
HeySummon is designed as a zero-knowledge relay for consumer responses.
What “Zero-Knowledge” Means
The platform cannot read the response sent back to the consumer. It is encrypted with the consumer’s public key, and only the consumer has the private key.
What the Server CAN See
| Data | Visible? | Why |
|---|---|---|
| Request metadata | ✅ | Reference code, timestamps, status, expiry |
| Consumer’s public key | ✅ | Needed to encrypt the response |
| Messages (at rest) | ✅ Server can decrypt | Encrypted with server key pair — needed for provider viewing |
| Provider’s response (to consumer) | ❌ | Encrypted with consumer’s public key |
What the Server CANNOT See
- The decrypted response going to the consumer — only the consumer’s private key can decrypt it
- The consumer’s private key — never leaves the consumer’s machine
Trust Model
Consumer trusts:
✅ Their own private key (generated locally)
⚠️ The server (for relaying, not for reading responses)
Provider trusts:
✅ The server (to decrypt messages for viewing)
✅ The encryption (response is encrypted for consumer only)
Server:
✅ Can decrypt messages (for provider viewing)
❌ Cannot decrypt consumer responses
✅ Can see metadataLimitations
- The server can read the original messages (it has the server private key). This is by design — providers need to read them.
- The server cannot read responses encrypted for the consumer.
- If the server is compromised, an attacker could read stored messages but not consumer responses.
- For maximum security, self-host your own instance.