Help & documentation

Using Parable

Parable opens into your notes. Choose New note to begin, use the search field to find words across titles and bodies, and select a tag to narrow the list. Your in-progress writing is held in memory while you work, so an unsaved draft does not survive a reload or browser restart.

1. Identity as architecture

Every Parable account is a decentralised identifier of the form did:maatara:<base64url(sha3-384(base64url(publicKey))[0..24])> — hashing the base64url text of the public key, not its raw bytes, and keeping the first 24 bytes of that digest. It is created locally from a 24-word recovery phrase. A passkey assists local unlock where the browser exposes the required WebAuthn capability; that does not make the ML-DSA key hardware-bound. The signing key uses NIST FIPS 204 ML-DSA-65 ; the key-encapsulation path uses NIST FIPS 203 ML-KEM-768 . Both are deterministically derived from the recovery phrase, so the same person on the same phrase always re-derives the same DID.

The account DID is derived from the public signing key rather than an email address. Protected protocol mutations use ML-DSA-65 assertions or signed records where their route contract requires them; public reads, OAuth, health checks and every response are not universally signed. A verifier who has the evidence and public key can check whether that key signed the record. That does not by itself establish a person's legal identity, authorship, ownership, truth, or an independently witnessed time. Signing happens in your browser rather than on dedicated hardware — see how Ma’atara secures your connection ↗ for what that trade-off actually means.

2. The Notes app

The Notes app is the everyday face of Parable. It looks like a familiar private notebook with plain-text notes, attachments and version history — but underneath, every note is a signed object in your personal chain. The mechanics:

• On-device editor. The note title, body, tags, attachment names/types and plaintext hashes stay inside a DID-bound AES-256-GCM envelope. The normal sync path sends ciphertext, an opaque SHA3-384 envelope commitment, attachment ciphertext hashes, public identity material and operational timestamps—not readable note metadata.
• Version history. Each save is a new signed block referencing the previous one. You can browse the saved versions available for a note and open a read-only preview. The service-recorded time is not an independent timestamp.
• Attachment integrity. Parable encrypts note files for normal sync and records opaque ciphertext hashes used to detect a changed payload before opening it. The file name, type, plaintext hash and decryption IV remain inside the encrypted note envelope.
• Optional content checks. Choose Let others check this content later on a note to add a one-way matching record to the public provenance index. The note itself is not uploaded or made public. Fingerprints still carry matching and privacy risk. See How Ma’atara Provenance protects your notes ↗.
• AI chat exception. Where the Notes product offers an AI chat action, it is a Notes-app feature, not part of the Ma’atara protocol or the Veritas canonical architecture. The prompt and selected context are an explicit plaintext egress to the selected model provider; this is separate from encrypted Notes sync. The product may record a SHA3-384 commitment and limited metadata, but a chat turn is not automatically a durable Veritas evidence record.
• Cross-device. Today, that means pairing a browser you trust or restoring on a fresh one with your recovery phrase, then fetching the encrypted note chain; the service stores signed chain records, ciphertext and associated metadata, and the decryption material remains locally controlled. A phrase-free “authorise this browser” flow — the new browser makes its own key and the identity portal, where your root key lives, approves it — is built and switched off here. It also needs an identity minted at that portal, so an identity created in Parable keeps using the phrase until its owner moves it there.
• Removing a device. Revoking a device from Settings → Devices removes it from your list and asks it to stop; today, enforcement is cooperative — the device itself has to reconnect and see the removal before it stops, rather than a server refusing it outright. Anything that device signed while it was trusted stays valid, because it genuinely was signed while trusted. Rotating your key instead (if your key material may have been copied) retires the old key everywhere immediately.
• Migration boundary. Native Notes accepts only the ratcheted v2 envelope. Older records are returned as non_native_note_record and are not decrypted or adapted. If you have a user-controlled plaintext export, create a fresh native identity and re-save the notes through the native flow; the isolated migration guidance endpoint can explain the transition but never receives note content or keys.
• Export formats. A readable export decrypts notes and files in the browser before writing them to POSIX ustar archives. An encrypted backup preserves the stored ciphertext. Large exports are split into numbered parts, with a separate JSON manifest listing their entries and sizes. This export is also the honest answer to what happens to your data if Ma’atara shuts down ↗.

