# not.bot™: Cryptographic Identity Without Surveillance

The internet has no way to tell humans from machines. AI passes CAPTCHAs, generates convincing faces, clones voices, imitates writing styles, and operates social media accounts at scale. You cannot tell, with confidence, whether you are interacting with a person or a program. Neither can anyone else.

The obvious fix, requiring people to prove their real identity, trades one problem for another. You should not have to hand your government ID to a gambling site, a forum, or a social network. Businesses collecting that data take on a liability they do not want: data they hold can be leaked, hacked, or subpoenaed.

not.bot takes a third path. You prove specific things about yourself, with cryptographic certainty, without revealing who you are. The math behind a not.bot signature is unforgeable. No AI can produce one. No bot can fake one. And the site that checks it never collects the underlying data, because not.bot was built so the data does not leave your device.

Julia Social, the company behind not.bot, built the system so that Julia Social itself cannot access your identity information. The company does not know your name, your age, your nationality, or which sites you visit. It cannot read your signatures. It cannot correlate your aliases. The privacy guarantee is enforced by architecture, not by policy. Julia Social cannot leak data it does not have.

## Three products, one identity

not.bot is three products built on one identity infrastructure.

### not.bot app

The not.bot app runs on your phone. You enroll by scanning the NFC chip in your passport. The app verifies the passport's cryptographic signatures, confirms it is genuine and unexpired, and creates your digital identity. Your passport data stays on your device. Julia Social receives a cryptographic proof that you are a unique, real person with a real passport. That proof is enough to create an identity controlled by your device.

From that identity, you create aliases: separate identities for different contexts. Your professional alias. An alias for a forum. A throwaway for a site you will visit once. Each alias is cryptographically independent. Nobody, including Julia Social, can connect your aliases to each other.

You sign content by composing a message, authenticating with your biometric (FaceID, TouchID, or device passcode), and producing a cryptographic signature in the form of a QR code or JAB code you can attach to images, documents, videos, or posts. Anyone who scans the signature can verify that a passport-verified human created the signature, check any credentials the signer chose to include, and confirm the content has not been altered.

You verify other people's signatures by scanning their QR or JAB codes. You do not need a not.bot identity to verify signatures. Download the app and scan.

### not.bot Verify

not.bot Verify is server software that businesses deploy inside their own infrastructure. A website or service integrates Verify to request and check credentials from not.bot users.

Verify answers the questions businesses care about. Is this a human? Verify provides cryptographic proof, replacing CAPTCHAs that AI has defeated. Is this the same human who was here before? Site Passes give each person a unique, per-site token that prevents one person from creating multiple accounts, without revealing who they are. Is this person old enough? not.bot users can prove they are over 18, over 21, or within a specific age range, without the site learning their birthdate.

Verify runs in the business's own data center or cloud account. No user data flows through Julia Social during verification. The business controls its own infrastructure, its own data retention, and its own compliance posture. This matters for regulated industries. Healthcare organizations bound by HIPAA, financial institutions subject to data residency requirements, and government agencies pursuing FedRAMP can deploy Verify without routing sensitive interactions through a third party.

### not.bot Signer

The not.bot app handles occasional signing. 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 for regular, high-volume signing, launching at the end of June 2026\. You upload content, write a title and description, and sign. Signer hosts an encrypted known-good copy of the signed content at a permanent verification URL. Anyone who encounters the signed content elsewhere can compare it against the hosted original.  The decryption key is in the signature.  Julia Social doesn’t have it.

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 key never leaves the signer's device.

