Skip to main content
Alethea Protocol

Minimal example

One example, among all possible.

This demo isn't the protocol, the protocol is a spec. This is a minimal example of what a builder could ship on top of it. It covers content fingerprints, the hardest technical piece.

Two steps. Sign content, then verify it. Verification takes a file upload or a public URL, same action, two ways in.

Demo scope

This demo covers pHash computation and matching robust to recompressions and video trims. It does not wire KYC, cryptographic signature, or on-chain writes. The registry here is a JSON file, reset regularly. This is deliberate: we show the hardest technical part, the rest is product integration that depends on the builder.

To understand how to ship a complete product, see Build with Alethea.

01SIGN

Create a signature

Sign a content into the demo registry. The hashes are computed server-side from your uploaded file, then stored in a shared JSON registry for this public demo.

png, jpg, webp, gif, mp4, mov, webm. Max 50 MB.

In the full protocol, this would be a cryptographic signature bound to a verified identity (eIDAS / NIST / ISO). Here, free text for demonstration.

02VERIFY

Check if a content matches a signature

Two ways to feed the verifier: upload a file (the same one you just signed, or a recompressed version), OR paste a public URL and the verifier downloads it. Either way, perceptual matching looks for the closest signature in the registry.

Same formats as step 01. Try a recompressed, resized, or trimmed version of the file you signed to see perceptual matching at work.

Direct image/video link, or X / YouTube / Instagram public page (download via yt-dlp).

Hamming distance between pHashes. 0 = strictly identical, 8 = tolerates recompressions and resizes, 16+ = permissive (false positives possible).

How it works

  1. 1You upload a content (image or video). The API computes one or several pHash via imagehash.phash. For videos, ffmpeg extracts one frame per second, each frame is hashed.
  2. 2The signer (free label in the demo, verified identity in the full spec) is bound to the list of hashes and to the timestamp, written to the registry.
  3. 3On verification, the same computation runs on the submitted content. The algorithm seeks the best match in the registry via sliding window (tolerant to trims, re-encodes, resizes).
  4. 4If the average Hamming distance between the submitted pHash and the registered pHash is under the threshold (8 by default), it is a match. Otherwise, no match.
Build with Alethea Read the full spec Contribute