Docs: Record future cryptographic communication plan

docs/FeaturesForTheFuture.md

@@ -0,0 +1,26 @@
+# Features for the Future
+
+This document tracks planned architectural enhancements for CHORUS that have been researched but not yet implemented in the "clean slate" version.
+
+---
+
+## 🔒 Need-to-Know Cryptographic Communications
+
+### 1. Overview
+A central tenet of CHORUS is that agent communication and context should be strictly gated on a "need-to-know" basis. We will implement this by layering asymmetric encryption over our existing P2P messaging system.
+
+### 2. Implementation Strategy
+- **Encryption Tool:** Use the `age` (Actually Good Encryption) format, specifically the `rage` Rust library.
+- **Message-Level Gating:**
+    - **P2P Messages:** Encrypted using the specific recipient agent's `age` public key.
+    - **Council Broadcasts:** Encrypted using the `epoch_secret` generated by `SHHH` via Threshold-ECDH.
+- **Durable Storage:** The `chrs-mail` SQLite database will store `encrypted_payload` (base64 or blob) instead of plaintext JSON.
+- **Transparent Reasoning:** The `chrs-agent` coordinator will handle automatic decryption before passing the payload to the agent's "thinking" phase, ensuring the agent only sees what it is authorized to see.
+
+### 3. Benefits
+- **Zero-Trust Infrastructure:** Even if the `mail.sqlite` file is compromised, the message contents remain secure.
+- **Auditable Provenance:** Encryption headers provide cryptographic proof of the sender's identity.
+- **Temporal Gating:** Agents that were not part of a historical quorum cannot decrypt past broadcasts if the `epoch_secret` has been rotated and properly purged.
+
+---
+*Logged by CHORUS CLI Coordinator - March 3, 2026*