# **Roadmap**

This document describes where Julia Social is taking not.bot™ and honest.bot™: the products, capabilities, and infrastructure planned beyond what ships today. The items differ in maturity. Some are scheduled releases with target dates. Others are designed and waiting on engineering. A few are capabilities the protocol already supports that need application code to reach users. The list runs from nearer-term work toward later items, not in strict release order. Each entry states what the item is, what it makes possible, and how far along it stands. Target dates describe intent, not promises.

## **not.bot Signer**

not.bot Signer is a web tool for signing content at volume, targeted for release at the end of June 2026. The not.bot app signs one piece of content at a time from a phone. That fits a person sharing photos. It does not fit a newsroom, a brand, or a public figure publishing dozens of items a day across formats. Signer is built for that scale: videos, images, PDFs, links, and posts, signed from a browser. Signing still requires the not.bot app on the signer's phone to create the signatures, so the property that gives a signature its meaning, a verified human authorizing it, stays intact at any volume.

Signer also hosts an encrypted known-good copy of each signed item. The decryption key is embedded in the signature and Signer does not have it. A verifier who encounters the content in the wild can compare what they see against what was signed, which turns a signature from a claim of authorship into a check against the original.

Public figures and brands are the first people deepfakes impersonate. Signer gives them a practical way to sign their output as a matter of routine, so their audiences learn that authentic content from them carries a signature. Signer is also the first product to use Alias Vault Keys, described below, keeping each signer's account data encrypted on the server between sessions. [Content Signing & not.bot Signer](http://doc_03A_content_signing.md) describes the product in full.

## **Alias Vault Keys**

