From dfc662d4fe41acee0eddae3068088a606b75d9c6 Mon Sep 17 00:00:00 2001 From: Trezy Date: Sun, 19 Apr 2026 23:50:09 -0500 Subject: [PATCH] docs: refer to `atproto` --- packages/docs/docs/README.md | 6 +- .../docs/getting-started/authentication.md | 8 +- .../docs/docs/getting-started/dashboard.md | 10 +- .../docs/docs/getting-started/quickstart.md | 4 +- packages/docs/docs/guides/backfill.md | 2 +- packages/docs/docs/guides/labelers.md | 2 +- packages/docs/docs/guides/lexicons.md | 4 +- packages/docs/docs/guides/plugins.md | 2 +- packages/docs/docs/guides/scripting.md | 10 +- .../guides/sqlite-to-postgres-migration.md | 2 +- packages/docs/docs/reference/admin-api.md | 2 +- packages/docs/docs/reference/admin/domains.md | 2 +- .../docs/docs/reference/admin/labelers.md | 2 +- .../docs/docs/reference/admin/lexicons.md | 2 +- packages/docs/docs/reference/admin/users.md | 2 +- packages/docs/docs/reference/architecture.md | 4 +- packages/docs/docs/reference/glossary.md | 18 +- .../docs/docs/reference/lua/atproto-api.md | 6 +- .../docs/docs/reference/lua/record-api.md | 2 +- .../reference/scripts/cascading-delete.md | 2 +- .../docs/reference/scripts/sidecar-records.md | 2 +- .../docs/docs/reference/troubleshooting.md | 2 +- packages/docs/docs/reference/xrpc-api.md | 2 +- packages/docs/docs/sdk/lex-agent.md | 2 +- .../docs/docs/sdk/oauth-client-browser.md | 2 +- packages/docs/docs/sdk/oauth-client.md | 2 +- packages/docs/docs/sdk/overview.md | 6 +- packages/docs/docs/tutorials/statusphere.md | 190 +++++------------- packages/docs/sidebars.ts | 2 +- 29 files changed, 108 insertions(+), 194 deletions(-) diff --git a/packages/docs/docs/README.md b/packages/docs/docs/README.md index 736e679..c6cc4a1 100644 --- a/packages/docs/docs/README.md +++ b/packages/docs/docs/README.md @@ -1,6 +1,6 @@ # HappyView -HappyView is the best way to build an [AppView](https://atproto.com/guides/glossary#app-view) for the [AT Protocol](https://atproto.com). Upload your [lexicon](reference/glossary.md#at-protocol-terms) schemas and get a fully functional AppView, complete with [XRPC](reference/glossary.md#at-protocol-terms) endpoints, OAuth, real-time network sync, and historical [backfill](guides/backfill.md), without writing a single line of server code. +HappyView is the best way to build an [AppView](https://atproto.com/guides/glossary#app-view) for the [AT Protocol](https://atproto.com). Upload your [lexicon](reference/glossary.md#atproto-terms) schemas and get a fully functional AppView, complete with [XRPC](reference/glossary.md#atproto-terms) endpoints, OAuth, real-time network sync, and historical [backfill](guides/backfill.md), without writing a single line of server code. Building an AppView from scratch means wiring up real-time event streams, record storage, XRPC routing, OAuth flows, and PDS write proxying before you can even think about your application. HappyView handles all of that. Define your data model with lexicons, add custom logic with Lua scripts when you need it, and ship your app. @@ -8,7 +8,7 @@ Building an AppView from scratch means wiring up real-time event streams, record - **Schema-driven endpoints:** Upload a [lexicon](guides/lexicons.md) and HappyView generates XRPC query and procedure routes, storage, and indexing from it — updatable at runtime with no restart. -- **Network sync built in:** Real-time record streaming via [Jetstream](https://github.com/bluesky-social/jetstream), historical [backfill](guides/backfill.md) from each user's PDS, and AT Protocol OAuth with DPoP-bound proxy writes back to the PDS. +- **Network sync built in:** Real-time record streaming via [Jetstream](https://github.com/bluesky-social/jetstream), historical [backfill](guides/backfill.md) from each user's PDS, and atproto OAuth with DPoP-bound proxy writes back to the PDS. - **Customize with Lua, hooks, and plugins:** [Lua scripts](guides/scripting.md) for query and procedure logic, [index hooks](guides/index-hooks.md) that fire on every record change, WASM [plugins](guides/plugins.md) for external platform integration, and [labeler](guides/labelers.md) subscriptions for content moderation. @@ -24,7 +24,7 @@ Building an AppView from scratch means wiring up real-time event streams, record - **Runtime-configurable**: Lexicons can be added, updated, and removed without restarting the server. New endpoints and sync rules take effect immediately, so you can iterate on your data model in real time. -- **Protocol-native**: HappyView works with _any_ PDS, resolves DIDs through the directory, and follows AT Protocol conventions. It's a first-class citizen of the network, not a wrapper around it. +- **Protocol-native**: HappyView works with _any_ PDS, resolves DIDs through the directory, and follows atproto conventions. It's a first-class citizen of the network, not a wrapper around it. ## Next Steps diff --git a/packages/docs/docs/getting-started/authentication.md b/packages/docs/docs/getting-started/authentication.md index 7a66307..00d694e 100644 --- a/packages/docs/docs/getting-started/authentication.md +++ b/packages/docs/docs/getting-started/authentication.md @@ -2,7 +2,7 @@ HappyView has two distinct authentication surfaces: -- **XRPC** (`/xrpc/*`) — client-level identification via an **API client key** on every request, plus optional user-level AT Protocol OAuth for endpoints that need a specific user's identity (e.g. procedures that write to a PDS). +- **XRPC** (`/xrpc/*`) — client-level identification via an **API client key** on every request, plus optional user-level atproto OAuth for endpoints that need a specific user's identity (e.g. procedures that write to a PDS). - **Admin API** (`/admin/*`) — user-level authentication via admin API keys or service auth JWTs, gated by [permissions](../guides/permissions.md). ## Which endpoints require what? @@ -49,7 +49,7 @@ curl 'https://happyview.example.com/xrpc/com.example.feed.getHot' \ ### Authenticating users for procedures -Queries that don't care who is calling need nothing more than the client key. Procedures — and queries whose Lua scripts read the caller's DID — need a real AT Protocol OAuth session. +Queries that don't care who is calling need nothing more than the client key. Procedures — and queries whose Lua scripts read the caller's DID — need a real atproto OAuth session. XRPC routes only accept **DPoP auth** (`Authorization: DPoP ` + `DPoP` proof header + `X-Client-Key`). Bearer tokens and service auth JWTs are not accepted on XRPC endpoints. @@ -103,7 +103,7 @@ A key only carries the permissions selected at creation time and can never excee ### Service auth JWT -HappyView also accepts standard AT Protocol inter-service auth JWTs in the `Authorization` header. Another AppView, relay, or PDS can sign a short-lived ES256 or ES256K JWT with its DID's signing key; HappyView resolves the issuer's DID document, verifies the signature against the `#atproto` verification method, and treats the issuer DID as the caller identity. +HappyView also accepts standard atproto inter-service auth JWTs in the `Authorization` header. Another AppView, relay, or PDS can sign a short-lived ES256 or ES256K JWT with its DID's signing key; HappyView resolves the issuer's DID document, verifies the signature against the `#atproto` verification method, and treats the issuer DID as the caller identity. For a service auth JWT to validate: @@ -186,7 +186,7 @@ The `dpop_key` is the private JWK. Use it to generate DPoP proofs during your OA #### 2. Run OAuth with the user's PDS -Use the provisioned DPoP key as your DPoP keypair in a standard AT Protocol OAuth flow with the user's PDS. HappyView is not involved in this step — the app talks directly to the PDS authorization server. +Use the provisioned DPoP key as your DPoP keypair in a standard atproto OAuth flow with the user's PDS. HappyView is not involved in this step — the app talks directly to the PDS authorization server. #### 3. Register the session diff --git a/packages/docs/docs/getting-started/dashboard.md b/packages/docs/docs/getting-started/dashboard.md index a46f7ad..59b599f 100644 --- a/packages/docs/docs/getting-started/dashboard.md +++ b/packages/docs/docs/getting-started/dashboard.md @@ -1,6 +1,6 @@ # Dashboard -HappyView ships with a web dashboard that provides a visual interface for everything the [admin API](../reference/admin-api.md) offers. It runs as a separate Next.js application alongside the Rust backend and authenticates via AT Protocol OAuth. +HappyView ships with a web dashboard that provides a visual interface for everything the [admin API](../reference/admin-api.md) offers. It runs as a separate Next.js application alongside the Rust backend and authenticates via atproto OAuth. On a fresh deployment with no users in the database, the first person to log in to the dashboard is automatically bootstrapped as the super user with all permissions — so log in with the handle you want to own the instance first. @@ -23,11 +23,11 @@ HappyView generates a default Lua script when you first set the type to query or Toggle **Enable backfill** to index historical records when uploading a record-type lexicon. -**Network** lexicons are fetched from the AT Protocol network. Enter an NSID (e.g. `xyz.statusphere.status`) and HappyView resolves the schema automatically. If found, the lexicon JSON is displayed in a read-only editor. Click **Add** to track it. Network lexicons are kept up to date via the Jetstream subscription. See [Lexicons - Network lexicons](../guides/lexicons.md#network-lexicons) for how resolution works. +**Network** lexicons are fetched from the atproto network. Enter an NSID (e.g. `xyz.statusphere.status`) and HappyView resolves the schema automatically. If found, the lexicon JSON is displayed in a read-only editor. Click **Add** to track it. Network lexicons are kept up to date via the Jetstream subscription. See [Lexicons - Network lexicons](../guides/lexicons.md#network-lexicons) for how resolution works. ### JSON editor -The JSON editor provides real-time validation against the AT Protocol Lexicon v1 schema: +The JSON editor provides real-time validation against the atproto Lexicon v1 schema: - Validation for Lexicon format - Auto-complete for definition types (`record`, `query`, `procedure`, `subscription`), property types (`string`, `integer`, `boolean`, `ref`, `union`, `blob`, `cid-link`, etc.), and schema structure (`defs`, `main`, `properties`, `required`) @@ -41,7 +41,7 @@ See [Lua Scripting](../guides/scripting.md) for the full runtime reference and e ## Records -Navigate to **Records** to browse all indexed AT Protocol records. Records are grouped by collection and searchable. Each record shows its AT URI, author DID, and the raw record JSON. +Navigate to **Records** to browse all indexed atproto records. Records are grouped by collection and searchable. Each record shows its AT URI, author DID, and the raw record JSON. ## Backfill @@ -89,7 +89,7 @@ View the current values of all environment variables that affect HappyView's beh ### Accounts -Manage connected AT Protocol accounts used by the instance. +Manage connected atproto accounts used by the instance. ## Next steps diff --git a/packages/docs/docs/getting-started/quickstart.md b/packages/docs/docs/getting-started/quickstart.md index 8828db8..b6627b5 100644 --- a/packages/docs/docs/getting-started/quickstart.md +++ b/packages/docs/docs/getting-started/quickstart.md @@ -1,6 +1,6 @@ # Quickstart -This page walks you through the fastest path to a working HappyView instance. By the end, you'll have an AppView that indexes records from the AT Protocol network and serves XRPC endpoints. +This page walks you through the fastest path to a working HappyView instance. By the end, you'll have an AppView that indexes records from the atproto network and serves XRPC endpoints. ## 1. Deploy HappyView @@ -16,7 +16,7 @@ If you're just trying HappyView for the first time, start with Railway. ## 2. Log in to the dashboard -The built-in [dashboard](dashboard.md) is served at your instance's root URL. Log in with your AT Protocol identity — on a fresh deployment, the first handle to authenticate is automatically bootstrapped as the **super user** with all permissions, so use the handle you want to own the instance. +The built-in [dashboard](dashboard.md) is served at your instance's root URL. Log in with your atproto identity — on a fresh deployment, the first handle to authenticate is automatically bootstrapped as the **super user** with all permissions, so use the handle you want to own the instance. ## 3. Add your first lexicon diff --git a/packages/docs/docs/guides/backfill.md b/packages/docs/docs/guides/backfill.md index a7ad503..062d2ec 100644 --- a/packages/docs/docs/guides/backfill.md +++ b/packages/docs/docs/guides/backfill.md @@ -29,7 +29,7 @@ Re-running a backfill for a collection that's already been backfilled is safe. E ## Restoring deleted records -Deleting records from HappyView (via the dashboard or API) only removes them from the local database — the records still exist on the AT Protocol network. To restore deleted records, create a backfill job for the affected collection. The backfill will re-discover the repos and re-fetch all records from each PDS, restoring any that were previously deleted. +Deleting records from HappyView (via the dashboard or API) only removes them from the local database — the records still exist on the atproto network. To restore deleted records, create a backfill job for the affected collection. The backfill will re-discover the repos and re-fetch all records from each PDS, restoring any that were previously deleted. ## Next steps diff --git a/packages/docs/docs/guides/labelers.md b/packages/docs/docs/guides/labelers.md index cb12f60..f9894f3 100644 --- a/packages/docs/docs/guides/labelers.md +++ b/packages/docs/docs/guides/labelers.md @@ -78,5 +78,5 @@ Labels are also available in the records API response and in Lua scripts via the ## Next steps - [Admin API — Labelers](../reference/admin/labelers.md) — full endpoint documentation -- [AT Protocol API](../reference/lua/atproto-api.md) — access labels in Lua scripts with `get_labels` and `get_labels_batch` +- [atproto API](../reference/lua/atproto-api.md) — access labels in Lua scripts with `get_labels` and `get_labels_batch` - [Permissions](permissions.md) — manage user access to labeler operations diff --git a/packages/docs/docs/guides/lexicons.md b/packages/docs/docs/guides/lexicons.md index a45b422..d2ff04b 100644 --- a/packages/docs/docs/guides/lexicons.md +++ b/packages/docs/docs/guides/lexicons.md @@ -1,8 +1,8 @@ # Lexicons -Lexicons are the core building block of HappyView. They're [AT Protocol schema definitions](https://atproto.com/specs/lexicon) that describe your data model, and HappyView uses them to decide which records to index from the network and what XRPC endpoints to serve. +Lexicons are the core building block of HappyView. They're [atproto schema definitions](https://atproto.com/specs/lexicon) that describe your data model, and HappyView uses them to decide which records to index from the network and what XRPC endpoints to serve. -You don't write route handlers or database queries; you upload a lexicon and HappyView generates the infrastructure from it. There are two ways to add lexicons: uploading them via the [admin API](../reference/admin/lexicons.md) or [dashboard](../getting-started/dashboard.md), or fetching them directly from the AT Protocol network via [DNS authority resolution](#network-lexicons). +You don't write route handlers or database queries; you upload a lexicon and HappyView generates the infrastructure from it. There are two ways to add lexicons: uploading them via the [admin API](../reference/admin/lexicons.md) or [dashboard](../getting-started/dashboard.md), or fetching them directly from the atproto network via [DNS authority resolution](#network-lexicons). ## Supported lexicon types diff --git a/packages/docs/docs/guides/plugins.md b/packages/docs/docs/guides/plugins.md index d674d75..8b59aba 100644 --- a/packages/docs/docs/guides/plugins.md +++ b/packages/docs/docs/guides/plugins.md @@ -1,6 +1,6 @@ # Plugins -HappyView uses WASM plugins to extend its functionality. Plugins can integrate with external platforms, sync data to users' AT Protocol identities, and more. Auth plugins — the first supported plugin type — enable users to link accounts from platforms like Steam, Xbox, itch.io, and others, then sync data like game libraries. +HappyView uses WASM plugins to extend its functionality. Plugins can integrate with external platforms, sync data to users' atproto identities, and more. Auth plugins — the first supported plugin type — enable users to link accounts from platforms like Steam, Xbox, itch.io, and others, then sync data like game libraries. Official plugins for Steam, Xbox, itch.io, and other platforms are available in the [happyview-plugins](https://github.com/gamesgamesgamesgamesgames/happyview-plugins) repository. diff --git a/packages/docs/docs/guides/scripting.md b/packages/docs/docs/guides/scripting.md index 6ac53b5..b11c50f 100644 --- a/packages/docs/docs/guides/scripting.md +++ b/packages/docs/docs/guides/scripting.md @@ -68,7 +68,7 @@ Available in both queries and procedures: | ---------------- | ------- | ------------------------------------------------------------------- | | `now()` | string | Current UTC timestamp in ISO 8601 format | | `log(message)` | — | Log a message (appears in server logs at debug level) | -| `TID()` | string | Generate a fresh AT Protocol TID (13-character sortable identifier) | +| `TID()` | string | Generate a fresh atproto TID (13-character sortable identifier) | | `toarray(table)` | table | Mark a table as a JSON array for serialization (see [below](#toarray)) | ### toarray @@ -85,7 +85,7 @@ You don't need `toarray()` on results from `db.query`, `db.search`, `db.backlink ## Record API -The `Record` API is only available in **procedure** scripts. It handles creating, updating, loading, and deleting AT Protocol records. Writes are proxied to the caller's PDS and indexed locally. +The `Record` API is only available in **procedure** scripts. It handles creating, updating, loading, and deleting atproto records. Writes are proxied to the caller's PDS and indexed locally. See the full [Record API reference](../reference/lua/record-api.md) for constructor, static methods, instance methods, fields, schema validation, and save behavior. @@ -127,11 +127,11 @@ local resp = http.get("https://api.example.com/data") local data = json.decode(resp.body) ``` -## AT Protocol API +## atproto API -The `atproto` table provides AT Protocol utility functions like DID resolution and label queries. +The `atproto` table provides atproto utility functions like DID resolution and label queries. -See the full [AT Protocol API reference](../reference/lua/atproto-api.md) for `atproto.resolve_service_endpoint`, `atproto.get_labels`, and `atproto.get_labels_batch`. +See the full [atproto API reference](../reference/lua/atproto-api.md) for `atproto.resolve_service_endpoint`, `atproto.get_labels`, and `atproto.get_labels_batch`. ## JSON API diff --git a/packages/docs/docs/guides/sqlite-to-postgres-migration.md b/packages/docs/docs/guides/sqlite-to-postgres-migration.md index 00260b0..349d670 100644 --- a/packages/docs/docs/guides/sqlite-to-postgres-migration.md +++ b/packages/docs/docs/guides/sqlite-to-postgres-migration.md @@ -50,7 +50,7 @@ Start HappyView with the new `DATABASE_URL`. It will connect to Postgres and run ## Step 5: Re-index your data -Since HappyView indexes records from the AT Protocol network, the simplest way to populate your new Postgres database is to re-run the backfill: +Since HappyView indexes records from the atproto network, the simplest way to populate your new Postgres database is to re-run the backfill: 1. Upload your lexicons via the dashboard or admin API (or they will already be there if you exported and re-imported them) 2. Run a backfill for each collection (dashboard or `POST /admin/backfill`) diff --git a/packages/docs/docs/reference/admin-api.md b/packages/docs/docs/reference/admin-api.md index 3dd9cea..426f5f4 100644 --- a/packages/docs/docs/reference/admin-api.md +++ b/packages/docs/docs/reference/admin-api.md @@ -7,7 +7,7 @@ The admin API lets you manage lexicons, monitor records, run backfill jobs, and The admin API supports two authentication methods: 1. **API keys** — read/write tokens starting with `hv_`, passed as `Authorization: Bearer hv_...`. See the [API Keys guide](../guides/api-keys.md) for details. -2. **Service auth JWT** — AT Protocol inter-service authentication via signed JWTs. +2. **Service auth JWT** — atproto inter-service authentication via signed JWTs. In all cases the resolved DID is checked against the `users` table, and the user's permissions are loaded to authorize the request. diff --git a/packages/docs/docs/reference/admin/domains.md b/packages/docs/docs/reference/admin/domains.md index 55633c3..11750d5 100644 --- a/packages/docs/docs/reference/admin/domains.md +++ b/packages/docs/docs/reference/admin/domains.md @@ -1,6 +1,6 @@ # Admin API: Domains -Manage the domains a HappyView instance serves. Each domain gets its own AT Protocol OAuth client identity. The primary domain is set from `PUBLIC_URL` on first boot. All endpoints require the `settings:manage` permission. +Manage the domains a HappyView instance serves. Each domain gets its own atproto OAuth client identity. The primary domain is set from `PUBLIC_URL` on first boot. All endpoints require the `settings:manage` permission. ```sh # All examples assume $TOKEN is an API key (hv_...) diff --git a/packages/docs/docs/reference/admin/labelers.md b/packages/docs/docs/reference/admin/labelers.md index 14ea249..4434b2a 100644 --- a/packages/docs/docs/reference/admin/labelers.md +++ b/packages/docs/docs/reference/admin/labelers.md @@ -24,7 +24,7 @@ curl -X POST http://localhost:3000/admin/labelers \ | Field | Type | Required | Description | | ----- | ------ | -------- | ----------------------------- | -| `did` | string | yes | The labeler's AT Protocol DID | +| `did` | string | yes | The labeler's atproto DID | **Response**: `201 Created` (empty body) diff --git a/packages/docs/docs/reference/admin/lexicons.md b/packages/docs/docs/reference/admin/lexicons.md index 6b6b3ec..396d7dc 100644 --- a/packages/docs/docs/reference/admin/lexicons.md +++ b/packages/docs/docs/reference/admin/lexicons.md @@ -92,7 +92,7 @@ curl -X DELETE http://localhost:3000/admin/lexicons/xyz.statusphere.status -H "$ ## Network Lexicons -Network lexicons are fetched from the AT Protocol network via DNS TXT resolution and kept updated via the Jetstream subscription. See [Lexicons - Network lexicons](../../guides/lexicons.md#network-lexicons) for background. +Network lexicons are fetched from the atproto network via DNS TXT resolution and kept updated via the Jetstream subscription. See [Lexicons - Network lexicons](../../guides/lexicons.md#network-lexicons) for background. ### Add a network lexicon diff --git a/packages/docs/docs/reference/admin/users.md b/packages/docs/docs/reference/admin/users.md index 51aee60..3e5c667 100644 --- a/packages/docs/docs/reference/admin/users.md +++ b/packages/docs/docs/reference/admin/users.md @@ -27,7 +27,7 @@ curl -X POST http://localhost:3000/admin/users \ | Field | Type | Required | Description | | ------------- | -------- | -------- | ---------------------------------------------------------------------------------- | -| `did` | string | yes | The AT Protocol DID of the user to add | +| `did` | string | yes | The atproto DID of the user to add | | `template` | string | no | Permission template: `viewer`, `operator`, `manager`, or `full_access` | | `permissions` | string[] | no | Explicit list of permissions to grant (used instead of or in addition to `template`) | diff --git a/packages/docs/docs/reference/architecture.md b/packages/docs/docs/reference/architecture.md index 74662f2..eb294b4 100644 --- a/packages/docs/docs/reference/architecture.md +++ b/packages/docs/docs/reference/architecture.md @@ -195,7 +195,7 @@ sequenceDiagram | Column | Type | Description | | -------------- | ------------- | ------------------------------------------------ | | `id` | uuid (PK) | | -| `did` | text (unique) | User's AT Protocol DID | +| `did` | text (unique) | User's atproto DID | | `is_super` | boolean | Whether this is the super user (only one allowed)| | `created_at` | timestamptz | | | `last_used_at` | timestamptz | Updated on each authenticated request | @@ -226,7 +226,7 @@ sequenceDiagram | Column | Type | Description | | -------------- | ----------- | -------------------------------------------- | -| `did` | text (PK) | User's AT Protocol DID | +| `did` | text (PK) | User's atproto DID | | `session_data` | text | Serialized OAuth session (managed by atrium) | | `created_at` | timestamptz | | | `updated_at` | timestamptz | | diff --git a/packages/docs/docs/reference/glossary.md b/packages/docs/docs/reference/glossary.md index 61ca96a..51b4d5a 100644 --- a/packages/docs/docs/reference/glossary.md +++ b/packages/docs/docs/reference/glossary.md @@ -1,18 +1,18 @@ # Glossary -Key terms used throughout the HappyView documentation. For a broader introduction to the AT Protocol, see the [official ATProto glossary](https://atproto.com/guides/glossary). +Key terms used throughout the HappyView documentation. For a broader introduction to the atproto, see the [official ATProto glossary](https://atproto.com/guides/glossary). -## AT Protocol terms +## atproto terms -**AppView** — A backend service that indexes AT Protocol records and serves them through an API. HappyView is an AppView. See the [ATProto docs](https://atproto.com/guides/glossary#app-view) for more. +**AppView** — A backend service that indexes atproto records and serves them through an API. HappyView is an AppView. See the [ATProto docs](https://atproto.com/guides/glossary#app-view) for more. **DID** (Decentralized Identifier) — A persistent, globally unique identifier for an account (e.g. `did:plc:abc123`). -**Firehose** — A real-time stream of all record events (creates, updates, deletes) across the AT Protocol network. HappyView consumes a filtered slice of this via [Jetstream](https://github.com/bluesky-social/jetstream). +**Firehose** — A real-time stream of all record events (creates, updates, deletes) across the atproto network. HappyView consumes a filtered slice of this via [Jetstream](https://github.com/bluesky-social/jetstream). **Handle** — A human-readable name for an account (e.g. `user.bsky.social`). Handles resolve to a DID via a DNS TXT record or an HTTP `.well-known/atproto-did` lookup. -**Lexicon** — A schema definition for AT Protocol data types and API methods. Lexicons define what records look like, what endpoints exist, and what parameters they accept. See [Lexicons](../guides/lexicons.md). +**Lexicon** — A schema definition for atproto data types and API methods. Lexicons define what records look like, what endpoints exist, and what parameters they accept. See [Lexicons](../guides/lexicons.md). **NSID** (Namespaced Identifier) — A reverse-DNS identifier for a lexicon (e.g. `xyz.statusphere.status`). The authority is everything except the last segment. @@ -20,7 +20,7 @@ Key terms used throughout the HappyView documentation. For a broader introductio **PLC directory** — A public service (e.g. `plc.directory`) that maps DIDs to their DID documents, which contain the user's PDS endpoint and other metadata. -**Record** — A single piece of data in an AT Protocol repository, identified by an AT URI (e.g. `at://did:plc:abc/xyz.statusphere.status/abc123`). +**Record** — A single piece of data in an atproto repository, identified by an AT URI (e.g. `at://did:plc:abc/xyz.statusphere.status/abc123`). **Relay** — A network service that aggregates repository data from many PDSes. HappyView queries the relay during [backfill](../guides/backfill.md) to discover which repos contain records for a given collection, then fetches each repo's records directly from its PDS. @@ -28,15 +28,15 @@ Key terms used throughout the HappyView documentation. For a broader introductio **TID** (Timestamp Identifier) — A 13-character sortable identifier used as a record key. Generated from the current timestamp. -**XRPC** — The HTTP-based RPC protocol used by the AT Protocol. Query methods map to GET requests, procedure methods map to POST requests. See [XRPC API](xrpc-api.md). +**XRPC** — The HTTP-based RPC protocol used by the atproto. Query methods map to GET requests, procedure methods map to POST requests. See [XRPC API](xrpc-api.md). -**Jetstream** — A [filtered firehose](https://github.com/bluesky-social/jetstream) that delivers atproto record commit events as JSON over WebSocket. Not part of the core AT Protocol spec, but widely used. HappyView subscribes to Jetstream with a collection filter built from its indexed record lexicons, and persists a cursor for resume on reconnect. +**Jetstream** — A [filtered firehose](https://github.com/bluesky-social/jetstream) that delivers atproto record commit events as JSON over WebSocket. Not part of the core atproto spec, but widely used. HappyView subscribes to Jetstream with a collection filter built from its indexed record lexicons, and persists a cursor for resume on reconnect. ## HappyView-specific terms **Backfill** — The process of bulk-indexing existing records from the network. HappyView discovers repos via the relay and fetches each repo's records directly from its PDS. Runs when a new record-type lexicon is uploaded or triggered manually. See [Backfill](../guides/backfill.md). -**Network lexicon** — A lexicon fetched directly from the AT Protocol network via DNS authority resolution, rather than uploaded manually. See [Lexicons - Network lexicons](../guides/lexicons.md#network-lexicons). +**Network lexicon** — A lexicon fetched directly from the atproto network via DNS authority resolution, rather than uploaded manually. See [Lexicons - Network lexicons](../guides/lexicons.md#network-lexicons). **Permission** — A granular access control right that authorizes a specific action in the admin API. HappyView defines 20 permissions organized by category (e.g. `lexicons:create`, `users:read`). See [Permissions](../guides/permissions.md). diff --git a/packages/docs/docs/reference/lua/atproto-api.md b/packages/docs/docs/reference/lua/atproto-api.md index df77a82..cad79e5 100644 --- a/packages/docs/docs/reference/lua/atproto-api.md +++ b/packages/docs/docs/reference/lua/atproto-api.md @@ -1,6 +1,6 @@ -# AT Protocol API +# atproto API -The `atproto` table provides AT Protocol utility functions. Available in queries, procedures, and [index hooks](../../guides/index-hooks.md). +The `atproto` table provides atproto utility functions. Available in queries, procedures, and [index hooks](../../guides/index-hooks.md). ## atproto.resolve_service_endpoint @@ -8,7 +8,7 @@ The `atproto` table provides AT Protocol utility functions. Available in queries local endpoint = atproto.resolve_service_endpoint(did) ``` -Resolves a DID to its AT Protocol service endpoint URL by fetching the DID document. Supports both `did:plc:*` (via the PLC directory) and `did:web:*` (via `.well-known/did.json`). +Resolves a DID to its atproto service endpoint URL by fetching the DID document. Supports both `did:plc:*` (via the PLC directory) and `did:web:*` (via `.well-known/did.json`). | Parameter | Type | Description | | --------- | ------ | ------------------------ | diff --git a/packages/docs/docs/reference/lua/record-api.md b/packages/docs/docs/reference/lua/record-api.md index 3a348ae..79e2107 100644 --- a/packages/docs/docs/reference/lua/record-api.md +++ b/packages/docs/docs/reference/lua/record-api.md @@ -1,6 +1,6 @@ # Record API -The `Record` API is only available in **procedure** scripts. It handles creating, updating, loading, and deleting AT Protocol records. Writes are proxied to the caller's PDS and indexed locally. +The `Record` API is only available in **procedure** scripts. It handles creating, updating, loading, and deleting atproto records. Writes are proxied to the caller's PDS and indexed locally. ## Constructor diff --git a/packages/docs/docs/reference/scripts/cascading-delete.md b/packages/docs/docs/reference/scripts/cascading-delete.md index 34a85ca..efdd53a 100644 --- a/packages/docs/docs/reference/scripts/cascading-delete.md +++ b/packages/docs/docs/reference/scripts/cascading-delete.md @@ -72,4 +72,4 @@ curl -X POST http://localhost:3000/xrpc/xyz.statusphere.deletePost \ Cascading deletes are useful when your data model has parent-child relationships across collections. For example, deleting a post should also clean up its comments, reactions, or metadata records. This keeps the user's repo and the local index consistent. -Note that this only deletes records owned by `caller_did`. AT Protocol records can only be deleted by their owner. If the related records could have more than 100 matches, paginate through all of them before deleting. +Note that this only deletes records owned by `caller_did`. atproto records can only be deleted by their owner. If the related records could have more than 100 matches, paginate through all of them before deleting. diff --git a/packages/docs/docs/reference/scripts/sidecar-records.md b/packages/docs/docs/reference/scripts/sidecar-records.md index c1083c1..567ddeb 100644 --- a/packages/docs/docs/reference/scripts/sidecar-records.md +++ b/packages/docs/docs/reference/scripts/sidecar-records.md @@ -72,4 +72,4 @@ at:// did:plc:abc /xyz.statusphere.postMetadata /3abc123 ^^^^^^^ same rkey ``` -This is a common AT Protocol pattern for keeping a primary record lean while storing auxiliary data (metadata, reactions, settings) in a companion collection. +This is a common atproto pattern for keeping a primary record lean while storing auxiliary data (metadata, reactions, settings) in a companion collection. diff --git a/packages/docs/docs/reference/troubleshooting.md b/packages/docs/docs/reference/troubleshooting.md index 4d767ec..d3e2645 100644 --- a/packages/docs/docs/reference/troubleshooting.md +++ b/packages/docs/docs/reference/troubleshooting.md @@ -108,7 +108,7 @@ See [Backfill](../guides/backfill.md) for how the process works. ## OAuth or login issues -HappyView handles AT Protocol OAuth internally via the `atrium-oauth` library. If users can't log in: +HappyView handles atproto OAuth internally via the `atrium-oauth` library. If users can't log in: 1. Verify `PUBLIC_URL` is set correctly and the URL is publicly accessible (required for OAuth callbacks). 2. Check that the user's PDS authorization server is reachable. diff --git a/packages/docs/docs/reference/xrpc-api.md b/packages/docs/docs/reference/xrpc-api.md index 2329547..7b5f7fa 100644 --- a/packages/docs/docs/reference/xrpc-api.md +++ b/packages/docs/docs/reference/xrpc-api.md @@ -1,6 +1,6 @@ # XRPC API -[XRPC](https://atproto.com/specs/xrpc) is the HTTP-based RPC protocol used by the AT Protocol. HappyView dynamically registers XRPC endpoints based on your uploaded [lexicons](../guides/lexicons.md): query lexicons become `GET /xrpc/{nsid}` routes, procedure lexicons become `POST /xrpc/{nsid}` routes. +[XRPC](https://atproto.com/specs/xrpc) is the HTTP-based RPC protocol used by the atproto. HappyView dynamically registers XRPC endpoints based on your uploaded [lexicons](../guides/lexicons.md): query lexicons become `GET /xrpc/{nsid}` routes, procedure lexicons become `POST /xrpc/{nsid}` routes. If a query or procedure lexicon has a [Lua script](../guides/scripting.md) attached, the script handles the request. Otherwise, HappyView uses built-in default behavior (described below). diff --git a/packages/docs/docs/sdk/lex-agent.md b/packages/docs/docs/sdk/lex-agent.md index 4bf7244..40c333a 100644 --- a/packages/docs/docs/sdk/lex-agent.md +++ b/packages/docs/docs/sdk/lex-agent.md @@ -1,6 +1,6 @@ # Lex Agent -The Lex agent adapter is the recommended way to interact with HappyView from JavaScript. It creates an [`@atproto/lex`](https://www.npmjs.com/package/@atproto/lex) `Agent` from a `HappyViewSession`, so you can use `@atproto/lex`'s type-safe `Client` to make XRPC calls with HappyView's DPoP authentication. All requests are routed to your HappyView instance, which handles its own lexicons locally and proxies standard AT Protocol methods (e.g., `com.atproto.repo.createRecord`) to the user's PDS. +The Lex agent adapter is the recommended way to interact with HappyView from JavaScript. It creates an [`@atproto/lex`](https://www.npmjs.com/package/@atproto/lex) `Agent` from a `HappyViewSession`, so you can use `@atproto/lex`'s type-safe `Client` to make XRPC calls with HappyView's DPoP authentication. All requests are routed to your HappyView instance, which handles its own lexicons locally and proxies standard atproto methods (e.g., `com.atproto.repo.createRecord`) to the user's PDS. The adapter gives you lexicon-level type checking on parameters, input bodies, and responses, and works with any library or tool that accepts an `@atproto/lex` `Agent`. diff --git a/packages/docs/docs/sdk/oauth-client-browser.md b/packages/docs/docs/sdk/oauth-client-browser.md index a6a9dd8..2746ca8 100644 --- a/packages/docs/docs/sdk/oauth-client-browser.md +++ b/packages/docs/docs/sdk/oauth-client-browser.md @@ -1,6 +1,6 @@ # Browser Client -The browser client handles the full OAuth redirect flow for browser apps authenticating with a HappyView instance. It wraps the [OAuth Client](./oauth-client.md) with Web Crypto, localStorage, and AT Protocol handle/DID resolution. +The browser client handles the full OAuth redirect flow for browser apps authenticating with a HappyView instance. It wraps the [OAuth Client](./oauth-client.md) with Web Crypto, localStorage, and atproto handle/DID resolution. If you're starting a new app, consider using [`@happyview/lex-agent`](./lex-agent.md) with `@atproto/lex` instead — it provides type-safe XRPC calls and is the recommended way to interact with HappyView. This package is primarily useful if your app already uses `@atproto/oauth-client-browser` and you want to add HappyView authentication alongside it. diff --git a/packages/docs/docs/sdk/oauth-client.md b/packages/docs/docs/sdk/oauth-client.md index 5f65a62..b73d034 100644 --- a/packages/docs/docs/sdk/oauth-client.md +++ b/packages/docs/docs/sdk/oauth-client.md @@ -37,7 +37,7 @@ const { provisionId, dpopKey, pkceVerifier } = For public clients, `pkceVerifier` is included and must be passed back when registering the session. For confidential clients it will be `undefined`. -Use the returned `dpopKey` (a private JWK) as your DPoP keypair during your AT Protocol OAuth flow with the user's PDS. +Use the returned `dpopKey` (a private JWK) as your DPoP keypair during your atproto OAuth flow with the user's PDS. ## Session registration diff --git a/packages/docs/docs/sdk/overview.md b/packages/docs/docs/sdk/overview.md index 4df6f95..82b78c2 100644 --- a/packages/docs/docs/sdk/overview.md +++ b/packages/docs/docs/sdk/overview.md @@ -12,7 +12,7 @@ HappyView provides JavaScript packages for building third-party apps that authen **Starting a new app?** Use `@happyview/lex-agent` with `@atproto/lex`. It gives you type-safe XRPC calls through a `Client` that routes requests to your HappyView instance with DPoP authentication. This is the recommended way to interact with HappyView from JavaScript. -**Already using `@atproto/oauth-client-browser`?** Add `@happyview/oauth-client-browser` to get a `HappyViewBrowserClient` that handles the HappyView-specific DPoP key provisioning and session registration on top of the standard AT Protocol OAuth flow. +**Already using `@atproto/oauth-client-browser`?** Add `@happyview/oauth-client-browser` to get a `HappyViewBrowserClient` that handles the HappyView-specific DPoP key provisioning and session registration on top of the standard atproto OAuth flow. **Building a server-side app or something more custom?** Use `@happyview/oauth-client` directly and provide your own `CryptoAdapter` and `StorageAdapter`. @@ -21,9 +21,9 @@ HappyView provides JavaScript packages for building third-party apps that authen Third-party apps authenticate using HappyView's [DPoP key provisioning](../getting-started/authentication.md#dpop-key-provisioning-for-third-party-apps) flow: 1. The SDK requests a DPoP keypair from the HappyView instance. -2. Your app runs a standard AT Protocol OAuth flow with the user's PDS using that keypair. +2. Your app runs a standard atproto OAuth flow with the user's PDS using that keypair. 3. The SDK registers the resulting tokens with HappyView. -4. All subsequent XRPC requests are authenticated with DPoP proofs — HappyView handles its own lexicons locally and proxies standard AT Protocol writes to the user's PDS. +4. All subsequent XRPC requests are authenticated with DPoP proofs — HappyView handles its own lexicons locally and proxies standard atproto writes to the user's PDS. ## Quick start diff --git a/packages/docs/docs/tutorials/statusphere.md b/packages/docs/docs/tutorials/statusphere.md index 6110a94..3791471 100644 --- a/packages/docs/docs/tutorials/statusphere.md +++ b/packages/docs/docs/tutorials/statusphere.md @@ -1,6 +1,6 @@ # Tutorial: Statusphere with HappyView -[Statusphere](https://github.com/bluesky-social/statusphere-example-app) is an example AT Protocol application where users set their current status as a single emoji. It's a great way to learn how HappyView works because the data model is simple but the queries are interesting. +[Statusphere](https://github.com/bluesky-social/statusphere-example-app) is an example atproto application where users set their current status as a single emoji. It's a great way to learn how HappyView works because the data model is simple but the queries are interesting. In this tutorial, you'll set up HappyView to act as the AppView for Statusphere. By the end, you'll have indexed records and working XRPC endpoints. @@ -19,11 +19,20 @@ Users can set their status as many times as they want. Each status is a new reco For more background on how the app works, see the [ATProto Statusphere guide](https://atproto.com/guides/applications). -## Step 1: Upload the record lexicon +## Step 1: Add the record lexicon -First, upload the `xyz.statusphere.status` lexicon to HappyView. This tells HappyView to start indexing Statusphere records from across the network as they're created, updated, or deleted. +First, tell HappyView to start indexing Statusphere records. Since `xyz.statusphere.status` is [published on the atproto network](../guides/lexicons.md#network-lexicons), you can add it directly from the dashboard: -The examples below use `$TOKEN` as a placeholder for an API key. See [Authentication](../getting-started/authentication.md) and the [API Keys guide](../guides/api-keys.md) for how to get one. +1. Go to **Lexicons > Add Lexicon > Network** +2. Enter `xyz.statusphere.status` +3. HappyView resolves the schema from its authority domain records and shows a preview +4. Enable the **Backfill** toggle so HappyView fetches existing records from the network +5. Click **Add** + +HappyView now subscribes to `xyz.statusphere.status` via Jetstream and kicks off a backfill job to index historical records. + +:::tip +You can also add lexicons via the [admin API](../reference/admin/lexicons.md). This is useful for automation or CI/CD workflows: ```sh curl -X POST http://localhost:3000/admin/lexicons \ @@ -52,63 +61,31 @@ curl -X POST http://localhost:3000/admin/lexicons \ }' ``` -HappyView now subscribes to `xyz.statusphere.status` via Jetstream. The `backfill` flag tells HappyView to also index existing status records from the network. You can monitor progress with `GET /admin/backfill/status` or the [dashboard](../getting-started/dashboard.md). - -:::tip -Since the `xyz.statusphere.status` lexicon is [published on the AT Protocol network](../guides/lexicons.md#network-lexicons), you can also add it as a network lexicon instead of uploading the JSON manually: - -```sh -curl -X POST http://localhost:3000/admin/network-lexicons \ - -H "Authorization: Bearer $TOKEN" \ - -H "Content-Type: application/json" \ - -d '{ "nsid": "xyz.statusphere.status" }' -``` - ::: ## Step 2: Verify records are being indexed -Once the backfill starts processing, you should see records appearing. Check the stats: +Once the backfill starts, you should see records appearing in the dashboard: -```sh -curl http://localhost:3000/admin/stats \ - -H "Authorization: Bearer $TOKEN" -``` - -```json -{ - "total_records": 1234, - "collections": [{ "collection": "xyz.statusphere.status", "count": 1234 }] -} -``` +1. The **home page** shows a live record count and per-collection breakdown +2. Go to **Records** to browse individual indexed statuses +3. Go to **Backfill** to watch the backfill job progress — you'll see the number of repos processed and records fetched ## Step 3: Add a query lexicon for listing statuses -Now add a query endpoint to read the indexed data. Upload a query lexicon with `target_collection` pointing at the record collection from Step 1: +Now add a query endpoint to read the indexed data: -```sh -curl -X POST http://localhost:3000/admin/lexicons \ - -H "Authorization: Bearer $TOKEN" \ - -H "Content-Type: application/json" \ - -d '{ - "lexicon_json": { - "lexicon": 1, - "id": "xyz.statusphere.listStatuses", - "defs": { - "main": { - "type": "query", - "output": { "encoding": "application/json" } - } - } - }, - "target_collection": "xyz.statusphere.status" - }' -``` +1. Go to **Lexicons > Add Lexicon > Local** +2. Set the NSID to `xyz.statusphere.listStatuses` +3. Set the type to **Query** +4. Set `target_collection` to `xyz.statusphere.status` — this tells the query which record collection it operates on (`target_collection` is a HappyView-specific field, not part of the lexicon spec) +5. Click **Add** This creates a `GET /xrpc/xyz.statusphere.listStatuses` endpoint. Without a Lua script, it uses HappyView's built-in default behavior: listing records with `limit`, `cursor`, and `did` parameters, or fetching a single record by `uri`. Try it: ```sh -curl "http://localhost:3000/xrpc/xyz.statusphere.listStatuses?limit=5" +curl "http://localhost:3000/xrpc/xyz.statusphere.listStatuses?limit=5" \ + -H "X-Client-Key: $CLIENT_KEY" ``` ```json @@ -133,7 +110,11 @@ See [XRPC API](../reference/xrpc-api.md) for the full default query behavior. ## Step 4: Enhance the query with a Lua script -The default query behavior works, but let's customize it with a [Lua script](../guides/scripting.md). Here's a script that handles single-record lookups by URI and paginated listing with an optional DID filter: +The default query behavior works, but let's customize it with a [Lua script](../guides/scripting.md). The script will handle single-record lookups by URI and paginated listing with an optional DID filter. + +1. Click on **xyz.statusphere.listStatuses** in the lexicon list to open its detail page +2. The Lua script editor is at the bottom of the page +3. Paste in the following script: ```lua function handle() @@ -154,73 +135,31 @@ function handle() end ``` -Re-upload the lexicon with parameters defined in the schema and the script attached: - -```sh -LEXICON='{ - "lexicon": 1, - "id": "xyz.statusphere.listStatuses", - "defs": { - "main": { - "type": "query", - "parameters": { - "type": "params", - "properties": { - "uri": { "type": "string" }, - "did": { "type": "string" }, - "limit": { "type": "integer" }, - "cursor": { "type": "string" } - } - }, - "output": { "encoding": "application/json" } - } - } -}' - -SCRIPT='function handle() - if params.uri then - local record = db.get(params.uri) - if not record then - return { error = "not found" } - end - return { record = record } - end - - return db.query({ - collection = collection, - did = params.did, - limit = tonumber(params.limit) or 20, - cursor = params.cursor, - }) -end' - -curl -X POST http://localhost:3000/admin/lexicons \ - -H "Authorization: Bearer $TOKEN" \ - -H "Content-Type: application/json" \ - -d "{ - \"lexicon_json\": $LEXICON, - \"target_collection\": \"xyz.statusphere.status\", - \"script\": \"$SCRIPT\" - }" -``` +4. Click **Save** The endpoint now uses your custom logic. Filter by a specific user: ```sh -curl "http://localhost:3000/xrpc/xyz.statusphere.listStatuses?did=did:plc:abc&limit=1" +curl "http://localhost:3000/xrpc/xyz.statusphere.listStatuses?did=did:plc:abc&limit=1" \ + -H "X-Client-Key: $CLIENT_KEY" ``` Fetch a single record by URI: ```sh -curl "http://localhost:3000/xrpc/xyz.statusphere.listStatuses?uri=at://did:plc:abc/xyz.statusphere.status/3abc123" +curl "http://localhost:3000/xrpc/xyz.statusphere.listStatuses?uri=at://did:plc:abc/xyz.statusphere.status/3abc123" \ + -H "X-Client-Key: $CLIENT_KEY" ``` ## Step 5: Add a procedure lexicon for setting status -Add a write endpoint so users can set their status through your AppView. This creates a `POST /xrpc/xyz.statusphere.setStatus` endpoint that proxies writes to the user's PDS. +Add a write endpoint so users can set their status through your AppView: -The Lua script auto-fills `createdAt` and uses the authenticated user's DID: +1. Go to **Lexicons > Add Lexicon > Local** +2. Set the NSID to `xyz.statusphere.setStatus` +3. Set the type to **Procedure** +4. Set `target_collection` to `xyz.statusphere.status` +5. A default Lua script is generated — replace it with: ```lua function handle() @@ -233,47 +172,19 @@ function handle() end ``` -Upload the procedure lexicon with this script: - -```sh -LEXICON='{ - "lexicon": 1, - "id": "xyz.statusphere.setStatus", - "defs": { - "main": { - "type": "procedure", - "input": { "encoding": "application/json" }, - "output": { "encoding": "application/json" } - } - } -}' - -SCRIPT='function handle() - local r = Record(collection, { - status = input.status, - createdAt = now(), - }) - r:save() - return { uri = r._uri, cid = r._cid } -end' +6. Click **Add** -curl -X POST http://localhost:3000/admin/lexicons \ - -H "Authorization: Bearer $TOKEN" \ - -H "Content-Type: application/json" \ - -d "{ - \"lexicon_json\": $LEXICON, - \"target_collection\": \"xyz.statusphere.status\", - \"script\": \"$SCRIPT\" - }" -``` +This creates a `POST /xrpc/xyz.statusphere.setStatus` endpoint that creates records on the user's PDS and indexes them locally. ## Step 6: Test the procedure endpoint -Set a status (requires authentication): +Set a status. This requires DPoP authentication — the [JavaScript SDK](../sdk/overview.md) handles this for you, but you can test with curl if you have a token: ```sh curl -X POST http://localhost:3000/xrpc/xyz.statusphere.setStatus \ - -H "Authorization: Bearer $TOKEN" \ + -H "X-Client-Key: $CLIENT_KEY" \ + -H "Authorization: DPoP $TOKEN" \ + -H "DPoP: $DPOP_PROOF" \ -H "Content-Type: application/json" \ -d '{ "status": "\ud83d\ude80" }' ``` @@ -289,17 +200,20 @@ The record is created on your PDS and immediately indexed by HappyView. ## What you've built -With three lexicon uploads and a few lines of Lua, you have a complete Statusphere AppView: +With three lexicons and a few lines of Lua, you have a complete Statusphere AppView: -- **Real-time indexing** of `xyz.statusphere.status` records from the entire AT Protocol network +- **Real-time indexing** of `xyz.statusphere.status` records from the entire atproto network - **Historical backfill** of existing status records - **A query endpoint** (`xyz.statusphere.listStatuses`) with filtering, pagination, and single-record lookups - **A write endpoint** (`xyz.statusphere.setStatus`) that creates records on the user's PDS and indexes them locally +Everything was done through the dashboard — no server restarts, no config files, no deploys. For automation and CI/CD, the same operations are available via the [admin API](../reference/admin-api.md). + ## Next steps - [Lua Scripting](../guides/scripting.md): Explore the full Record and database APIs to build more complex queries - [Lexicons](../guides/lexicons.md): Learn about network lexicons, the backfill flag, and target collections - [XRPC API](../reference/xrpc-api.md): Understand how the generated endpoints behave +- [Admin API](../reference/admin-api.md): Automate lexicon management via the API - [Statusphere example app](https://github.com/bluesky-social/statusphere-example-app): See the full Statusphere frontend - [ATProto Statusphere guide](https://atproto.com/guides/applications): Deep dive into how the app works at the protocol level diff --git a/packages/docs/sidebars.ts b/packages/docs/sidebars.ts index bab5d06..a2641d1 100644 --- a/packages/docs/sidebars.ts +++ b/packages/docs/sidebars.ts @@ -370,7 +370,7 @@ const sidebars: SidebarsConfig = { { type: "doc", id: "reference/lua/atproto-api", - label: "AT Protocol API", + label: "atproto API", }, { type: "doc", -- 2.51.2