Identity Architecture: DIDs, Aliases, and Ownership
A not.bot™ identity is a Julia Social decentralized identity, an instance of the did:julia method. did:julia is one of more than 200 decentralized identifier methods registered with the W3C and the Decentralized Identity Foundation. It was designed to deliver what the field has been working toward since 2016: an identity the user controls, verifiable without contacting a central server, that serves humans, organizations, software agents, and non-human objects through a single coherent model.
Decentralized identifiers
A decentralized identifier (DID) is a globally unique identifier that follows the W3C URI convention: did:<method>:<identifier>. A DID is not an identity. It is a string that identifies some unique thing. The thing can be a person, a company, a software agent, a physical object, or anything else that has a stable existence.
A DID method is the protocol that defines how a DID of a given form is created, resolved and updated. Methods vary widely: some are blockchain-rooted, some use witness logs, some are derived from cryptographic key material, some require contacting a central registry on every resolution.
A DID document is a JSON-LD document that describes the entity the DID identifies. The W3C specification requires only that the document contain the DID itself. Most methods include additional information: public keys, service endpoints, key rotation history.
Decentralized identity
Decentralized identity, sometimes called self-sovereign identity or self-managed identity, refers to the principle that the entity an identity describes should have control over that identity. The field was launched in 2016 by Christopher Allen's Principles of Self-Sovereign Identity, refined and expanded later that year by Joe Andrieu's Technology-Free Definition of Self-Sovereign Identity.
The principles have remained consistent for nearly a decade. Achieving them in practice has proven harder. DID methods built since 2016 have compromised in one or more dimensions: in decentralization (centralized registries), in functionality (limited operations), in privacy (correlation data leaking across uses), or in security (recovery options that depend on the issuer).
did:julia
did:julia was designed from first principles to close every one of the gaps that prior methods left open. The user controls the identity through cryptographic keys they hold. Anyone with access to the Chia blockchain can verify the current state of any did:julia identity. No central server participates in normal use. The same identity model serves humans, organizations, software agents, and non-human objects.
Several architectural properties shape the design.
Cryptographic commitment
A did:julia identifier is the launcher coin ID of a Chia singleton, a hash commitment derived from the coin's launch parameters. The DID itself contains the cryptographic anchor that ties it to its on-chain state. The DID and the on-chain state form a single cryptographic structure that requires no name registration or database lookup.
Blockchain verification
The current state of every did:julia identity sits on the Chia blockchain in the form of a singleton coin. Authentication keys, recovery configuration, custodian list, and DID document pointer all live inside that coin. To check which keys can sign for an identity, you read the on-chain state of its current singleton. To check whether a credential the identity holds has been revoked, you read the issuer key singleton's revocation bitfield.
The Chia blockchain is the source of truth for did:julia identity state. Tens of thousands of Chia nodes worldwide can answer questions about identity state. No identity provider, Julia Social included, sits in the verification path. Anyone with access to a single Chia node can verify any did:julia identity.
Signature-carries-identity
A did:julia signature carries the signer's identity with it. The signature contains the signer's alias DID, the credentials the signer chose to include, a message the signer composed, a timestamp, and an anti-replay nonce. A verifier who encounters the signature has everything needed to look up the signer's current state on the blockchain, validate the cryptographic signature against the signer's current key, and inspect the credentials.
A signature stays verifiable after the signer rotates keys. The verifier resolves the signer's lineage from the launcher commitment, the permanent anchor of the DID, rather than from whatever key is current, so an old signature still resolves to the same identity even after the keys that produced it have been replaced. Key rotation does not break past signatures.
This property closes the gap between "someone signed this" and "a specific identified person signed this." A traditional digital signature (PGP, S/MIME, X.509) binds content to a key. Resolving that key to an identity requires a separate channel: a key directory, a certificate authority, a web of trust. A did:julia signature carries the resolution step inside the signature itself.
The identity structure
A not.bot identity consists of one root DID and any number of alias DIDs. Each is a separate did:julia coin on the Chia blockchain. Both the root and every alias have the same coin structure.
The root DID is the recovery anchor of the identity. If you lose your keys, recovery operates on the root DID first. The root never signs content or presents credentials.
Alias DIDs are the identifiers a user interacts with the world through. Each alias has its own keys, its own credentials, and its own signature history. A user creates as many aliases as they need: per-site aliases for privacy, named aliases for public personas, scratch aliases for one-off contexts, hidden aliases for sensitive use.
The not.bot app holds one BLS12-381 secret key on the user's device. Every DID in the user's identity (the root and every alias) is identified by a separate public key derived from that secret. The derivations are independent: given two of the user's alias public keys, no observer (Julia Social included) can determine they share a parent. Unlinkability across aliases follows from the derivation structure.
The same property applies to credentials. The same credential value (a first name, for example) issued to two aliases produces two cryptographically distinct credentials that cannot be correlated to a common subject. A user with a public-facing journalist alias and a private personal alias, each holding their first name as a credential, can present that first name to two verifiers without giving either verifier the ability to recognize the same human across both presentations.
Ownership
The owner of a not.bot identity is the holder of the keys that can sign for the identity. The default ownership model for personal not.bot identities is single-sig: one BLS12-381 key, secured by the secure element of the user's device, authenticates every operation on every DID in the identity.
did:julia supports two additional ownership models for organizational and high-value identities: multi-sig (M-of-N keys required to authenticate) and multi-class multi-sig (M-of-N classes of keys, each class with its own quorum). It also supports a custodian capability in which a separate DID can operate the identity on behalf of the owner. These models, and the Business DIDs that use them, are the subject of Delegation and Organizational Identity (6C).
Asset ownership
A did:julia identity can own assets on the Chia blockchain: XCH, CATs (Chia Asset Tokens), NFTs, and DataLayer singletons. An asset coin owned by a DID spends only on command from that DID. The pattern is called pay-to-JDID, and it is part of the shipped protocol; the did:julia Technical Specification (Doc #15) describes the mechanism.
A did:julia identity is not itself one of these assets. The identity is an active vault: it holds credentials, signs messages, and owns the assets listed above. An NFT or a CAT is a static token that a DID owns. The identity is the thing that does the owning. Selling or transferring an identity is not a supported operation. The owner is the holder of the keys that can sign for the identity, and control of an identity moves through the ownership and recovery models, key rotation and recovery agents, not by handing a token to someone else. A user who wants a fresh, unlinkable context creates a new alias rather than acquiring an existing one.
Two properties separate DID-owned assets from key-based wallets.
Assets follow identity. The asset coin is bound to the DID's permanent launcher ID, not to a key. When the owner rotates keys, control of every owned asset moves with the identity. When the owner recovers a lost identity, the recovery restores control of every owned asset. There is no seed phrase whose loss strands the assets.
One ownership model over identity and assets. The same ownership model that authorizes identity operations, single-sig, multi-sig, or multi-class multi-sig, also governs every asset the identity owns. A business identity under multi-class multi-sig controls its treasury under the same key classes that control its DID operations, so a treasury spend clears the same quorum that a key-rotation or delegation operation clears. A custodian operating an identity operates its assets under the same restrictions and the same attributable record. No separate wallet policy layer exists, because there is no separate wallet.
The not.bot app is not a wallet. The app holds the signing key and the consent step, nothing more. It does not index the blockchain, does not track balances, and does not contain asset-handling logic. It is not going to become a wallet; that boundary is a design commitment.
Websites as asset front-ends. The flow that brings these pieces together is on the roadmap. A website reads the blockchain to find the assets a DID owns, presents them in its own interface, and constructs the spend the user wants to make. The website hands the transaction to the not.bot app. The app shows the user a plain statement of what the transaction does and signs on the user's consent. The website never holds keys, and the app never builds asset UX. The smallest version of this flow is a web-based wallet. The same flow serves anything a Chia spend can express, and a single spend can present credentials and transfer assets together, proving who is paying and moving the funds in one atomic transaction.
A related pattern puts a coin under the control of a credential rather than a DID, so that holding a valid credential is what confers the right to spend. Credentials, Presentations, and Selective Disclosure (6B) covers that pattern, pay-to-credential, in its own section.
Display and identification
Every alias has a deterministic visual identity computed from its DID. Two devices that hold the same alias compute the same visual identity. No display data needs to sync.
Petnames are three-word phrases (a typical example: "endlessly-altruistic-whale") derived from the alias's DID bytes. The not.bot app computes a petname for every alias. The petname is the default user-visible name for an alias.
LifeHash is a colored visual fingerprint, also derived from the alias DID. Two aliases have visually different LifeHashes. A user can tell their aliases apart at a glance.
Reserved names are .nb-suffixed names a Pro or Verified Signer subscriber can request: alice-smith.nb, notbot_official.nb. Reserved names are a Julia Social-mediated registry today. The roadmap replaces this registry with on-chain "Julia Vanity Names" that operate autonomously without Julia Social's involvement. When the on-chain mechanism deploys, existing reserved names convert to Julia Vanity Names.
Verified Signer badges link a specific alias to a specific online or social media account. The badge is a credential issued by Julia Social after verification of an online proof, and held by the alias. When the badged alias signs content and presents the Verified Signer credential, the badge appears alongside the petname or reserved name.
Nicknames are user-edited private labels for an alias. A nickname is for the user's own use, and it is never disclosed to verifiers. Nicknames sync across the user's devices through an end-to-end encrypted blob on the Recovery Server. The Recovery Server cannot read the nicknames.
Hidden aliases are aliases the user has marked as not visible in the app's regular alias list. Reaching a hidden alias requires an additional unlock step gated by on-device biometric or passcode authentication. The concept is similar to a browser's incognito mode: a separated context a user reaches only when they intend to use it. Hidden aliases let a user maintain identities for sensitive contexts on a device that other people sometimes see.
Recovery
Recovery operates on the root DID. Once the root DID has recovered, the user's alias DIDs follow. The full recovery model, including pre-rotated keys for instant recovery, time-locked assisted recovery through recovery agents, and the malicious-recovery scenario and countermeasures, is covered in Recovery (6D).
What lives where
The other documents in the identity series carry the rest of the model.
Credentials, Presentations, and Selective Disclosure (6B) covers the credential architecture: single-claim credentials, the catalog of credentials Julia Social issues, presentations and the three modes (on-chain, online off-chain, fully offline), the "no phone home" property, antecedents and cascade revocation, and holder presentation.
Delegation and Organizational Identity (6C) covers issuer delegation and credential delegation, revocation, multi-sig and multi-class multi-sig ownership, Business DIDs, the custodian capability and its application to personal and non-human identities, and the chain of human accountability that terminates every delegation.
Recovery (6D) covers the recovery model in detail.
The did:julia Technical Specification (Doc #15) is the implementer-facing reference for the on-chain protocol, complementary to the conceptual treatment here.