# 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*