SOURCE_URL: https://majikah.solutions/products/majik-signature/docs/verifying-documentation

---
title: "Verifying Signatures"
id: "verifying-documentation"
group: "majik-signature"
type: "products"
version: "0.4.0"
lastUpdated: "2026-09-05T00:00:00.000Z"
difficulty: "Beginner"
time: "10-15 minutes"
tags: [verification, digital-signatures, ed25519, ml-dsa-87, post-quantum, hybrid-crypto, tamper-detection, trust-models, tofu, contacts, offline, batch, folder, zip, multi-signature, sealing, trusted-timestamps, tsa, majik-universal-id, embeddable-widget, quick-mode, advanced-mode, chain-verification, revision-history, stamped-annotations, drawn-signatures, append-only, photo-stamping, audio-stamping]
---

# Verifying Signatures

> Complete guide to verifying post-quantum signatures — single files, multi-signer documents, text, folders, ZIP archives, and verification against a Majik Universal ID

## Overview
Learn how to verify Ed25519 + ML-DSA-87 hybrid signatures in Majik Signature. This guide covers single file and text verification, multi-signer files, seal verification, Trusted Timestamps, batch verification of folders and ZIP archives, trust models (contact vs. self-reported keys), per-signer result interpretation, and verifying a file against a signer's Majik Universal ID — either on their public profile page or through an embeddable verification widget on any website.

### What Does Verification Mean?

Verification proves that signed content: (1) originated from a specific cryptographic key, (2) has not been modified since signing, and (3) was signed at the claimed timestamp. Majik Signature uses hybrid verification — both Ed25519 and ML-DSA-87 signatures must be valid for a given signer's result to pass. If either algorithm fails, that signer's verification fails. Verification is fully public — you only need the signer's public keys (either from a known contact, self-reported in the signature envelope, or resolved from a Majik Universal ID). No private key is ever needed, making it safe to verify content anywhere. A file may carry more than one signature, so verifying a file returns one result per signer, not a single pass/fail. Batch verification extends this to entire folders and ZIP archives, verifying each file — and each signer within each file — individually and reporting per-file, per-signer results.

> **NOTE:** Access the verification interface from the Verify tab — the third tab in the top navigation bar. Use Quick Mode for a fast drag-and-drop check, or Advanced Mode for detailed technical inspection, paginated signatures, and per-signer detail.

### Quick Mode vs. Advanced Mode

Quick Mode is a fast, minimal drag-and-drop flow: drop a file, get a single overall valid/invalid result, done. It's the fastest way to answer 'is this file authentic?' without digging into per-signer detail. Advanced Mode exposes the full technical picture: every individual signer's verdict, algorithm-level checks, seal status, Trusted Timestamp detail, and flexible verification methods (contact-based, self-reported, or Majik Universal ID lookup). For a single-signer file with no seal or TSA, both modes will show the same underlying result — Advanced Mode simply shows more of it.

### Interface Layout (Advanced Mode)

In Advanced Mode, the Verify tab is split into two side-by-side panels. The left panel (input) is where you provide the content to verify — a signed file, plain text plus a detached signature, or a folder/ZIP for batch verification. The right panel (output) shows the verification result after the process completes. At the top of the panels is a mode toggle: File (blue), Text (green), or Batch (purple). Above the panels is the Verify Against selector, where you choose between self-reported keys (TOFU — trust-on-first-use), a specific contact from your directory, or a signer's Majik Universal ID. Below the input panel is a footer with action buttons.

### Trust Models: Contact, Self-Reported, or Majik Universal ID

Majik Signature supports three verification modes. Contact verification (recommended for people already in your directory) uses the public keys from a known contact you've imported. Self-reported verification (TOFU — trust-on-first-use) uses the public keys embedded in the signature envelope itself — cryptographically valid, but you should cross-check the signerId fingerprint against a known source before trusting it. Majik Universal ID verification resolves the signer's public keys directly from their published identity record — see the dedicated section below — which is often the fastest way to get a trusted result without first manually importing a contact. In every mode, the signature proves the content was signed by someone who controls the corresponding private keys — it's the trust model you choose that determines how confidently you can map that to a real-world identity. All trust models apply to batch verification — your chosen mode is used for every file in the batch.