3. Veritas — your personal chain

Veritas is the per-user, append-only chain that records every consequential action on your DID — note saves, key rotations, provenance registrations, consent statements, device pairings. Each covered block is an ML-DSA-65-signed JSON envelope containing the SHA3-384 hash of its payload and a hash pointer to the previous block.

R2 is the authoritative server-side store for signed chain blocks and encrypted objects; D1 is a read projection and KV is used for caches and coordination. The service therefore observes ciphertext and protocol metadata, and it can be required to disclose what it stores. Client-held keys protect note plaintext, while signatures and hash linkage make record changes detectable under the stated key-custody assumptions. You can browse the chain in the plain-language History page. Verification APIs and record formats remain in Developer endpoints.

The native canonical evidence target is the exact maatara/veritas/block/v4 authority and evidence contract: user-key-derived ownership, typed authority transitions, ML-DSA-65 signatures, SHA3-384 commitments and ciphertext-only payload references. The current Core service uses a separate exact maatara/core-chain/block/v3 ciphertext carrier for product transport; that carrier is not the Veritas v4 shape and must not be described as a native Veritas v3 or v4 proof without the canonical validator and preimage.

4. Ma’atara Provenance — public provenance fabric

Ma’atara Provenance is the public side of provenance. Where Veritas is your private ledger, Ma’atara Provenance is the global, queryable index where you can register derived fingerprints so another party can compare content and verify a signed provenance claim. The claim is evidence of a key's assertion, not standalone proof of authorship.

It measures each work several ways: a cryptographic hash of the exact bytes, fingerprints that survive cropping and re-encoding, and — for images and video — a descriptor that recognises the same subject after heavy editing. Prose is measured by the shape of the writing rather than its exact characters, so a quoted passage still matches after reformatting. All of it is computed on your device. These measurements are one-way and are not designed to reconstruct the source, but they are not anonymous either: they can be compared against material someone already holds, and should not be treated as zero-knowledge disclosures. You can register, query and verify against Ma’atara Provenance from Detect ↗ and Verify ↗, and the explainer for what leaves your device is at What leaves your device ↗.

5. AI consent Coming soon

Modern AI systems are trained on the open web — usually without asking the people who wrote it. Parable will let you attach a machine-readable consent statement to any content you publish, following the IETF AI-Pref Internet-Draft, and sign it under your DID so a verifier can attribute the statement to that key. The draft does not make crawlers enforce the preference.

The consent worker (consent.ma-atara.io) stores a SHA3-384-keyed record of your preferences (training, fine-tuning, retrieval-augmented use, derivative works, attribution requirements) and serves them under the canonical AI-Pref endpoint. Crawlers and model providers can choose to resolve a content URL → AI-Pref policy → signed statement over HTTPS. Support and enforcement depend on each recipient. A public preview is wired up at Ma’atara Provenance consent page ↗; the full publisher dashboard ships next.

6. Privacy & the keyed email linkage

One of the hardest problems in a self-sovereign identity system is continuity: how do we recognise that an account signing in today on a freshly-wiped device is the same person who created an identity here last year — without keeping a copy of their email, name or any other linkable identifier on a server that could one day be breached, subpoenaed, or quietly mined?

Parable's answer is a deliberately one-way email linkage. When you sign in with a Google OAuth flow, the auth worker takes the verified email address, normalises it, and computes an HMAC-keyed hash using a server-side secret held outside source. The design persists the keyed index rather than the full address. The KV key is account:h:<hash>; the plaintext email not intended to retain the full address after the request completes.

This is a privacy-reducing keyed index, not a zero-knowledge proof:

• A database-only attacker cannot directly recompute candidates without the HMAC secret. An attacker who also obtains that secret can test likely email addresses, so secret custody, rotation and access control remain material.
• We can still answer the only question we need to ask — "have we seen this email before?" — by hashing the new sign-in with the same secret and checking for a match. Yes/no, nothing more.
• Audit rows store only the first 16 hex of the hash plus a redacted display form (r***s@gmail.com) so operators can investigate abuse with reduced exposure. Redacted values and truncated hashes are still account-related data, not anonymity.
• Your DID and public keys are necessarily sent to protocol services. The current browser implementation keeps the recovery phrase, passkey private credential and ML-DSA secret material local; the normal Notes sync path sends encrypted note data rather than plaintext. Separate export, support and AI features require their own disclosed data-flow review.

