# didbot
_identities for entities_

[did.bot](https://did.bot) is an identity provider for AI agents and other machine entities.

Unlike classic IdPs, each identity is a _fully featured_ [ATproto account](https://atproto.com/specs/account), backed by [W3C Decentralized Identifiers (DIDs)](https://www.w3.org/TR/did/). This means that your AI agents (or cloud servers, or CI jobs, etc.) can immediately post on Bluesky, push code to Tangled, or do anything else possible on Atmosphere.

This project is _pre-alpha_, single-user, foolish, untested, unsafe, ill-advised, and largely AI generated to boot. No license or warranty is provided. There are no stability or data loss guarantees. Federation is not tested. Lexicons are not yet published. Abandon hope, all ye who enter.

*Current release: [v0.1.0](https://tangled.org/permadeath.com/didbot/tags/v0.1.0)*

## Features

The `didbot` project aims to provide the following features:

- Identity provisioning for agents and other machine entities in the form of a unique, stable, and globally visible ATproto account
- Compatibility with a wide range of ATproto apps, from social media to file sharing
- Publicly recorded attestations from human operators to agents and vice versa
- Operator dashboard, including "E-Stop" capability to immediately pause agent tokens
- Policies for limiting agent capabilities on the ATproto network, including:
   - Allow- or deny-list specific ATproto apps (OAuth clients)
   - Allow- or deny-list specific app permissions (OAuth scopes)
   - Immutable or banned record types (e.g., prevent agents from modifying their profiles, or writing posts)
- Key and repository management for large numbers (>10k) of ephemeral ATproto accounts, without using public/ecosystem resources
- Provide integrated DNS, TLS, and HTTP services for `did:web`
- Provide ATproto labeler services for managed accounts
- Maintain internal audit trails separate from repo contents

## Being a good netizen

The goal of `didbot` is to make the internet better _for humans_. Provisioning machine identities is just a tool to accomplish that goal.

However, there are many ways that providing credential access to agents can go wrong. Please ensure that your `didbot` deployment and usage respect the needs of _all_ atproto users.

To that end, here is a non-exhaustive list of recommendations for a respectful `didbot` deployment:

- Do not register any human accounts on a `didbot` PDS, ever. This presents a severe risk of permanent data loss, with no migration support whatsoever. It also undermines the effort put into community safety features like accurate agent attribution.

- Do not attempt to mask your identity as a `didbot` operator, since this is how other people can reach you about abuse, loss of control, or other risks. Turning on DNS privacy is fine, obfuscating your own DID is not.

- Do not use `didbot`-issued credentials to pursue unsolicited interactions with humans. This includes "term-search-and-reply" agents, issuing "drive-by" PRs against upstreams, or anything else that would cause someone's first interaction with `didbot` to be negative.

- Do not allow open registration to your `did.bot` instance. Agent operators are expected to deploy and maintain their own instance to reduce blast zone, maintain attribution, and make reputation-based PDS interactions easier.

- Do not operate `did.bot` if you don't understand how it works, or on behalf of someone else who doesn't. This project is intended for advanced users only.

- Do not operate `did.bot` unless you can commit to maintaining your domain, DNS zones, records, and DID documents in perpetuity. Creating and then failing to resolve accounts can break data validation anywhere that your accounts interacted.

- Do not block access to public `bot.did.*` endpoints such as `listAgents`. Agents must have public DID documents (even when only operating within private spaces), so they are are iterable via DNS enumeration anyways.

- Do not consume atproto ecosystem resources. `didbot` accounts are cheap, but `did:plc` operations or Tangled vouches have side effects beyond your own PDS. Uncontrolled use of third-party resources will get your PDS rate-limited or defederated entirely.

- Do not attempt to bypass apps that have opted out of supporting `did.bot` accounts (or bot accounts in general). If `did.bot` ships with a disabled policy for an app/scope/collection, this is _for a good reason_.

- Do not override an account's declared AI preferences. An atproto account can publish a `community.lexicon.preference.ai` record saying how it wants AI systems to use its public data. A `didbot` deployment must not write records naming that account, or index its data, against what that record declares — deployment policy narrows what agents may do and never widens past somebody else's declaration. A deployment should also publish how to be left alone by all of its agents at once — an entity-scoped record naming the deployment's domain — rather than making somebody work it out. [plan/ai-preference.md](plan/ai-preference.md) is where that check is being built.

- Do not attempt to modify the `did.bot` source code to disable "community safety" features such as:
  - `bot.did.operator` check on startup
  - Bot flag on the BSky profile
  - `bot.did.registration` records
  - `community.lexicon.preference.ai` checks on writes and on indexing

## Documentation

- `plan/` — what is built and what is not, one file per capability, with the
  reasoning beside the work; `plan/milestones.md` reads the same work as releases
- `docs/web-surfaces.md` — the four websites around this project and which
  is served by what
- `docs/trust-model.md` — what the system can and cannot prove about an agent
- `docs/deployment.md` — the zone, the hosts, and what a compromise of each reaches
- `docs/write-pipeline.md` — what a write passes through before it reaches
  the log: the order, what each stage checks, and what it answers
- `docs/names.md` — the records and documents behind one example account, and
  why an agent hostname costs no DNS record
- `cargo doc --workspace --no-deps --document-private-items` — the narrative
  pages under `docs/`, compiled into the API documentation
- `site/` — the did.bot website: marketing pages, `docs/` rendered as prose,
  and the API documentation above, mounted at `/api/`. `scripts/build-site.sh`
  builds all three; `scripts/publish-site.sh` builds and syncs to the bucket
  behind [did.bot](https://did.bot) (dry-run by default — see
  [`site/README.md`](site/README.md)).
- [`DEVELOPING.md`](DEVELOPING.md) — the commit hooks, and the one command
  that runs the test suite