Content Provenance and Digital Signatures
Generative AI can produce convincing video, audio, images, and text of people who never said or did what the content depicts. You have no reliable way to tell, by looking at or listening to a piece of content, whether a real person created it. Neither does anyone else.
The standard response is detection: train classifiers to spot AI-generated content, watermark AI output so it can be identified later, and look for artifacts in generated media. Detection is an arms race. The detector must catch every fake. The attacker needs to fool it once. Each generation of AI closes the gap between generated and genuine content. Detection tools that work today will degrade as models improve.
not.bot™ takes a different approach. You sign your content with a cryptographic signature bound to your verified identity. Anyone who encounters that content can check the signature. Unsigned content gets appropriate skepticism. Signed content carries proof that a specific verified human reviewed it and approved it.
A signature is an identity, not a key
Traditional digital signatures (PGP, S/MIME) bind content to a cryptographic key. A verifier who encounters the signature needs a separate channel to figure out who owns that key. Key directories, certificate authorities, and webs of trust all exist to bridge this gap between "someone with key X signed this" and "a specific person signed this."
A not.bot signature carries the signer's identity with it. Each signature includes:
- The signer's alias DID, a decentralized identifier the signer controls
- A message the signer composed describing what they're signing
- Credentials, including at least the not.bot credential proving the signer is a passport-verified human
- A timestamp and nonce preventing replay
The signature also includes cryptographic proof that the holder of the alias's private key authorized its creation. That key lives in the device's encrypted database, protected by the device's secure element. Creating a signature requires biometric authentication (FaceID, TouchID, or the device passcode) at the moment of signing.
A verifier doesn't need a pre-existing relationship with the signer. The signature itself describes what kind of entity signed, what credentials they hold, and what they attested.
What the signer signs
A not.bot signature is the signer's whole identity acting, not a detached key. The signer's DID rides inside the signature. Anyone who reads the signature resolves who signed from the signature itself, checked against the chain, with no certificate authority and no key directory to look up.
The signer signs a message, the content being attested to, and can bind a self-attested timestamp and a nonce into the same signature. A verifier cannot peel any of them off the signature, and cannot move the signature onto other content.
The timestamp is the signer's own attested time. A verifier weighs it as a self-attested claim from the signer, not a notarized stamp from a third party.
When you sign in response to a not.bot Verify request, your signature embeds a complete copy of that request: the server that asked, its domain, the nonce, and the claims it requested. The server signed its request, so your signature and the server's request bind together into one record. The signer cannot later deny producing the signature, and the requesting server cannot deny asking for it. No tool surfaces this embedded request today, but it rides inside every Verify signature, so a captured signature traces to both the person who produced it and the site that requested it.
For the formal message model, see did:julia Message Model. For how credentials ride inside a signature, see Credentials.
Verified Signer badges
A basic not.bot signature proves "a verified human signed this." For deepfake defense, that claim is necessary but insufficient on its own. The threat is impersonation of a known person. A politician, journalist, or creator needs to prove that they signed something, with a persistent public persona their audience recognizes.
Verified Signer badges give public figures a consistent, verified identity across platforms. A creator's badge appears in their signatures, linking the content to a persona their audience knows. The badge is tied to their not.bot identity, which traces back to a passport-verified human, but the badge itself does not expose the creator's government-issued name or documents. You can maintain a verified public persona across communication channels without revealing your legal identity.
Signature encodings: matching the channel
A not.bot signature is one cryptographic structure. The encoding changes depending on where the signature needs to travel.
QR code signatures store encrypted data on Julia Social's servers. The QR code image contains a randomized URL, a decryption key, and a hash of the signature data. Julia Social cannot read the contents: the decryption key exists only in the QR image and in the scanning app's memory. Julia Social cannot alter the stored data without detection, because any modification would fail verification against the hash embedded in the QR code.
JAB code signatures use the JAB (Just Another Barcode) format, a high-density color barcode that stores more data than QR codes. JAB signatures are self-contained: the entire signature, compressed to fit, is encoded in the image. No server is contacted to create or verify a JAB signature.
Audio encoding for audio-only channels is on the roadmap.
The cryptographic structure is the same in both visual formats. New encodings can be added for new channels as needed.
Why signatures should be visible
A signature that nobody knows about doesn't get checked.
Invisible metadata, no matter how durable, requires the recipient to know in advance that a credential might be embedded and to use a specific tool to look for it. Few people will do this. Few people know what C2PA is, let alone that they should be checking for invisible content credentials.
A QR code or JAB code printed on or alongside content says "scan me." The signature's presence is self-evident. A viewer who encounters a signed photograph, video, or document sees the code and understands that verification is available. The visual encoding serves as both the signature and the call to action.
This is a deliberate design choice with a tradeoff: a visible signature takes up space in the image. not.bot accepts that tradeoff because a signature that reaches the viewer and gets checked is more valuable than an invisible one that doesn't.
Surviving hostile distribution channels
Visibility also solves a durability problem. Social media platforms strip embedded metadata when you upload content. They remove C2PA manifests, EXIF data, invisible watermarks, and any information attached to the file rather than visible in the content. Instagram, X, and Facebook all do this during upload processing. Screen-recording, screenshotting, and re-photography destroy embedded metadata the same way.
QR code and JAB code signatures (patent pending) survive these channels because the signature is part of the visible content. Any copy, screenshot, re-encoding, or re-photograph that preserves the visible image preserves the signature. A printout of a signed photograph carries the signature. A phone recording of a signed video carries the signature.
How not.bot complements C2PA
C2PA (Coalition for Content Provenance and Authenticity) is an industry standard backed by Adobe, Microsoft, Sony, Google, the BBC, and others. C2PA lets cameras and editing software attach a tamper-evident record to a file, tracking how it was created and modified. If someone edits a photo in Photoshop, C2PA records that edit. If someone crops a video, C2PA records the crop. C2PA-aware tools carry this record forward as the file moves through production.
C2PA adoption is real and growing. Leica, Sony, Samsung, and Google ship cameras and phones that sign photos at capture. The C2PA Conformance Program maintains a public registry of certified products. EU AI Act Article 50 enforcement begins August 2026, requiring machine-readable labeling of AI-generated content, and C2PA satisfies that requirement.
C2PA tracks the device and the software. It does not track the person. A camera that records a deepfake playing on a screen produces a valid C2PA record for the resulting file. The record proves the camera captured the image. It says nothing about whether a specific human stands behind the content.
not.bot adds the human layer. A verified human signs the content, attesting that they vouch for it. C2PA catches tampering in the production pipeline. not.bot catches impersonation and fabrication at the source. Running both gives you coverage that neither provides alone.
The Creator Assertions Working Group (CAWG) is building the specification-level bridge between device provenance and human identity. CAWG's Identity Assertion specification lets a verified human sign within a C2PA manifest. The specification supports decentralized identifiers, which is the identifier format not.bot uses. The architectural path for embedding not.bot credentials in C2PA manifests exists, though Julia Social is focused on its visible-signature approach, which addresses the discoverability and metadata-stripping problems that manifest-level integration would not solve.
Three complementary approaches to content authenticity:
- C2PA manifest. Protects file integrity through the production pipeline, from capture through editing and publishing. Stripped by most social platforms during upload.
- Durable watermarking. Protects against re-encoding and casual modification through invisible embedded signals. Degrades under sufficient compression and format conversion.
- Visible not.bot signature. Survives any distribution channel that preserves the visible image, and tells the recipient that verification is available. Requires space in the image.
The three approaches cover different failure modes. Where one breaks, another holds.
not.bot Signer: signing content at scale
The not.bot app handles occasional signing: you compose a message, authenticate with your biometric, and produce a QR or JAB code. For public figures and brands who sign content several times a day, the app alone adds too much friction.
not.bot Signer is a web-based tool designed for regular, high-volume signing, launching at the end of June 2026. You upload content (video, images, PDFs, links, or posts), write a title and description, and sign. Signer hosts a known-good copy of the signed content at a permanent verification URL. Anyone who encounters the content elsewhere can use the not.bot app to compare it against the hosted original.
Signing through Signer still requires the not.bot app on the signer's phone. The web interface handles content management and hosting. The phone handles biometric authentication and cryptographic signing. The signing key never leaves the signer's device.
Content Signing & not.bot Signer is the product document: the signing workflow for teams, the content types, the known-good hosting model, pricing, and the privacy properties.
Verifying a signature
You do not need a not.bot identity to verify signatures. Downloading the app gives you verification capability without enrollment.
The app verifies QR and JAB signatures because those are the visual encodings it can capture through the device camera, photo library, screenshots, or video frames. Point the camera at a QR or JAB code, and the app fetches (for QR) or extracts (for JAB) the signature data, verifies it against the blockchain, and displays the signer's alias, their message, any included credentials, and the revocation status of those credentials. For signatures created with not.bot Signer, the message includes a link to the durable, encrypted original version hosted by Julia Social and the hash and decryption key needed to verify and view it.
Websites and services verify signatures through not.bot Verify, which runs inside the business's own infrastructure. The not.bot app on the user's phone communicates with the business's Verify server to present credentials. No user data flows to Julia Social during this process.
Privacy properties of signatures
C2PA credentials can contain creator identity information. The World Privacy Forum has documented the privacy risks: embedded identity metadata can expose journalists, activists, and whistleblowers to identification they did not intend. C2PA allows redaction, but consumer tools for managing this are not yet mature.
not.bot signatures take a different approach to signer privacy.
Every signer can have as many unique aliases as they need to compartmentalize their exposure as they sign content. Particularly sensitive aliases can be marked hidden so that they do not show up in the app user interface, except when an additional action is taken to reveal them, which requires a biometric or passcode verification.
Julia Social cannot read QR code signature contents. The decryption key and hash exist only in the QR image and in the verifying app's memory. Julia Social cannot determine what a signature says, who created it, or when someone verified it.
JAB code signatures never touch Julia Social's servers at all. Creation and verification happen between the signer's device, the verifier's device, and the Chia blockchain.
QR code verification requests use randomized URLs, require no authentication, and discard IP addresses without logging. Julia Social does not track who verifies what.
The signer controls which alias and which credentials to include in each signature. A signer can use different aliases for different contexts, and those aliases are cryptographically unlinkable. A signature reveals only what the signer chose to reveal.
For the full formal treatment of privacy properties (P1 through P12), see the Privacy Architecture document.