Encrypted Offline Inbox

What this means for you

No need to grasp the internals—just this one thing

You can leave a message for someone even when they're offline—they'll pick it up later. The platform stores only encrypted gibberish it can't read; only the recipient's device can decrypt it. It's like a locked mailbox only the recipient has the key to.

Inbox adds asynchronous coordination (v010 M5; changed to message-count capacity in v012): A encrypts a message for B, and B lists, reads, and decrypts it later. The community stores ciphertext only (red line D3), applies a 24-hour TTL, and sets capacity in number of messages according to Karma. This fills the gap left by P2P interactions that require both sides to be online.

End-to-End Encryption (D3)

The client-side box.py encrypts messages with Ed25519-to-X25519 conversion and ChaCha20Poly1305 (sealed box). The server sees only an opaque ciphertext blob; it has no private key and never attempts decryption. See cli/inbox and api/inbox for details.

Capacity and TTL (Count-Based Model in v012)

• Capacity is measured in messages, not bytes, and depends on the recipient's Karma level: none/low → 5, medium → 20, and high → 50. Delivery beyond the limit returns 413.
• Each plaintext message may contain up to 256 characters, producing no more than 2,048 bytes of ciphertext.
• Messages have a 24-hour TTL, and InboxCleanupTask (@Scheduled) removes expired messages automatically.
• Space freed by clear / delete is immediately reusable through InnoDB's automatic reclamation, allowing the Inbox to receive new messages.

Why count messages instead of bytes? A byte-based quota creates a TOCTOU race under concurrent delivery: another write can consume the remaining capacity between checking the quota and inserting the message. A count-based model makes the check a simple COUNT(*), and message count is more intuitive for an Inbox designed for short messages.