Every Othra takedown carries a cryptographic claim — proof that the request comes from a biometrically verified human, not a script, not an impersonator. Platforms can confirm it independently, on a public URL we publish.
Imagine writing a letter to Instagram saying "this is a fake video of me — please take it down." How does Instagram know it's really you who wrote it? Today, they don't. Anyone can copy that text and send it about anyone.
Othra changes that. We attach a digital "seal" to every takedown letter — a kind of cryptographic fingerprint that proves you are a real, verified person who actually scanned the suspicious content. The platform can check the seal at our public verification page. If the seal is broken or missing, the request is probably fake.
We give your takedown letter the same kind of trust a notarized document has — except faster, free, and built for the internet.
Takedown requests today are unauthenticated text. Anyone can impersonate anyone in a copy-pasted email. Trust & Safety teams compensate with manual review queues that scale linearly with abuse — which means they don't scale at all.
Othra issues a tamper-evident verification block alongside every takedown. Each block is HMAC-SHA256-signed over a canonical payload binding the user's identity, biometric fingerprint, and scan event into a single artifact. A reviewer can ingest the block, validate its structure on a public endpoint, and (in v2) verify the full signature against our audit log.
Authenticated identity claim ≈ HMAC<SHA256>(canonical_payload, issuer_key), plus a public verify URL that returns a structural and authenticity check.
The whole protocol is invisible to you. You scan, you tap "Create Takedown Request," Othra does the rest. Here's what happens behind the curtain.
Each takedown invocation in the client triggers three sequential primitives. The signing key never leaves trusted code paths; the audit record never leaves Othra infrastructure.
When you first open Othra, you sign in with Apple and complete a quick liveness check — Othra confirms there's a real person behind the camera, not a photo or video. You add a few reference photos to your private vault. That's your identity.
Apple Sign In yields a stable user identifier. Apple Vision framework performs on-device liveness detection (head pose multi-axis check). Reference face embeddings are extracted on-device; only their hash and storage path persist.
When you generate a takedown, Othra mixes who you are, the scan you just ran, and the moment in time into one compact "seal." Tampering with any part of it breaks the seal, so anyone checking later can tell something's wrong.
A canonical payload concatenates identity pseudonym, scan metadata, and timestamp. We HMAC-SHA256 the payload using an issuer key, producing a 256-bit signature. The verification block is rendered into the takedown letter in human-readable form, with a token encoding pointer into our audit log.
The letter the platform receives has a link (othra.ai/verify/...). Anyone who clicks it sees a clean page showing the seal's details — issue time, verification class, cryptographic fingerprint. If anything's altered, the page shows a warning instead.
Each request includes https://othra.ai/verify/<token>, where the token base64url-encodes a compact pointer (verification ID + payload digest + signature prefix). The public verifier validates token structure and signature prefix; the v2 endpoint will perform a full server-side lookup against our audit log.
Below is roughly what a Trust & Safety reviewer at Instagram or TikTok sees attached to your takedown letter. Each field has a purpose, and none of them reveal personal information about you.
The block is a deterministic, monospace-formatted record appended to the localized takedown letter body. Field ordering is fixed; whitespace is canonicalized to enable byte-identical reproduction for signature verification.
| Verification ID | A unique receipt number for this specific takedown — like a tracking code. |
| Verified at (UTC) | The exact moment your scan was signed, in Universal Time. |
| Identity provider | How we confirmed you're you — Apple's secure sign-in plus a live face check. |
| User pseudonym | A scrambled version of your account ID. Doesn't reveal your name, email, or phone. |
| Biometric fingerprint | A one-way scrambled version of "this scan + this user." Cannot be reversed into your face. |
| Scan analysis ID | The internal reference for the AI scan that produced this result. |
| Vault match score | How closely the suspicious image matches your reference photos. |
| AI manipulation risk | Hive AI's estimate that the image was AI-generated or manipulated. |
| Cryptographic proof | The mathematical "seal" produced over everything above. The proof that nothing has been tampered with. |
| Verify URL | Where a platform reviewer can check the seal's authenticity in seconds. |
| Verification ID | Format OTH-YYYYMMDD-{16-hex}. Deterministic per signing event. Indexed primary key in Othra's audit log. |
| Verified at | ISO-8601 UTC, second precision. Used in canonical payload. |
| User pseudonym | Truncated SHA-256 over user_id ‖ pseudonym_salt. One-way; same user always renders the same pseudonym, but the salt prevents cross-system correlation. |
| Biometric fingerprint | SHA-256 over scan_id ‖ user_id ‖ biometric_salt. Binds a scan to a user without exposing the embedding. |
| Scan analysis ID | UUID v4 referencing the Hive analysis record. |
| Vault match score | Float 0–1, formatted as percentage. Derived from cosine similarity between query embedding and vault embeddings (Apple Vision). |
| AI manipulation risk | Hive deepfake-detection probability, 0–1. |
| Cryptographic proof | HMAC-SHA256 hex digest of the canonical payload (concatenated, delimiter-separated). 64 hex characters. |
| Verify URL | Public endpoint at /verify/<token>. Token encodes verification ID + payload digest + signature prefix in base64url. |
The exact concatenation order, salt strings, and key material for HMAC computation are not published. A reviewer can validate structural conformance against our public endpoint. Verified platform partners can apply for direct programmatic access.
The verification block is engineered to be tamper-evident, not revealing. None of these details appear in the letter or on the public verify URL:
The block is a pointer — enough to confirm a real verification happened, never enough to identify you to anyone but Othra.
Othra holds the audit trail. The world sees only an opaque proof. The two only connect if a court compels us — and even then, only for that one record.
We chose hashing over disclosure for every personally identifying field. The verification block is a commitment to data we hold — never a publication of it.
| Face embedding | Extracted on-device by Apple Vision. Stored on Othra Storage as encrypted blob; only the SHA-256 fingerprint references it in the verification block. |
| User identifier | Apple's stable sub (per developer team) plus Supabase UUID. Both pass through a salted SHA-256 before becoming the pseudonym. |
| Scan image | Uploaded for Hive analysis, retained 24 hours, then auto-deleted. The image itself is never referenced in the verification block. |
| Email / phone | Stored encrypted in Supabase Auth. Never referenced in the block. Never returned by the verify URL. |
| IP / device ID | Captured in Supabase server logs for security purposes only. Not part of the verification protocol. |
Every field in the block is either a one-way hash, a deterministic ID, or content the user voluntarily provided (URL, platform). No raw PII, no biometric template, no recoverable identity.
When a Trust & Safety reviewer at Instagram or TikTok opens your takedown letter, they see your request and the verification block. They can click the verify URL to confirm it's a real Othra claim — without leaving their browser, without creating an account.
The verification page shows:
The platform-facing verifier at /verify/<token> performs a layered check. Today it is structural; in v2 it will be cryptographic against our audit DB. In v3 it will expose a signed JWT for programmatic integration.
Verified platform partners will receive API keys for POST /verify/api/v1/check returning a signed JWT response. Contact legal@othra.ai.
v1 of Othra is a strong credibility statement — designed to survive human review and casual scrutiny. v2, in progress, moves the signing key off your phone and into Othra's servers, making the seal cryptographically forgery-proof.
v1's HMAC issuer key is bundled with the client. Sophisticated adversaries can extract it and forge structurally-valid blocks offline — though the audit log will not contain the corresponding record, so v2's server-side check would detect such forgeries.
Trust & Safety teams, security researchers, journalists, and partner platforms: we're listening.