This linkage is what powers the "Welcome back" chooser: when a known email signs in on a wiped device, we can offer to restore their existing DIDs from their recovery phrase instead of silently minting a new orphan identity — without us ever having had a list of email addresses to compromise in the first place.

7. The provenance packages

Under the hood Parable is composed of a small number of focused services, each with a single responsibility and a clear cryptographic contract:

These services are deployed on Cloudflare Workers, but their route contracts are not identical. Protected mutations use ML-DSA-65 assertions or signed objects where documented; public reads, health requests and responses are not universally signed. A separate Rust workspace compiles the post-quantum primitives to WebAssembly so the same code paths run on the edge and in your browser.

8. Developer endpoints

Signed-in accounts can drive the entire protocol from outside the Parable UI. Authentication and signature requirements vary by route; use the live capability and API documentation rather than assuming every endpoint accepts the same envelope or returns a signed receipt. Browser routes are CORS-scoped for the parable.social origin. The technical service monitor shows live status, while the integration guide documents supported entry points. A pragmatic subset:

The complete machine-readable spec and signed schemas are exercised in the technical service monitor for live status and Developer integration for supported compose and share entry points.

Building a one-click Share to Parable button or a Create note action into another app? See the dedicated integrator guide — it documents the compose URL contract, the data shape and the privacy guarantees.

9. Who we build for

Ma'atara is a protocol, not a product — and we're actively looking for partners and integrators to put it under their own workflows. If you recognise your work in any of the patterns below, we'd like to talk. We're committed to re-grounding the trust axis of digital life: who made this, when, and under what consent. Everything else follows from that.

Creators & journalists

Create signed evidence that a key committed to a photograph, article or draft at the service-recorded time without uploading the original content in that workflow. Public-chain anchoring is not yet running, so the timestamp is not independently witnessed. Built for breaking news, manuscripts and evidentiary photography, where the priority order is first, intact, attributable.

Enterprises & regulated industries

Post-quantum signing for documents, model artefacts, software releases and audit trails, with hardware-rooted profiles remaining roadmap work. Veritas chains give you a tamper-evident internal ledger; Ma’atara Provenance lets you publish only the fingerprints external auditors need. Designed to drop in alongside existing SIEM, HSM and compliance pipelines rather than replace them.

Research & integrity

The replication crisis is, at heart, a provenance problem: methods, parameters and datasets that cannot be reconstructed from what was published. Parable lets researchers pre-register hypotheses, sign the full methodology and pin the dataset fingerprint with an ML-DSA-65 signature and service-recorded time. That is tamper-evident evidence, not an independent timestamp or proof that the method was followed. We see replicable research and reproducible method as a critical frontier and are actively shaping integrations for that work.

AI labs & model providers

Resolve a published IETF AI-Pref draft preference for content you crawl, with a signed statement you can retain in a training-set manifest. Adoption and enforcement remain voluntary. Good-faith consent handling without re-implementing crawl infrastructure — and a clean audit trail when the regulator asks how you knew.

Regulators & platforms

Verify signatures and compare provenance signals against a public index without the original content being stored by that registration workflow. This can support an authorship assessment but does not prove authorship or remove dependence on Ma'atara service availability. The roadmap targets C2PA interoperability and the emerging duty-of-care provenance regimes.

Everyday users

A really nice notes app where the words you write stay yours — readable on authorised devices, encrypted in normal server storage, and accompanied by evidence showing which key signed each recorded version.

Partners & integrators

If you ship anything where authorship, consent or evidentiary integrity matter — a CMS, a journal platform, a model registry, a court e-filing system, a creator marketplace — Ma'atara is designed to slot underneath it. Reach out at parable.social.

Parable is the application layer; Ma'atara is the protocol. The protocol is patent pending. The active native and WASM protocol paths use NIST-standard ML-DSA-65, ML-KEM-768 and SHA3-384 primitives; that does not certify the whole product. Signatures can verify integrity and key authorization, while availability, service-recorded time, indexing and current deployment state still involve operational trust. Inspect available evidence on the Ma’atara Provenance Verify ↗ page.

PATENT PENDING · Ma'atara Protocol · parable.social