01
Secret content
Secret payloads and room messages are stored as ciphertext and expire through TTL, views, burn, room expiry, request reveal, package expiry, and scheduled cleanup.
- TTL
- View limits
- Burn and cleanup
Metadata and retention
Shhhs separates secret content from operational metadata. Secret content follows TTL, view limits, burn, room expiry, request lifecycle, and scheduled cleanup. Metadata exists only to run, secure, bill, and support the service.
01
Secret payloads and room messages are stored as ciphertext and expire through TTL, views, burn, room expiry, request reveal, package expiry, and scheduled cleanup.
02
Operational metadata can include object ids, timestamps, account/workspace references, plan gates, size buckets, lifecycle state, abuse signals, and delivery status. It must not contain plaintext secrets, passphrases, full private links, or fragment keys.
03
Billing records are handled through Paddle references and support metadata. Support can help cancel billing after validation but cannot recover secrets or recreate lost account access.
04
Audit and event notifications are metadata-only. They can report that a secret was created, viewed, expired, burned, requested, submitted, or revealed without including content.
05
CLI and MCP reports should contain metadata and links only. They must not print plaintext secrets to stdout/stderr, agent memory, CI logs, or transcripts.
06
Scheduled cleanup is operational, not instantaneous to the millisecond. Public pages must describe the deployed storage and retention behavior without overstating deletion guarantees.
No. Public guides never include secret identifiers, room ids, full private URLs, fragments, filenames, or payload-derived text.
No. It is product documentation for deployed boundaries. External audits, DPAs, SLAs, and certifications require separate evidence and review.
No. Shhhs support can help with billing and metadata-only support, but cannot decrypt or recover secret content.