> **NOTE:** TOFU mode shows a warning. When you select Self-reported keys, an amber warning banner appears reminding you to cross-check the signerId fingerprint against a known contact or Majik Universal ID before trusting the result. This is normal — TOFU is cryptographically valid but requires manual identity verification.

### Verifying a Signed File

1. **1. Open the Verify Tab**
   *Navigate to the verification interface*
   - Go to the Verify tab — third tab in the navigation bar
   - Choose Quick Mode for a fast check, or Advanced Mode for full detail
   - The interface loads in File mode by default

2. **2. Choose a Verification Mode**
   *Contact, self-reported keys, or Majik Universal ID*
   - At the top of the page is the Verify Against selector (Advanced Mode)
   - The default option is Self-reported keys — this uses the public keys embedded in the signature envelope (TOFU mode)
   - An amber warning banner appears: Trust-on-first-use mode. The public keys used for verification are self-reported inside the signature. Cross-check result.signerId against a known contact fingerprint or Majik Universal ID before trusting this result.
   - Alternatively, click on a specific contact from your directory, or enter/select a Majik Universal ID (e.g. a username or profile URL) to verify directly against their published identity
   - Each contact shows their display name, fingerprint (first 32 chars), and a badge: You (own account), Contact (external), No Keys (needs signing keys), or Selected (active choice)

3. **3. Provide the Signed File**
   *Drop the file you want to verify*
   - In the left panel (input), drag-and-drop the signed file onto the drop zone, or click to browse
   - The panel validates the file and checks for one or more embedded signatures
   - If a signature is found, a blue chip appears: ✦ Signature detected — for multi-signer files, the chip shows the total signer count (e.g. '✦ 2 signatures detected')
   - Below that is an Embedded signature info metadata preview, listing every signer with their Signer ID (first 28 chars + …), Signed at (timestamp), Content type (MIME type), and SHA-256 (first 24 chars + …)
   - If the file is sealed, a lock chip appears showing when it was sealed and by whom
   - If no signature is found, a red chip appears: ◌ No signature found — verification is blocked

4. **4. Preview the File (Optional)**
   *See what you're verifying*
   - Below the signature detection chip is an inline file preview for supported formats
   - Images display as thumbnails, audio shows a waveform player, video plays inline, PDFs render in an iframe, and text files show their content
   - The preview is purely for your convenience — it does not affect what gets verified