[Content Signing & not.bot Signer](http://doc_03A_content_signing.md) covers the product in full: how a team signs day to day, the content types, pricing, and the privacy properties.

## Content provenance: verify the authentic

Detecting fakes is an arms race. The detector must catch every forgery. The attacker only needs to fool it once. Each generation of AI narrows the gap.

not.bot inverts the problem. You sign your authentic content. Recipients verify the signature. Unsigned content gets appropriate skepticism. Signed content carries proof that a specific verified human reviewed it and approved it.

A not.bot signature carries the signer's identity with it: an alias, a message, credentials (including the not.bot credential proving the signer is human), a timestamp, and cryptographic proof tying it all to the signer's private key. A verifier does not need a pre-existing relationship with the signer. 

Visible signatures (QR and JAB codes, patent pending) survive distribution channels that strip invisible metadata. A screenshot of a signed image still contains the signature. A forwarded photo still contains the signature. Visibility also solves discoverability: the visible code tells the recipient that a signature exists and can be checked.

For the full treatment of content provenance, signature encodings, the relationship to C2PA, and how verification works, see [Content Provenance & Digital Signatures](http://doc_02_content_provenance.md).

## Human verification for websites

Websites face three categories of identity challenge, and not.bot handles all three without collecting personal data.

**Proof of humanity.** A valid not.bot verification requires an enrolled human, on their own device, authenticating with their biometric at the moment of the request. No bot, script, or agent can produce one.

**Sybil resistance.** Site Passes are per-site tokens computed through a three-party multiparty computation among the user's app, the site's Verify server, and Julia Social. If the same human visits the site twice, the same Site Pass appears, regardless of which alias the user chose. The site can detect duplicates. Julia Social cannot learn which sites a user visits.

**Age and attribute verification.** Users can prove they are over 18, over 21, or any age from 13 to 25, prove they are within a five-year or ten-year age range, or meet other criteria, without the site learning their birthdate. The site requests specific claims. The user approves or declines each claim. The site learns only the information the user chooses to share.

For the buyer-side story, the verification flow, and the BYOC deployment model, see [Human Verification & not.bot Verify](http://doc_03_human_verification.md).

## Verifiable agent identity: honest.bot™

AI agents interact with people and systems through natural language, API calls, and realistic audio and video. These interfaces imply identity, but no identity exists. An agent is a process. It has no legal standing and no capacity for accountability.

honest.bot gives agents verifiable, process-bound identity. The core mechanism is multiparty computation: when an honest.bot process starts, it and Julia Social jointly compute a value that neither can derive alone. That value becomes the honest.bot credential. A verifier can confirm the presenting process holds the original credential, without contacting Julia Social. If any other process attempts to present the honest.bot credential, verification fails.

Every honest.bot delegation chain traces back to a single alias of a not.bot-verified human. An agent acts as an extension of the person that deployed it. The delegation chain, included in every presentation, lets any verifier trace the agent's authority back to one specific alias of an accountable human.

The core component of honest.bot is in production. Every not.bot Verify signature server acquires an honest.bot credential at startup. No two signature servers in the world can hold the same credential at the same time. The not.bot app verifies the server's honest.bot credential on every interaction.

For the full honest.bot story, see [honest.bot: Verifiable Agent Identity](http://doc_04_honest_bot.md).

## Privacy by architecture

Companies that collect identity data promise to keep it safe. not.bot makes the promise unnecessary by removing the data from everyone except the user.

Julia Social never sees your identity data. It does not know your name, age, nationality, or any other detail from your identity document. It cannot tell which sites you visit. It does not store which aliases belong to which person. It cannot correlate your activity across sites.

An independent escrow agent ([Praxis Escrow](https://praxisescrow.com/)) stores encrypted identity data but does not hold the decryption key. The identity verification provider ([Signicat](https://www.signicat.com/)) validates your passport during enrollment and deletes the data within minutes. Only the app on your phone holds both the encrypted data and the key to decrypt it.

Sites running not.bot Verify never collect identity data either. A site learns whether the user is human, potentially whether they have visited before (via Site Pass), and the answers to specific credential questions the user approved. Nothing more.

For the full privacy architecture, including what each party can and cannot learn, compromise scenarios, and known privacy weaknesses, see [Privacy Architecture](http://doc_07_privacy_architecture.md).

## Accountability under law

Privacy and accountability are in tension, and not.bot handles both.

U.S. law enforcement can identify the person behind a specific signature by presenting a valid legal demand. The process requires cooperation from both Julia Social and the independent escrow agent (Praxis), takes one to two weeks, has a real financial cost, cannot be expedited, and works on one signature at a time. Bulk surveillance using not.bot is impossible by design: there is no database mapping users to identities, and every identification request requires an independent legal process for each signature.

For the full law enforcement access model, timeline, and architectural constraints that prevent bulk identification, see [Law Enforcement & Accountability](http://doc_09_law_enforcement.md).

## Security model

not.bot's security properties are testable claims. Signatures cannot be forged. Credentials cannot be modified after issuance. Identity survives device loss through a recovery process that requires both the user's passport and their recovery password. Compromise of a user’s signing keys can be detected and remediated without destroying the user’s identity.

For the full security model, known weaknesses, and planned mitigations, see [Security Model & Known Weaknesses](http://doc_08_security_model.md).

## Built on Chia

not.bot identities are decentralized identifiers (DIDs) on the Chia blockchain, using a custom DID method called `did:julia`. Chia provides the properties the system requires: BLS12-381 signatures enabling non-interactive aggregation, a programmable UTXO model (Chialisp) for on-chain identity logic, and a network architecture that makes running your own node practical.

not.bot is not a cryptocurrency product. Users do not buy, hold, or trade tokens. There is no “not.bot token”. The blockchain is infrastructure, like a database, invisible to the user.

For the architectural rationale, see [Why Chia?](http://doc_10_why_chia.md). For the DID method specification, see [did:julia Technical Specification](http://doc_15_did_julia_specification.md).

## Where to go from here

This technology documentation covers the not.bot system in depth. Choose the path that matches your interest:

**If you are evaluating not.bot for your platform or business,** start with [Human Verification & not.bot Verify](http://doc_03_human_verification.md), then read the [Privacy Architecture](http://doc_07_privacy_architecture.md) for the data-handling guarantees your compliance team will want.

**If you are a content creator or public figure concerned about deepfakes,** start with [Content Provenance & Digital Signatures](http://doc_02_content_provenance.md) to understand how signing works and why visible signatures matter, then [Content Signing & not.bot Signer](http://doc_03A_content_signing.md) for the tool that signs at volume.

**If you are evaluating agent identity solutions,** start with [honest.bot: Verifiable Agent Identity](http://doc_04_honest_bot.md) for the product story.

**If you are a privacy advocate or policy analyst,** start with the [Privacy Architecture](http://doc_07_privacy_architecture.md), then read [Law Enforcement & Accountability](http://doc_09_law_enforcement.md) for the identification model.

**If you are a developer integrating not.bot Verify,** the [Architecture & Privacy Guide](http://doc_17B_verify_architecture_privacy.md), [Deployment Checklist](http://doc_17D_verify_deployment.md), and [Operations & Reference Guide](http://doc_17E_verify_operations.md) are delivered with your Verify subscription. The [not.bot Verify: Julia Web SDK Reference](http://doc_18_verify_web_sdk.md) covers the integration API.

**If you want to understand the cryptographic foundations,** start with [Identity Architecture: DIDs, Aliases, and Ownership](http://doc_06A_identity_architecture.md), then move to [Cryptographic Foundations](http://doc_12_cryptographic_foundations.md) and the [did:julia Technical Specification](http://doc_15_did_julia_specification.md).