An Alias Vault Key (AVK) is a symmetric encryption key the not.bot app holds, one per alias, returned to a host application during a not.bot Verify signature exchange and discarded when the user logs out. A server built this way keeps each user's data encrypted at rest under a key it does not hold between sessions, so a breach exposes only the data of users with a live session at that moment, and an abandoned account stays a locked box instead of a standing exposure. The key lives in the user's Recovery Data Bundle, so it survives the loss of every device without the recovery agent or Escrow Server being able to read it. The capability ships with not.bot Signer at the end of June 2026, the first product to use it. [Recovery](http://doc_06D_recovery.md) describes the bundle.

## **Privacy-preserving push notifications**

Julia Social plans push notifications from not.bot Verify to users' devices, delivered without Julia Social learning which not.bot Verify instance sent the notification, nor which DID received it. Users must opt-in to notifications from each Verify instance, and can block notifications from a specific instance at any time. The mechanism is documented in full and ready for development. 

## **In-person enrollment**

Enterprises ask a question not.bot has no good answer for today: can I enroll my employees, or my customers, in person, so I can recognize them online afterward? Enrollment today is notbot0, an NFC passport scan performed at home, with no in-person path. Two higher verification levels are planned, along with broader passport coverage, and in-person enrollment is the next major capability after not.bot Signer.

**notbot1: partner enrollment.** Banks, hospitals, and similar institutions verify identity in person for their own purposes. Under notbot1, a partner institution enrolls the person into not.bot during that same visit, under contract to follow NIST SP 800-63A IAL2 identity proofing procedures. Each partner becomes an enrollment channel, and in-person proofing at IAL2 opens use cases a home passport scan cannot serve.

**notbot2: first-party facilities.** Enrollment facilities under direct contract with Julia Social, providing the highest assurance tier in the scale.

**Additional passport countries.** The app is only available in US app stores today. The NFC-enabled passport holders in each added country represent a new population that can enroll, and a stronger guarantee for verifiers that a not.bot credential means the same thing across borders.

## **honest.bot**

honest.bot gives verifiable, process-bound identity to AI agents. Each honest.bot identity traces through a delegation chain to a not.bot-verified human, so an agent acting on someone's behalf is accountable to a named person rather than to a key file. The underlying MPC protocol runs in production today inside not.bot Verify, where each signature server acquires an honest.bot credential at startup. The honest.bot product, the pieces that let third parties deploy credentialed agents of their own, is targeted for Q4 2026. honest.bot Verifiable Agent Identity covers the product in depth; the work in flight consists of four pieces.

**The adversarial appliance.** A containment architecture for running agents in environments their operator does not control, or agents the operator does not trust without limits. The appliance holds the agent's identity and enforces its bounds from outside the agent's own process, so a misbehaving agent cannot exceed what was delegated to it.

**The SDK for third-party agent deployments.** The SDK turns honest.bot from Julia Social's internal infrastructure into a product. An organization uses it to give its agents identities, delegate authority to them within set bounds, and revoke that authority when circumstances change.

**Technology stack credential schemas.** Credentials that describe the software an agent runs on. A verifier deciding whether to transact with an agent can require proof of its stack and set policy against it, the same way a security team sets policy against software versions today.

**OIDC and enterprise authentication integration.** Enterprises run identity infrastructure already. Clean OIDC integration lets honest.bot credentials flow through existing authentication systems rather than beside them, which is the difference between an adoption path and a rip-and-replace.

## **Signatures in more places**

The signature system today is visual and app-centered: QR and JAB codes, created and scanned with the not.bot app. Four planned capabilities widen where signatures can live and how they get checked, and a fifth sits further out.

**Virtual-camera signature insertion.** A virtual camera that inserts the user's visible signature into a live video feed, so a video call itself carries proof that a verified human is on camera. The signature survives the call platform's compression and re-encoding (patent pending). Live impersonation on video calls, the staged-executive fraud that has already moved real money, is the sharpest form of the deepfake problem, and this answers it in real time rather than after the fact.

**Browser-extension verification.** Checking a signature today requires the not.bot app or a not.bot Verify deployment. A browser extension will let a person verify a signature without leaving the page the content appears on. Verification friction drops to nearly nothing at the place content is consumed, which is where the question "is this real?" gets asked.

**Video-stream signature detection and verification.** Detection and verification of signatures inside playing video, as the stream runs. Today, checking a signature in a video means pausing, capturing a frame, and scanning it. Stream-level detection makes the signature work at watching scale: a viewer or a platform sees the verification happen, with no frame-grab workflow.

**Offline signing and verification.** The protocol supports creating and verifying signatures with no network connection; the app code for it does not exist yet. The payoff is in-person verification where connectivity fails or never reached: a license check in the backcountry, a credential presented in a building with no signal.

**Audio encoding.** QR and JAB codes serve channels you can see. An audio encoding would extend signatures to audio-only channels: calls, radio, podcasts, voice interfaces. Voice cloning is the most common provenance problem after fake video, and no visual code can answer it.

## **Received-signature verification in not.bot Verify**

not.bot Verify currently requests a signature and checks the response inside an interactive session. A separate capability would let it validate a signature provided by the host app, for example one uploaded by a user. 

## **Recovery beyond Julia Social**

Julia Social operates the only Recovery Server and is the only recovery agent today. Recovery describes the destination in detail; the roadmap items form one arc, ending that single-operator state.

**Open-source Recovery Server.** Julia Social plans to release the Recovery Server as open source, with its two roles split: holding the user's encrypted recovery bundle, and authorizing recoveries. A user can run their own server and keep their bundle under their own control.

**Third-party recovery agents.** Commercial recovery services, friends and family, or a self-hosted agent, chosen by the owner. With more than one agent available, the multi-agent configurations the protocol supports become usable: quorums such as 2-of-3 across agents in different jurisdictions, where no single compromised or compelled agent can recover an identity or block its rightful recovery.

**Watchtower services.** Third-party services that watch the blockchain for a pending recovery against a subscriber's identity and alert the owner inside the cancellation window. Julia Social cannot run a watchtower, because alerting a user requires holding contact information and contact information identifies the user. The service has to come from parties willing to hold it.

**App-exposed pre-rotated keys.** The protocol supports committing a replacement key in advance, an instant recovery path with no delay and no agents. A future version of the app will let a user arm it and keep the pre-rotated key in storage of their own choosing, written down offline or in a hardware signer.

**Linking changed identity documents.** A renewed passport with a changed legal name, nationality, or gender fails duplicate detection today and produces a new identity; aliases, credentials, and history do not transfer. Planned linking lets a person carry their identity through a name change or naturalization instead of starting over. Marriage and citizenship are routine events, and an identity system should survive them.

## **The credentials platform**

**Third-party credentials.** Julia Social issues every credential today: personal information, age, the not.bot credential, Verified Signer. The architecture already supports any organization issuing credentials to users through a Business DID. Planned app support for receiving, storing, and presenting third-party credentials opens the catalog: diplomas, professional licenses, certifications, employer attestations, all presented with the same selective disclosure and the same no-phone-home property as Julia Social's own credentials. The credential catalog stops being one company's list.

**Broader Business DID availability.** Business DIDs exist today for not.bot Verify customers, with the Domain Name credential. Broader availability gives any organization an on-chain identity with multi-class multi-sig governance and delegation. Business DIDs enable the issuer side of the third-party credential ecosystem. The two items pair: Business DIDs create the issuers, app support creates the holders.

**Self-attested credentials.** Some facts about a person have no institutional issuer: an avatar, a preferred name, a gender identity. The architecture lets a user issue these credentials to themselves, and planned app support will let users create and present them like any other credential. The signature makes the provenance plain: a verifier sees a claim signed by its own subject and weighs it as the person's own word, the right authority for what a person calls themselves. The payoff is a portable profile, set once and presented to any site that asks, owned by the user instead of scattered across platform databases.

## **Website-requested transaction signing**

A website builds a blockchain transaction and the rich interface for defining it, then asks the user's app for a signature with the user's DID. The app shows the user a plain summary of what they are approving, the user signs, and the website submits the result. The division of labor is deliberate. Websites become front-ends for on-chain operations without holding keys, and users act on chain without running a wallet. The app does not build these transactions and will not; the two capabilities below reach users through a website's request.

**On-chain credential presentation.** A credential presentation today happens off-chain: the holder presents to a website or a person, and the verifier checks the result against the blockchain. A website-built transaction can place the presentation inside the transaction itself, where the chain enforces it. A coin or smart contract can require a valid credential presentation as a condition of spending, and that changes what on-chain assets can do.

**Julia DIDs as digital asset wallets.** The protocol lets a DID own digital assets on the Chia blockchain. The not.bot app will not manage those assets; a website builds the transfer, and the app's role stays what it is everywhere else, showing the user what they are signing. Combined with on-chain credential presentation, a single website-built transaction can carry both proof of identity and a movement of value, the foundation for person-to-person commerce between verified counterparties.

## **Julia Vanity Names**

Reserved Names ship today as a preview of the Julia Vanity Name system. A reserved name is a chosen username, displayed with the .nb suffix (sarah.nb), that a user carries across every site where they choose to be recognized. Reserved names never expire and never need renewal, and the matching rules treat lookalike characters as the same name, so no one can impersonate sarah.nb by registering the same name with a capital i in place of the l. Julia Social mediates the reservations: Pro subscribers hold one name, Verified Signer subscribers five.

The Julia Vanity Name system replaces that mediation with a self-governing registry on the Chia blockchain. The Chialisp code exists; deployment remains. Registration will take a deposit rather than a fee, returned in full when the name is released. Names will transfer and sell like the property they are. The registry will run without maintenance from Julia Social, and a person will be able to register as many names as they want. Every reserved name will be pre-registered in the new system at launch, so a name claimed today is a claim on the permanent registry.

A username on a platform is an entry in that platform's database, kept on that platform's terms. A Julia Vanity Name belongs to the user outright, on a registry no company can edit, attached to an identity no company can seize. It completes the recognizability half of the alias model: aliases keep a user's contexts separate by default, and a vanity name is the deliberate exception, one name, recognizable wherever its owner chooses to use it.

## **Security and privacy hardening**

**Independent privacy audit.** An independent audit by Least Authority is planned for the MPC protocols and other privacy-critical code. The audit converts "review our design" into third-party assurance that an enterprise security team or a regulator can cite.

## **Standards interoperation**

**DIDComm messaging.** DIDComm is an open standard for end-to-end encrypted communication between DID holders. The encryption keys come from the DID documents themselves: a sender resolves the recipient's DID, encrypts to the key published there, and sends. No account is created, no certificate authority vouches for the parties, and no platform sits in the middle. The encryption lives at the message level rather than the transport, so the same message stays protected over any channel that can carry it.

Julia Social plans to integrate DIDComm into the not.bot app. The integration gives users private communication where the only thing either side shares is an alias DID. Messaging today runs on identifiers that name the person, a phone number or an account with a platform. A DIDComm conversation between not.bot users runs on aliases: each side knows the other's alias DID and whatever the other chooses to disclose, nothing more. The same channel connects not.bot users to the broader ecosystem of DIDComm-capable systems and gives third-party credential issuers an out-of-band way to deliver credentials. Delivery to an offline recipient runs through mediators, and the standard already covers them: each routing hop gets its own layer of encryption, so a mediator learns only the next hop, not the message contents, the sender, or the final destination. A relay can carry not.bot users' messages without learning who is talking to whom, the property Julia Social's architecture demands of any party it adds.

## **Related documents**

- **[Content Provenance and Digital Signatures](http://doc_02_content_provenance.md):** the signature system as it exists today.
- **[Content Signing and not.bot Signer](http://doc_03A_content_signing.md):** the Signer product, targeted for the end of June 2026.
- **[Identity Architecture](http://doc_06A_identity_architecture.md):** aliases and the naming surface that vanity names complete.
- **[honest.bot Verifiable Agent Identity](http://doc_04_honest_bot.md):** the honest.bot product narrative.
- **[The not.bot App](http://doc_05_notbot_app.md):** the app the roadmap extends.
- **[Credentials, Presentations, and Selective Disclosure](http://doc_06B_credentials.md):** the credential model behind the platform items.
- **[Recovery](http://doc_06D_recovery.md):** the recovery model the decentralization arc completes.
- **[Why Chia?](http://doc_10_why_chia.md):** the blockchain the on-chain items build on.