5. **5. Verify the Signature(s)**
   *Run the cryptographic verification*
   - Click the ◈ Verify button in the footer of the left panel
   - The right panel shows real-time progress through 5 steps, run independently per signer: ① Extract signature → ② Hash content → ③ Rebuild payload → ④ Ed25519 → ⑤ ML-DSA-87
   - Each step lights up as it completes: done (green) if passed, active (blue) if in progress, waiting (gray) if not yet started
   - If the file is sealed, an additional seal-check step runs, confirming the current signer set matches the sealed set
   - After a moment (typically under 1 second for files 

6. **6. Interpret the Verdict**
   *Understand the result — per signer*
   - For a single-signer file, the right panel shows one large verdict banner with one of four outcomes:
   - Signature verified (green) — both Ed25519 and ML-DSA-87 passed, hash matches, content is authentic and unmodified
   - Verification failed (red) — one or both algorithm checks failed — do not trust this content
   - Content tampered (red) — hash mismatch detected — the content has been modified after signing
   - Valid signature · unknown signer (amber) — cryptographically valid but signer is not in your contact list or resolvable Majik Universal ID — cross-check signerId before trusting
   - For a multi-signer file (Advanced Mode), each signer gets its own verdict banner, listed in signing order, so a partially-signed or mixed-validity document is immediately clear
   - If the file is sealed, a separate Seal verified / Seal check failed indicator appears — this confirms the signer set hasn't changed since sealing and is shown alongside, not instead of, the per-signer verdicts
   - Below each signer's banner is an algorithm checks row showing: ✓ SHA-256 hash, ✓ Ed25519, ✓ ML-DSA-87, and whether the signer is a known contact or resolvable identity

7. **7. Review the Metadata**
   *Inspect the signature details*
   - The right panel shows a metadata grid per signer with: File (original filename), Embed handler (e.g., 'PDF', 'WAV', 'MP4/MOV'), Verdict (the outcome), Signed by (signer's label or fingerprint), Fingerprint (first 32 chars + …), Own account (✓ Yes or No), Algorithm (Ed25519 + ML-DSA-87), Signed at (local timestamp, and TSA timestamp if present), Content type (MIME type), and SHA-256 (content hash, first 28 chars + …)
   - If a signer attached a Trusted Timestamp, a dedicated TSA badge shows the timestamp authority's identity and its own independently verified timestamp
   - At the bottom is the Embedded signature (base64) section for each signer — this is that signer's serialized signature envelope extracted from the file (click Copy to copy it)


### What to Do If Verification Fails

> ⚠️ **WARNING:** If a signer's verification fails (Verification failed or Content tampered verdict), do NOT trust that signature. Verification failed means one or both algorithms (Ed25519 or ML-DSA-87) rejected the signature — the cryptographic checks did not pass. Content tampered means the SHA-256 hash of the current content does not match the hash embedded in that signer's envelope — the file has been altered since that signer signed it. In a multi-signer file, one signer failing does not necessarily invalidate other signers' signatures — check each one individually — but treat the overall file with caution until you understand why a signer's check failed.

### Verifying a Seal

If a file has been sealed, its verification result includes a separate seal check alongside the per-signer signature checks. Seal verification recomputes a hash over the file's current list of signers and compares it against the hash that was stored when the file was sealed. A Seal verified result means the set of signers has not changed since sealing — no signer was silently added or removed after the document was finalized. A Seal check failed result means the current signer set doesn't match what was sealed, which should be treated as a serious red flag regardless of whether individual signatures still verify. Seal verification is a structural check on the signer list — it does not replace verifying each individual signer's Ed25519/ML-DSA-87 signature, and both checks should be reviewed together for a sealed file.

### Verifying Plain Text Signatures

In addition to files with embedded signatures, you can verify plain text against a detached base64 signature. This is useful when someone shares text + signature through email, messaging apps, or notes. The signature is not embedded in the text itself; instead, you need both the original text and the base64 signature string to verify. Text signatures are always single-signer.

### Verifying Text Signatures

1. **1. Switch to Text Mode**
   *Toggle the mode switcher*
   - At the top of the panels is a mode toggle
   - Click Text — the toggle turns green
   - The left panel now shows two text input areas instead of a file drop zone

2. **2. Choose a Verification Mode**
   *Contact, self-reported keys, or Majik Universal ID*
   - At the top of the page is the Verify Against selector
   - Choose Self-reported keys (TOFU mode), a specific contact, or a Majik Universal ID
   - The same trust model logic applies as with file verification

3. **3. Provide the Original Text**
   *Paste the text that was signed*
   - In the left panel, the first input box is labeled Original text
   - Paste the exact text that was signed — any character change invalidates the signature
   - Spaces, line breaks, and capitalization matter — the text must be byte-for-byte identical to what was signed
   - Below the text box is a character counter showing how many characters you've entered

4. **4. Provide the Detached Signature**
   *Paste the base64 signature string*
   - The second input box is labeled Detached signature (base64)
   - Paste the base64 signature string you received from the signer (from sig.serialize())
   - This is a long base64-encoded string containing the signature envelope

5. **5. Verify the Signature**
   *Trigger the verification*
   - Click the ◈ Verify button in the footer of the left panel
   - The right panel shows the same 5-step progress animation as file verification
   - After a moment, the verification result appears

6. **6. Interpret the Result**
   *Understand the verdict*
   - The right panel shows the same verdict banner and algorithm checks as file verification
   - The metadata grid shows: Verdict, Signed by, Fingerprint, Own account, Algorithm, Signed at, Content type (text/plain), and SHA-256
   - If the verdict is Valid or Unknown signer, the text is authentic and unmodified
   - If the verdict is Invalid or Tampered, the text has been altered or the signature is forged


> **NOTE:** Text must be byte-for-byte identical. If you change even one character, space, or line break in the text, the SHA-256 hash will change and verification will fail with a Content tampered verdict. Copy-paste carefully and preserve all whitespace.

### Batch Verification — Folders and ZIP Archives

Batch mode lets you verify an entire folder or ZIP archive of signed files in a single workflow. Switch to Batch mode using the mode toggle (purple). Drop a folder or ZIP onto the input panel — Majik Signature automatically extracts and recursively processes all contained files, verifying each one — and every signer within each — individually. The output panel shows a detailed per-file, per-signer results list: which files/signers passed (✅), which failed (❌), and why, plus seal status for any sealed files. Batch verification uses the same trust model as single-file verification — your chosen Verify Against setting applies to every file in the batch.

### Batch Verifying a Folder or ZIP

1. **1. Switch to Batch Mode**
   *Toggle the mode switcher*
   - At the top of the panels is a mode toggle
   - Click Batch — the toggle turns purple
   - The left panel now shows a batch drop zone and file list area

2. **2. Choose a Verification Mode**
   *Contact, self-reported keys, or Majik Universal ID*
   - Select your trust model from the Verify Against selector above the panels
   - The selected mode applies to every file — and every signer — in the batch
   - Use Self-reported keys for TOFU verification, select a known contact, or supply a Majik Universal ID for the trusted path

3. **3. Provide Files, a Folder, or a ZIP**
   *Drop your content onto the batch input panel*
   - Drag-and-drop one or more individual files, an entire folder, or a ZIP archive onto the input panel
   - Majik Signature automatically detects all files — if you drop a ZIP, it is extracted and all contents are recursively processed, including nested folders and nested ZIPs
   - The input panel displays a file list showing each detected file with its name, size, and type
   - Click the popup preview icon on any file to inspect it before verifying
   - Use the ✕ Remove button on individual files to exclude them from the batch

4. **4. Verify the Batch**
   *Trigger batch verification*
   - Click the ◈ Verify All button in the footer of the input panel
   - The right panel shows a per-file progress list — each file (and each signer within it) advances through the verification steps independently
   - The overall progress bar tracks total completion across all files
   - After all files are processed, the output panel shows a summary: total files, total signatures, successful verifications (✅), and failed verifications (❌)

5. **5. Review Per-File Results**
   *Inspect the verification outcome for each file and signer*
   - The right panel shows a detailed per-file results list, expandable to show each signer's individual verdict for multi-signer files
   - Each row shows: filename, verification verdict (✅ Verified / ❌ Failed / ⚠️ Unknown signer / 🔴 Tampered), signer fingerprint, and seal status if applicable
   - Failed entries show an inline failure reason (e.g., no signature found, hash mismatch, algorithm check failed, seal check failed)
   - Files that had no embedded signature are listed separately as unsigned — they are not failures, but they have not been verified
   - Shared metadata visible across all files — algorithm, verification mode, trust model — is shown in a summary panel above the file list


> **NOTE:** Unsigned files in a batch are reported separately. If a batch contains a mix of signed and unsigned files, the unsigned files are listed as 'No signature found' — distinct from verification failures. A verification failure means a signature was found but did not pass. An unsigned file simply has no signature to verify.

### Verifying Against a Majik Universal ID

Every Majik Universal ID publishes a hybrid Ed25519 + ML-DSA-87 public key bundle as part of its identity record. Because Majik Signature is the signing engine behind Majik Universal ID, any file signed by someone's Majik Key — whether through the Majik Signature app directly, or through their identity via signContent()/signFile() — can be verified against that same published identity, without you needing to manually import a contact first. This gives you a fast path to a trusted result: instead of TOFU (trusting whatever keys are embedded in the file) or manually exchanging invite keys, you resolve the signer's public keys directly from their Majik Universal ID.

### Verifying via a Majik Universal ID Profile Page

1. **1. Find the Signer's Majik Universal ID Page**
   *Locate their public identity profile*
   - Every Majik Universal ID has a public profile page at id.majikah.solutions/id/[username] — for example, id.majikah.solutions/id/thezelijah
   - Ask the signer for their profile URL, or look it up if you already know their username

2. **2. Open the Verification Dropbox**
   *Use the built-in verification widget on their profile*
   - Every Majik Universal ID profile page includes an embedded verification dropbox — a drag-and-drop widget scoped to that specific identity
   - This widget is pre-configured with the profile owner's published Ed25519 and ML-DSA-87 public keys — you don't need to select a trust model manually

3. **3. Drop the Signed File**
   *Provide the file to verify*
   - Drag-and-drop the signed file onto the profile page's verification dropbox, or click to browse
   - The widget extracts the embedded signature(s) just like the main Verify tab
   - If the file has multiple signers, only the signature(s) matching this profile's identity are checked against it — other signers are reported separately, unresolved against this particular identity

4. **4. Review the Result**
   *Confirm authenticity against this specific identity*
   - The widget shows a verdict scoped to this identity: Signed by [name/handle] (verified) or a failure/mismatch state if the file's signer does not match this profile's keys
   - Because the public keys come directly from the profile owner's published identity record rather than from the file itself, this result carries the same trust weight as manually verified contact-based verification — with no separate contact import step required


### Embedding the Verification Dropbox on Your Own Website

The same verification dropbox shown on a Majik Universal ID profile page can be embedded directly into a personal website, portfolio, or blog via an <iframe>. This lets you offer visitors a self-service way to verify that a file (an article, a downloadable asset, a piece of media) actually came from you — without them needing to visit your Majik Universal ID profile page separately or understand the underlying cryptography.

### Embedding the Verification Widget

1. **1. Get Your Embed Snippet**
   *Locate the iframe embed code for your identity*
   - From your Majik Universal ID profile page (id.majikah.solutions/id), locate the Embed Widget option
   - This provides an <iframe> snippet scoped to your specific identity and public keys

2. **2. Add the Iframe to Your Site**
   *Paste the snippet into your website's HTML*
   - Paste the provided <iframe> tag into your website, blog, or portfolio's HTML wherever you'd like the verification dropbox to appear
   - The embedded widget renders the same drag-and-drop verification dropbox as your public profile page, scoped to your identity's public keys
   - No API keys or backend integration are required — it's a self-contained iframe

3. **3. Visitors Verify Directly on Your Site**
   *Self-service verification for anyone visiting*
   - A visitor can drag-and-drop any file they believe you signed directly into the embedded widget
   - The widget checks the file's embedded signature(s) against your published Majik Universal ID public keys and shows a verdict inline — no separate app or account needed on the visitor's part
   - This is useful for content provenance on articles, downloadable resources, released media, or software artifacts distributed from your own site


> **NOTE:** An embedded verification widget is always scoped to the identity that generated the embed snippet — it can only confirm 'was this signed by [this specific Majik Universal ID]', not verify arbitrary signers. For general-purpose verification against any signer, use the main Verify tab in the Majik Signature app instead.

### Verdict Meanings

| Verdict | Color | What It Means | Trust Level |
| --- | --- | --- | --- |
| Signature verified | Green | Both Ed25519 and ML-DSA-87 passed, hash matches, signer is a known contact or resolved Majik Universal ID | ✓ Trusted |
| Valid signature · unknown signer | Amber | Cryptographically valid but signer not in your contact list or resolvable identity — cross-check signerId | ~ Verify identity first |
| Verification failed | Red | One or both algorithm checks failed — signature is invalid | ✕ Do not trust |
| Content tampered | Red | Hash mismatch — content has been modified after signing | ✕ Do not trust |
| Seal verified | Green (separate indicator) | The current signer set matches what was recorded at seal time | ✓ No signer added/removed post-seal |
| Seal check failed | Red (separate indicator) | The current signer set does not match the sealed set — investigate immediately | ✕ Do not trust the signer list |

*Caption: How to interpret the possible per-signer verification outcomes*

### Understanding the Algorithm Checks

Below each signer's verdict banner is an algorithm checks row showing four individual checks. ✓ SHA-256 hash (green) means the content hash matches the hash in that signer's envelope — the content has not been modified relative to what they signed. ✓ Ed25519 (green) means that signer's Ed25519 signature is valid — the classical signature passed. ✓ ML-DSA-87 (green) means that signer's ML-DSA-87 signature is valid — the post-quantum signature passed. ✓ Known signer (green) means the signer's fingerprint matches a contact in your directory or a resolved Majik Universal ID. ~ Signer unknown (amber) means the signer is not in your contact list or resolvable identity — the signature is valid but you should verify their identity. If any of the first three checks show ✕ (red), that signer's verification has failed. In batch mode, these per-check indicators appear inline for each file and signer in the results list.

### Verify Against Selector — Choosing a Trust Model

The Verify Against selector at the top of the page lets you choose how to verify the signature. Self-reported keys (default) uses the public keys embedded in the signature envelope itself. This is TOFU (trust-on-first-use) mode — the signature is cryptographically valid, but you don't know who owns those keys in the real world. An amber warning banner reminds you to cross-check the signerId fingerprint. Known contact verification uses the public keys from a contact you've already added to your directory. Majik Universal ID verification resolves the signer's public keys directly from their published identity record — enter their username or profile URL. If the signature's signerId fingerprint matches the resolved keys (from a contact or a Majik Universal ID) and both algorithms pass, you get a green Signature verified verdict. In batch mode, the same selector applies to every file and signer in the batch.

### Cross-Check Identity in TOFU Mode

> ⚠️ **WARNING:** When using Self-reported keys (TOFU mode), the verification proves the signature is cryptographically valid — but it does NOT prove who the signer is in the real world. Always cross-check the signerId (fingerprint) shown in the result against a known source: ask the signer directly via a trusted channel (Signal, in person, verified email), check their Majik Universal ID profile page, or compare against a fingerprint you've seen before. TOFU is useful for initial contact, but should be upgraded to contact verification or a Majik Universal ID lookup once you've confirmed their identity.

### Signature Detection — How It Works

When you drop a file in the input panel, Majik Signature scans it for one or more embedded signatures. The detection logic checks for: (1) Magic bytes and markers — PDF binary trailers, PNG iTXt chunks, WAV RIFF LIST INFO, MP4 udta boxes, Office ZIP entries, etc. (2) Universal trailer for Tier 2 formats — the 8-byte magic MAJIKSIG at the end of the file. (3) Structural validation — if a signature-like structure is found, it's parsed as JSON and validated against the envelope schema, with legacy single-signature files transparently promoted to the current multi-signer wrapper shape. If all checks pass, the ✦ Signature detected chip appears (with a signer count for multi-signer files) and the embedded metadata is extracted and displayed. If no signature is found, the ◌ No signature found chip appears and verification is blocked. In batch mode, this detection runs per file across all files in the folder or ZIP.

> **NOTE:** The metadata preview in the input panel is extracted before verification runs. This lets you see who claims to have signed the file and when — but it does NOT mean the signature is valid. You must click Verify to cryptographically confirm each signature.

### What Happens During Verification (Step-by-Step)

When you click Verify, Majik Signature runs through five steps for each signer found in the file. ① Extract signature — the signature envelope for each signer is parsed from the file's metadata or trailer and deserialized from JSON. ② Hash content — the file is stripped of its embedded envelope to recover the original bytes, which are then hashed with SHA-256. ③ Rebuild payload — for each signer, the canonical payload is reconstructed using that signer's own metadata: "majik-signature-v1:" + JSON({ v, id, ts, ct, hash[, alh] }). ④ Ed25519 — that signer's Ed25519 signature is verified against their Ed25519 public key (from the envelope, a known contact, or a resolved Majik Universal ID). ⑤ ML-DSA-87 — that signer's ML-DSA-87 signature is verified against their ML-DSA-87 public key. If a signer's envelope carries a Trusted Timestamp, its own signature is independently verified against the timestamp authority's keys. If a file is sealed, an additional check confirms the current signer list matches the sealed hash. If all steps pass and the hash matches for a given signer, that signer's verdict is Signature verified. If any step fails for that signer, their verdict is Verification failed or Content tampered. In batch mode, these steps run independently per file and per signer.

### Verification Steps Breakdown

| Step | What It Does | Failure Means |
| --- | --- | --- |
| ① Extract signature | Parse each signer's envelope from file metadata or trailer | File is not signed or envelope is corrupted |
| ② Hash content | Strip signature, hash original bytes with SHA-256 | Structural error — should not fail |
| ③ Rebuild payload | Reconstruct that signer's canonical payload string from envelope metadata | Structural error — should not fail |
| ④ Ed25519 | Verify Ed25519 signature against payload using signer's Ed25519 public key | Classical signature is invalid or forged |
| ⑤ ML-DSA-87 | Verify ML-DSA-87 signature against payload using signer's ML-DSA-87 public key | Post-quantum signature is invalid or forged |
| (If sealed) Seal check | Recompute hash over current signers, compare to the sealed hash | Signer set was altered after sealing |
| (If TSA present) Timestamp check | Verify the TSA's own Ed25519 + ML-DSA-87 signature and matching digest | Trusted Timestamp is invalid or digest mismatch |

*Caption: What each step of the per-signer verification process checks*

### Full Chain Verification — Drawn & Stamped Revisions

Signed PDFs that get annotated or drawn over, and signed photos or audio that get stamped, used to invalidate every existing signature — the underlying bytes changed, so the hash no longer matched. Majik Signature now tracks an append-only revision chain on the envelope: each new version (a drawn-over PDF, a stamped photo, a stamped audio clip) is cryptographically linked to the version before it, and every signer's original signature is preserved rather than wiped out. This is true multi-signature support across revisions, not just across signers within one static file. By default, the latest version of a file always carries its full chain history and every signature embedded — the standard per-signer verification described above already validates against this latest version with no extra steps.

### Why Verify the Full Chain?

Standard verification confirms the latest version's signatures are valid. Full chain verification goes further: you supply the actual prior-revision files — the ones signed by the issuer, the ones signed by other signatories along the way — and Majik Signature confirms the latest file's chain honestly reconstructs that lineage byte-for-byte, version by version. This is the maximum-assurance path: it proves not just that today's file is validly signed, but that nothing in its history was quietly swapped, skipped, or rewritten between revisions.

> **NOTE:** Full chain verification is optional and only appears when a loaded file's envelope actually contains a revision history. If a file has never been re-drawn or re-stamped after signing, there's nothing to chain-verify — standard per-signer verification is already the complete picture.

### Verifying a Full Revision Chain

1. **1. Load the Latest Version**
   *Drop the current file as usual*
   - In File mode, drop the most recent version of the file — the one you want to confirm is trustworthy
   - If its envelope contains a revision chain, a Verify Full Revision History toggle appears below the drop zone

2. **2. Enable Chain Verification**
   *Switch on the toggle*
   - Click the toggle to enable full chain verification
   - A new drop zone appears, prompting you to load every earlier revision of the file

3. **3. Load Every Prior Revision**
   *Drag and drop all earlier versions*
   - Drop every earlier version of the file you have — files signed by the issuer, and files signed by any other signatories along the way
   - Order doesn't matter — each file is matched to the chain by its content, not by filename or drop order
   - Files are de-duplicated by name and size if you drop the same one twice
   - Remove an individual file with its ✕ icon, or clear the whole set to start over

4. **4. Run Chain Verification**
   *Verify the full lineage*
   - Click Verify N Revisions
   - Each supplied file is matched against the recorded revision history and checked against its recorded position in the chain

5. **5. Review the Result**
   *Per-revision status*
   - The result panel shows a status for each revision in the chain: matched and valid, missing, or mismatched
   - Full chain verified means every recorded revision was supplied and every one checked out
   - Chain verification incomplete means some revisions in the signed history weren't matched by a file you supplied — not a failure, but not a complete picture either
   - Chain verification failed means at least one supplied revision didn't match what the chain recorded for that position — treat this as seriously as a failed signature


### Chain Verification Outcomes

| allValid | isCompleteSet | Outcome | Meaning |
| --- | --- | --- | --- |
| true | true | Full chain verified | Every recorded revision was supplied and matched — maximum assurance |
| true | false | Chain verification incomplete | The revisions you supplied all check out, but the history has entries you didn't provide a file for |
| false | true / false | Chain verification failed | At least one supplied revision doesn't match what the chain recorded — investigate immediately |

*Caption: How the combination of allValid and isCompleteSet maps to a result*

### Don't Confuse This With Notary Chain Anchors

> ⚠️ **WARNING:** The revision-chain loader described here (for prior file versions) is a distinct feature from Majik Notary's blockchain anchor loader, which loads an anchor export (a notarization receipt) rather than a prior file revision. Both are chain-related, both are drag-and-drop, but they verify different things: this section confirms a file's own edit lineage; a notary anchor confirms a seal hash was recorded on-chain at a point in time. If you're unsure which one you need, you're most likely looking for this section unless you're specifically re-checking a Solana notarization receipt.

### Handling Unknown Signers (Amber Verdict)

If a signer's verification passes cryptographically but they're not in your contact list or resolvable via a Majik Universal ID, you get an amber Valid signature · unknown signer verdict for that signer. This means: (1) Both Ed25519 and ML-DSA-87 signatures are cryptographically valid. (2) The content hash matches — nothing has been tampered with relative to what they signed. (3) BUT you don't have that signer's fingerprint in your trusted contacts, and no Majik Universal ID was resolved for them. The signature proves the content was signed by someone who controls the private keys corresponding to the public keys in the envelope — but it doesn't prove who that someone is. To upgrade this to a green Signature verified verdict, either add the signer to your contact directory (ask them to share their invite key, or manually create a contact with their public keys if you've obtained them through a trusted channel), or verify against their Majik Universal ID directly if they have one.

> **NOTE:** To add an unknown signer to your contacts after verification, go to the Majikah tab → Contacts section → click the plus (+) icon → paste their invite key → click Add Contact. Next time you verify their signature, it will show as Signature verified (green). Alternatively, if they have a Majik Universal ID, you can simply verify against that instead of managing a manual contact.

### Quick Reference

| Task | Panel | Mode | Notes |
| --- | --- | --- | --- |
| Verify a signed file | Left (input) + Right (output) | File | Drag-and-drop or browse |
| Choose verification mode | Verify Against selector (above panels) | Any | Self-reported (TOFU), known contact, or Majik Universal ID |
| Check for embedded signature(s) | Left panel — signature detection chip | File | ✦ Signature detected (with signer count) or ◌ No signature found |
| Preview file before verifying | Left panel — preview area or popup icon | File or Batch | Images, audio, video, PDF, text |
| Verify text + signature | Left (input) + Right (output) | Text | Paste text and base64 signature |
| Batch verify folder or ZIP | Left (input) + Right (output) | Batch | Per-file, per-signer results with pass/fail breakdown |
| View algorithm checks | Right panel — checks row | File or Text | SHA-256, Ed25519, ML-DSA-87, Known signer, per signer |
| View seal status | Right panel — seal indicator | File or Batch | Separate from per-signer verdicts |
| View per-file results | Right panel — file results list | Batch | ✅ / ❌ / ⚠️ per file and signer with failure reason |
| Copy embedded signature | Right panel — Embedded signature section | File or Text | Base64 string, per signer |
| Verify via a Majik Universal ID profile | Signer's id.majikah.solutions/id/[username] page | N/A | Uses that identity's embedded verification dropbox |
| Verify via an embedded widget | A website with the embedded iframe | N/A | Scoped to the embedding identity's public keys |
| Verify another file/text | Right panel footer | Any | Click 'Verify Another' to reset |
| Verify full revision chain | Left (input) + Right (output) | File | Only shown when the file's envelope has a revision history — load every prior version |

*Caption: Common verification tasks and where to find them*

### Privacy & Security Guarantees

All core verification happens entirely on your device. Your files and the verification result never leave your computer. Resolving public keys from a Majik Universal ID requires fetching that identity's published record, which is the one network-dependent step in an otherwise fully local process — no file content is ever sent anywhere for this lookup, only the identity being verified against is looked up. No server is required for core cryptographic verification itself, and you can verify signatures completely offline against contacts or self-reported keys — including batch verification of entire folders and ZIP archives. The hybrid Ed25519 + ML-DSA-87 approach ensures that even if one algorithm is unexpectedly broken, the other still provides security. For a signature to be forged, an attacker must break both algorithms simultaneously — which is infeasible even for quantum computers.

> **NOTE:** Verification against a known contact or self-reported keys works completely offline. Verifying against a Majik Universal ID requires an internet connection to fetch the identity's published record. Your files and verification results never leave your device either way.