Self-Destruct & Privacy

IO was built from the ground up as a zero-retention system — not a policy you configure, but a structural constraint that makes data retention impossible.

The Architecture

• No database. Not a "we delete later" — there's nowhere to store.
• No logs. No request logs, no IP logs, no analytics.
• No accounts. Your API key is a stateless bearer token, not a user profile.
• No cookies. No session persistence. No tracking pixels.
• Stateless inference. Each request is processed and forgotten.

Self-Destruct Timers

Every IO session supports configurable self-destruct:

Self-destruct applies at every level:

• Session — entire conversation thread
• Message — individual messages on a timer
• File — uploaded documents
• Canvas — collaborative workspace
• Room — entire group + AI participant

curl https://api.useio.xyz/v1/timer \
  -H "Authorization: Bearer *** \
  -d '{"duration": "1m"}'

Or via relay: /io5 <prompt> for 5-minute timer.

Redact-Before-Infer

Before your prompt reaches any model, the Redact Engine strips:

• Wallet addresses (ETH, SOL, BTC, etc.)
• Email addresses
• Phone numbers
• API keys and secrets
• Social security / identity numbers

curl https://api.useio.xyz/v1/redact \
  -H "Authorization: Bearer *** \
  -d '{"text": "Send 1 SOL to 0x1234... and email me at user@example.com"}'

Returns:

{
  "redacted": "Send 1 SOL to [REDACTED_WALLET] and email me at [REDACTED_EMAIL]",
  "report": {"wallets_redacted": 1, "emails_redacted": 1}
}

The model never sees your raw PII. The redaction report stays local.

E2E Encrypted Rooms (Planned)

Upcoming: IO Room — E2E encrypted group chat where the server stores only ciphertext. Keys are generated client-side. Even if the server is compromised, your conversations are unreadable.

• Client-side key generation (X25519 + ChaCha20-Poly1305)
• Server stores encrypted blobs only
• Self-destructs when host leaves
• Encrypted message history with forward secrecy