How Aegis protects your notes

The short version

Every saved note is already cryptographically anchored to your Veritas chain: the note's text and each attachment are reduced to a SHA3-384 fingerprint and committed before anything is encrypted to storage. Ticking Protect with Aegis lifts that anchor into a public, queryable provenance fabric so other people can verify your authorship later — without you handing over anything sensitive.

What gets protected, and how

Order of operations

1. You compose a note, optionally attach files, tick Protect with Aegis, and hit Sign & save block. (You can also flip Always protect notes with Aegis in Settings → Preferences so every new note starts with the toggle on.)
2. The note body (your prose, minus the Protected by Aegis badge) is sent to Aegis Layer T. The server normalises it, slices it into 200-word chunks, hashes each chunk into a 256-bit SimHash over its k-gram shingles, and stores those fingerprints in a public Vectorize index. The original text is never persisted — only the SimHashes and a tiny manifest text/<asset_id>.json.
3. On your device, each image or video attachment is fingerprinted through the full Aegis pipeline (perceptual hash, semantic embedding, tiled Merkle hash, multi-view augmentation). The bytes never leave your device.
4. Each capsule is signed with your ML-DSA-65 post-quantum key and posted to Aegis. Aegis returns a public asset ID + capsule ID per attachment, and a separate text asset ID for the body.
5. Your note's plaintext (title + body + attachment names) is hashed to SHA3-384, committed to your Veritas chain alongside every Aegis ID (images, video, and the text asset), then and only then encrypted with a per-note key and uploaded as an opaque ciphertext block.
6. The encrypted block lives on chain forever; the public Aegis capsule lives in the provenance fabric forever; the plaintext lives only behind your passkey.

Proving authenticity later — without disclosure

The day you need to prove a note or an image is yours, you have three tiers of disclosure to choose from — pick the smallest one that satisfies the verifier:

• Zero disclosure (image / video). The other party drops their copy of the image on Parable Detect. Detect computes the same one-way fingerprints on their device and queries the public Aegis index. If it matches, they see your asset ID, registration timestamp, and an opaque owner ID. They never see your name, the original bytes, or any other note metadata.
• Zero disclosure (text). The other party pastes the passage they suspect is yours into Verify text. Their device sends the candidate text to Aegis Layer T; the server computes the same SimHash chunks and looks them up in the public index. If a registered note matches, it returns your asset ID, owner DID, and the chunk index — without ever seeing the rest of your note or your title.
• Hash-only disclosure (text). You publish the SHA3-384 of the note text. Anyone can re-hash a quoted passage and check it against your on-chain commitment. The text itself stays encrypted. This is the strict, exact-match path — use it when you need legal-grade byte-for-byte equivalence rather than similarity.
• Full reveal. You unlock the note, share the plaintext, and the verifier can replay the full chain: hash → chain commitment → your signature → your public key. Every link is post-quantum signed and timestamped.

Why this is genuinely private

• No bytes leave the device. Images and video are reduced to fingerprints in your browser. The capsule that travels to Aegis is roughly 4 KB regardless of the file size, and it cannot be inverted to reconstruct the original — that's not how perceptual hashing or semantic embedding works.
• No identity in the capsule. Aegis stores an opaque owner ID derived from your DID; the DID itself is did:maatara:<sha3-384(ownerPublicKey)>. There is no name, email, or wallet address anywhere in the public record.
• No plaintext on the server. Your encrypted note block is sealed with a per-note content-encryption key wrapped by the ratcheted notes key. Even Ma'atara cannot read it.
• Post-quantum by construction. Signatures are ML-DSA-65, hashes are SHA3-384, key encapsulation is ML-KEM-768. Nothing in the chain relies on RSA or ECDSA.

How text matching works

Aegis Layer T is the similarity index for prose, alongside the existing image (Layer C / PDQ + DINOv2) and video (Layer E / TMK+PDQF) layers. When you protect a note, every 200-word slice of the body is reduced to a 256-bit SimHash over its k-gram shingles. The shingles are SHA3-384 hashes of overlapping 5-word windows, so the SimHash captures the shape of the prose — word choice, ordering, phrasing — not its exact bytes.

That means someone can paste a single paragraph back into Verify even if they only quote a portion of your original, reformat the punctuation, or change the casing — and Aegis will still match the chunk and return your asset ID. None of your original words are stored: a 256-bit SimHash is information-theoretically far too small to recover the source text. The chain commitment is still the legal-grade, byte-for-byte anchor; Layer T is the discoverability layer on top.

PATENT PENDING — Ma'atara Protocol. Aegis Provenance Fabric · Veritas Chain.