The Ephemeral Blueprint

Core Philosophy: Privacy by Design

Most communication platforms rely on "Policy-Based Privacy"—promises that data will be handled carefully or deleted upon request. Our infrastructure is built on Architecture-Based Privacy. We employ a "Privacy by Design" framework, where the system is engineered to avoid the creation of sensitive data in the first place.

By implementing a strategy of aggressive data minimisation, we ensure that our server is not a vault for your data, but a transient relay. We have replaced the standard Matrix persistence model with a hardened, ephemeral stack designed to leave no digital footprint.

Layer 1: Cryptographic Foundation

The first line of defence is the total elimination of server-side readability.

• Mandatory End-to-End Encryption (E2EE): We enforce mandatory E2EE for all communications, strictly adhering to the Matrix protocol. This ensures that decryption occurs exclusively at the endpoints (the user devices).
• Zero-Knowledge Infrastructure: Because we do not hold the decryption keys, message content remains ciphertext while in transit and during its brief stay on our server.
• Independent Verification: This cryptographic state is not based on trust; it is independently verifiable by the user via the session verification tools within any compatible Matrix client (e.g., FluffyChat, Element).

Layers 2-4: The Data Erasure Pipeline

Encryption protects the content, but our erasure pipeline eliminates the existence of the communication through a multi-stage process.

Stage 2: Automated Redaction (~12h TTL / 30m Sweeps)

To maintain a minimal data footprint, the system executes redaction sweeps every 30 minutes. Any data that has reached its 12-hour Time To Live (TTL) is automatically scrubbed from the database. This includes:

• All messages
• Media files and attachments
• Emojis and stickers

Stage 3: Absolute Retention Purge (~36h TTL / 1h Sweeps)

While redaction removes the content, our retention policy performs a "hard delete" of the event record itself. These purges are executed in hourly sweeps, ensuring that once data reaches its 36-hour TTL, all remaining metadata and server-side pointers are permanently erased.

Stage 4: Physical Disk Sanitisation (Bi-Weekly)

To prevent forensic data remanence—where "deleted" data can still be recovered from the physical disk—we execute a FULL VACUUM on our PostgreSQL database every two weeks. This physically rewrites the database files on disk, ensuring that dead tuples are permanently overwritten and physically erased from the storage media.

System & Infrastructure Hardening

Beyond the data pipeline, the environment hosting the service is hardened to prevent leakage at the OS and hardware levels.

• Physical Hardware Security: Our service operates on hardened physical hardware protected by LUKS full-disk encryption, ensuring that all data is encrypted at rest.
• Dual-Stack Network Connectivity: The server is accessible via both the clearnet and Tor Onion Services. This allows users to mask their originating IP address entirely, providing a critical layer of network-layer anonymity.
• Zero-Log Network Policy: We operate a strict zero-log policy. No IP addresses are recorded, ensuring that network-level metadata is not captured.
• Volatile Memory Sanitisation: To mitigate the risk of memory-dump attacks, we purge E2EE and secret storage keys from the system memory every 30 minutes.

Access Control & Identity Management

We minimise the potential attack surface by restricting how accounts are accessed and recovered.

• Strict Session Limiting: To reduce the risk of unauthorised access, we enforce a maximum of two active sessions per account, with automated pruning.
• Periodic Session Rotation: We enforce mandatory weekly logouts to purge cached device data and invalidate active session tokens, automating security maintenance and reducing the window of potential exposure.
• Removal of Recovery Backdoors: We have completely disabled server-side message recovery. No recovery keys are stored on our infrastructure, ensuring there are no administrative backdoors to your encrypted data.

Transparency & Verifiability

We believe that privacy should be verifiable. Users can verify the integrity of our system through two distinct channels:

1. Client-Side Protocol Verification
   • Use the Matrix client's built-in cryptographic verification to confirm E2EE is active.
   • Confirm redaction via protocol tombstones; when the server redacts a message, the Matrix protocol generates a tombstone event, providing transparent evidence of removal.
   • Verify absolute purging through interaction failure with "zombie" messages; if a client has cached a message but has not synced for >36 hours, any attempt to edit or delete that message will fail, providing proof that the server-side record has been permanently erased.
2. Server-Side Verification
   • Access our Dedicated Verification Panel to manually confirm that redaction cycles are operating as advertised in real-time.