From 1c2aafb7930d8702c5a84d27e1a0bf48864818a4 Mon Sep 17 00:00:00 2001 From: djstrong Date: Wed, 13 May 2026 21:58:22 +0200 Subject: [PATCH 01/11] feat(docs): add planned integrations for ENSDb snapshots, CLI, and webhooks - Introduced new sidebar topics for "ENSDb snapshots & CLI" and "Webhooks & events" in integration documentation. - Added a new component for ENSDb snapshots teaser to highlight benefits. - Created detailed documentation for both planned features, outlining their value propositions and use cases. - Updated existing integration options to reference the new features, enhancing the overall documentation structure. --- .../starlight/sidebar-topics/integrate.ts | 16 +++ .../starlight/sidebar-topics/services.ts | 9 ++ .../molecules/EnsDbSnapshotsTeaser.astro | 24 ++++ .../integrate/ensdb-snapshots-and-cli.mdx | 77 +++++++++++++ .../src/content/docs/docs/integrate/index.mdx | 1 + .../integrate/integration-options/ensdb.mdx | 4 + .../docs/integrate/webhooks-and-events.mdx | 108 ++++++++++++++++++ .../content/docs/docs/reference/roadmap.mdx | 14 +++ .../src/content/docs/docs/self-host/index.mdx | 21 +++- .../docs/docs/services/ensdb/index.mdx | 6 + .../docs/docs/services/ensengine/index.mdx | 100 ++++++++++++++++ .../src/content/docs/docs/services/index.mdx | 5 +- 12 files changed, 382 insertions(+), 3 deletions(-) create mode 100644 docs/ensnode.io/src/components/molecules/EnsDbSnapshotsTeaser.astro create mode 100644 docs/ensnode.io/src/content/docs/docs/integrate/ensdb-snapshots-and-cli.mdx create mode 100644 docs/ensnode.io/src/content/docs/docs/integrate/webhooks-and-events.mdx create mode 100644 docs/ensnode.io/src/content/docs/docs/services/ensengine/index.mdx diff --git a/docs/ensnode.io/config/integrations/starlight/sidebar-topics/integrate.ts b/docs/ensnode.io/config/integrations/starlight/sidebar-topics/integrate.ts index d74b6bd31e..18454f7091 100644 --- a/docs/ensnode.io/config/integrations/starlight/sidebar-topics/integrate.ts +++ b/docs/ensnode.io/config/integrations/starlight/sidebar-topics/integrate.ts @@ -61,6 +61,22 @@ export const integrateSidebarTopic = { label: "ENSDb (PostgreSQL)", link: "/docs/integrate/integration-options/ensdb", }, + { + label: "ENSDb snapshots & CLI", + link: "/docs/integrate/ensdb-snapshots-and-cli", + badge: { + text: "Planned", + variant: "note", + }, + }, + { + label: "Webhooks & events", + link: "/docs/integrate/webhooks-and-events", + badge: { + text: "Planned", + variant: "note", + }, + }, ], }, { diff --git a/docs/ensnode.io/config/integrations/starlight/sidebar-topics/services.ts b/docs/ensnode.io/config/integrations/starlight/sidebar-topics/services.ts index d1ba48aeba..d192d7ef55 100644 --- a/docs/ensnode.io/config/integrations/starlight/sidebar-topics/services.ts +++ b/docs/ensnode.io/config/integrations/starlight/sidebar-topics/services.ts @@ -177,5 +177,14 @@ export const servicesSidebarTopic = { { label: "Contributing", link: "/docs/services/ensadmin/contributing" }, ], }, + { + label: "ENSEngine", + collapsed: true, + badge: { + text: "Planned", + variant: "note", + }, + items: [{ label: "Overview", link: "/docs/services/ensengine" }], + }, ], }; diff --git a/docs/ensnode.io/src/components/molecules/EnsDbSnapshotsTeaser.astro b/docs/ensnode.io/src/components/molecules/EnsDbSnapshotsTeaser.astro new file mode 100644 index 0000000000..cf04ccefda --- /dev/null +++ b/docs/ensnode.io/src/components/molecules/EnsDbSnapshotsTeaser.astro @@ -0,0 +1,24 @@ +--- +import { Card, CardGrid } from "@astrojs/starlight/components"; +--- + + + + Skip the historical RPC fanout entirely. Pull down a published ENSDb snapshot instead of replaying years of chain history through your own RPC provider - saving real money on every bootstrap, every CI run, every fresh environment. + + + Skip the long historical backfill too. A nearly up-to-date ENS index is ready as fast as you can download it - no specially configured Postgres required, no overnight wait. Perfect for hackathons, demos, prototypes, and any other time you need a fresh ENSDb fast. + + + Use snapshots as deterministic fixtures for tests and CI pipelines. Every run starts from the same well-known ENS state, with zero RPC dependency. + + + Diff snapshots across ENSNode versions to catch unexpected changes in indexed data - a powerful way to validate indexing-logic refactors before a release ships. + + + Bootstrap your own ENSNode instance from a recent snapshot, then catch up to realtime from there. Less time waiting, more time building. + + + The planned `ensdb-cli` will surface the operations you actually need day-to-day: inspect indexer instances, manage snapshots, clean up unused schemas, and more. + + diff --git a/docs/ensnode.io/src/content/docs/docs/integrate/ensdb-snapshots-and-cli.mdx b/docs/ensnode.io/src/content/docs/docs/integrate/ensdb-snapshots-and-cli.mdx new file mode 100644 index 0000000000..5e4d3136af --- /dev/null +++ b/docs/ensnode.io/src/content/docs/docs/integrate/ensdb-snapshots-and-cli.mdx @@ -0,0 +1,77 @@ +--- +title: ENSDb snapshots & CLI +description: Coming soon - publish, download, and diff snapshots of the live ENS state, and operate ENSNode like a database with the planned ensdb-cli. +--- + +import { LinkCard, Aside } from "@astrojs/starlight/components"; +import EnsDbSnapshotsTeaser from "../../../../components/molecules/EnsDbSnapshotsTeaser.astro"; + + + +## The problem + +Standing up a useful ENS index from zero is **expensive on two axes: time and money**. A full historical backfill across mainnet, Basenames, Lineanames, 3DNS, and friends means hours-to-days of indexing *and* a heavy RPC bill - every request to your provider, multiplied by every chain, multiplied by every block of history you have to replay. Add a specially configured Postgres on the other side and the cost of "just spin up a fresh ENSDb" stops being a rounding error. That tax is painful for anyone building, prototyping, demoing, or testing - and it hits hardest in exactly the moments where speed matters most. + +[ENSDb](/docs/services/ensdb) already gives you the live, onchain state of ENS in a plain PostgreSQL database that any language with a Postgres driver can read. The next step is making it **trivial - and cheap - to bootstrap and operate** that database. That's what ENSDb snapshots and `ensdb-cli` are for. + +## What we're building toward + +ENSDb snapshots will be **portable, versioned packages of an ENSDb instance** that anyone can publish or consume. Pull one down, restore it into Postgres, and start querying ENS in minutes instead of waiting on a fresh indexer to catch up - **without** sending the underlying RPC requests yourself. Then catch up to realtime from your own ENSIndexer whenever you're ready. + +`ensdb-cli` will be the operator-facing tool around them - the surface where you list indexer instances and their indexing status, generate fresh snapshots, inspect what configuration a snapshot was built with, and clean up schemas you no longer need. + + + +## Who this is for + +- **Hackathon teams and prototypers** who want a real ENS index right now and don't want to babysit an indexer overnight. +- **Self-hosters** standing up new ENSNode instances who'd rather start from a recent snapshot than backfill from genesis. +- **CI and testing pipelines** that need deterministic ENS state to run repeatable assertions against. +- **Maintainers** running release reviews who want to diff indexed data across versions to catch unintended regressions before they ship. +- **Anyone building specialized ENS services on top of ENSDb** who needs faster iteration loops and lower operational cost. + +## How this complements ENSDb + +Snapshots and the CLI sit *on top of* the [ENSDb open standard](/docs/services/ensdb). Because ENSDb is just Postgres governed by a well-defined schema, snapshots are portable: any [ENSDb Writer](/docs/services/ensdb/concepts/glossary#ensdb-writer) implementation can produce one, and any [ENSDb Reader](/docs/services/ensdb/concepts/glossary#ensdb-reader) (or your own code) can consume one. + +This is the same foundation that powers ENSNode's other planned ENSDb capabilities - including [Webhooks & events](/docs/integrate/webhooks-and-events), which reacts to changes in your ENSDb in real time. + +## What this page is not + +This page is intentionally light on technical specifics. There is no SDK to call yet, no CLI flag reference, no snapshot file format to integrate against. Those will arrive in dedicated reference docs once the products land. + +In the meantime, the goals above are stable enough to plan around. If your project would benefit from any of them, we'd love to hear from you while the design is still flexible. + +## Related + + + + + + + + + + diff --git a/docs/ensnode.io/src/content/docs/docs/integrate/index.mdx b/docs/ensnode.io/src/content/docs/docs/integrate/index.mdx index c9aed63f8c..9b92eb1572 100644 --- a/docs/ensnode.io/src/content/docs/docs/integrate/index.mdx +++ b/docs/ensnode.io/src/content/docs/docs/integrate/index.mdx @@ -18,4 +18,5 @@ This page will be a 60-second quickstart for querying ENSv2 data through ENSNode - Links to [hosted instances](/docs/integrate/hosted-instances) so you can start querying immediately with zero setup. - [ENSv2 Readiness](/docs/integrate/ensv2-readiness) — how building with ENSNode today prepares your app for ENSv2. - [Integration Options](/docs/integrate/integration-options) — choose the right path: enskit, enssdk, raw GraphQL, or ENSDb. +- **Power path (planned):** [ENSDb snapshots & CLI](/docs/integrate/ensdb-snapshots-and-cli) — bootstrap a fresh, nearly-current ENSDb in minutes instead of waiting on a full backfill. diff --git a/docs/ensnode.io/src/content/docs/docs/integrate/integration-options/ensdb.mdx b/docs/ensnode.io/src/content/docs/docs/integrate/integration-options/ensdb.mdx index 9433034474..35a0d9674c 100644 --- a/docs/ensnode.io/src/content/docs/docs/integrate/integration-options/ensdb.mdx +++ b/docs/ensnode.io/src/content/docs/docs/integrate/integration-options/ensdb.mdx @@ -10,6 +10,10 @@ For special use cases that go beyond what the ENS Omnigraph exposes — you can **ENSDb** is an open standard that stores the live onchain **ENSv2** state in a carefully-crafted data model within a PostgreSQL database. Because it's plain Postgres, you can use *any* language with a Postgres driver — **TypeScript**, **Python**, **Rust**, **Go**, and more. +:::tip[Coming soon: snapshots & CLI] +We're building [**ENSDb snapshots & a `ensdb-cli`**](/docs/integrate/ensdb-snapshots-and-cli) so you can pull down a fresh ENSDb in minutes instead of paying for a full historical RPC backfill, diff snapshots across versions to validate indexing changes, and operate ENSNode like a database. **Planned - not shipping yet**, but worth peeking at if your roadmap depends on a fast or cheap ENSDb bootstrap. +::: + :::note[Self-hosting required] ENSDb is available when you [self-host ENSNode](/docs/self-host). Each ENSNode instance writes its data into a PostgreSQL database that you own and control — that database **is** your ENSDb instance. The hosted ENSNode instances do not expose direct database access. ::: diff --git a/docs/ensnode.io/src/content/docs/docs/integrate/webhooks-and-events.mdx b/docs/ensnode.io/src/content/docs/docs/integrate/webhooks-and-events.mdx new file mode 100644 index 0000000000..a0360bffa4 --- /dev/null +++ b/docs/ensnode.io/src/content/docs/docs/integrate/webhooks-and-events.mdx @@ -0,0 +1,108 @@ +--- +title: Webhooks & events +description: Coming soon - ENS-native webhooks that fire when ENS state changes, so apps can stop polling and start reacting. +--- + +import { LinkCard, Aside } from "@astrojs/starlight/components"; + + + +## The problem + +Today, if you want your app to react to ENS state changes, you have two unappealing options: + +- **Poll constantly.** Hammer the GraphQL or RPC every few seconds and discard most responses. Wasteful, slow, and never quite fresh. +- **Build your own indexer.** Stand up infrastructure to listen to chain events, decode them, and turn them into the ENS-level signals you actually care about. Way too much work for what should be a primitive. + +Neither is good. The first is lossy and expensive at scale; the second is a project on its own. + +## What we're building toward + +We're working on an **ENS-native webhooks service** so your app can subscribe to ENS state changes the same way you'd subscribe to a Stripe or GitHub webhook - except the events speak the language of ENS, not the language of raw chain logs. + +Internally we refer to the planned service as **ENSEngine**: it watches your ENSDb for changes and turns them into ENS-aware webhook deliveries to any sink you configure. + +```http +POST https://your-app.example.com/webhooks/ens +Content-Type: application/json + +{ + "type": "domain.transferred", + "name": "vitalik.eth", + "chain": "mainnet", + ... +} +``` + +The shape above is illustrative only. + +## Example events (subject to change) + +The early thinking covers the events most apps actually care about: + +- `domain.registered`, `domain.renewed`, `domain.transferred` +- `resolver.address_changed`, `resolver.text_changed`, `resolver.contenthash_changed` +- `subname.created` + +This list is **not** a committed API surface - it's a sketch of what's in scope. Final event names, payloads, and filter options will land with the service itself. + +## What this unlocks + +The headline use case - and the one we're prioritizing first - is **cache invalidation**. + +### Cache invalidation (priority focus) + +Build aggressive, edge-friendly caches for ENS data. The goal is to make it practical to cache profiles, avatars, text records, and resolver responses for much longer than polling-based integrations allow, then invalidate them when relevant onchain state changes. That's the foundation for web2-grade UX on a web3 protocol - fast page loads, low RPC fanout, globally distributed reads - without giving up freshness as the product matures. + +Where this matters: + +- Frontend apps caching ENS profiles +- CDNs serving ENS-driven content +- API gateways with ENS lookups +- Any service that caches resolver records + +### Adjacent value props (enabled by the same primitive) + +Once a reliable change feed exists, a lot of follow-on patterns get dramatically easier to build *on top of it*. We're not promising these as separate features - they're examples of what the cache-invalidation foundation makes practical: + +- **Notification services** - expiry reminders, watchlists, security alerts on unexpected transfers, registration bots in Discord/Telegram. +- **Database sync** - keep your own app database in step with ENS state, so marketplaces, portfolio trackers, analytics dashboards, and search indices don't drift. +- **Realtime dashboards** - surface registration / renewal / transfer activity as it happens. + +## How it works (high level) + +Reactive webhooks build on the same foundation as the rest of ENSNode: + +1. **[ENSIndexer](/docs/services/ensindexer)** keeps **[ENSDb](/docs/services/ensdb)** up to date with the live, multichain onchain state of ENS - including automatic chain reorg healing. +2. The planned **[ENSEngine](/docs/services/ensengine)** service watches that database for changes and turns them into enriched, filtered, ENS-aware events. +3. Those events get delivered to **your sinks** - webhooks, cache invalidation hooks, database sync targets, notification systems, and more. + +For the architecture overview and code-name notes, see [ENSEngine - How it works](/docs/services/ensengine). + +## What this page is not + +This page is a teaser, not a spec. There's no subscription endpoint to call yet, no signature verification documented, no SDK to integrate against. Those will arrive in dedicated reference docs once the service ships. + +If your app would benefit from any of the use cases above, it's a great time to share what you'd need from this service - we're still shaping it. + +## Related + + + + + + diff --git a/docs/ensnode.io/src/content/docs/docs/reference/roadmap.mdx b/docs/ensnode.io/src/content/docs/docs/reference/roadmap.mdx index 732bda9884..5e1edaab4c 100644 --- a/docs/ensnode.io/src/content/docs/docs/reference/roadmap.mdx +++ b/docs/ensnode.io/src/content/docs/docs/reference/roadmap.mdx @@ -34,6 +34,20 @@ ENSNode could handle CCIP-Read logic internally, batch multiple requests to redu Besides dramatically decreasing latency for client applications, the Protocol Accelerator is also a key step forward in decentralization, away from reliance on centralized offchain gateway servers. This is a big win for the ENS protocol! +## ENSDb CLI & Snapshots + +We're investing in [ENSDb](/docs/services/ensdb) as a first-class integration point - and the next big step is making it trivial *and inexpensive* to **operate** an ENSDb and to **share state** across instances. See the full teaser at [ENSDb snapshots & CLI](/docs/integrate/ensdb-snapshots-and-cli). + +Goals on this roadmap stream include: + +- **Snapshot creation & consumption** - publish a portable, versioned package of an ENSDb instance to a destination like Cloudflare R2, and pull it down to bootstrap a new ENSNode instance in minutes instead of waiting on a full historical backfill. Saves **both time and RPC cost** - consumers don't need to replay history through their own RPC provider to catch up. +- **Snapshot metadata** - record which ENSIndexer config, version, and chains a snapshot was produced from, so consumers can pick the right one and trust it for their use case. +- **Snapshot diffing** - compare snapshots produced before and after an indexing change to confirm the change didn't unexpectedly alter indexed data. A powerful safety net for release reviews. +- **Operational ENSNode CLI** - list indexer instances tracked in an ENSDb, inspect their configuration and indexing status, and clean up schemas that are no longer in use. +- **Snapshot verification (exploratory)** - strategies for letting third parties confirm a snapshot's integrity, such as multi-publisher hash consensus or signed attestations. Open research, not a commitment. + +These capabilities will unlock dramatically faster - and cheaper - iteration for hackathon teams, self-hosters, marketplaces, and anyone building custom services on top of ENSDb. + ## ENS TokenScope: ENS NFT Marketplace Data API With Reservoir shutting down in the coming months, ENSNode aims to provide replacement infrastructure for tokenized ENS name market data. This includes: diff --git a/docs/ensnode.io/src/content/docs/docs/self-host/index.mdx b/docs/ensnode.io/src/content/docs/docs/self-host/index.mdx index 888dbb36c7..d9c6dd2cbb 100644 --- a/docs/ensnode.io/src/content/docs/docs/self-host/index.mdx +++ b/docs/ensnode.io/src/content/docs/docs/self-host/index.mdx @@ -3,7 +3,8 @@ title: Self-host ENSNode description: Decide whether to self-host ENSNode and understand the architecture. --- -import { LinkCard } from "@astrojs/starlight/components"; +import { LinkCard, Aside } from "@astrojs/starlight/components"; +import EnsDbSnapshotsTeaser from "../../../../components/molecules/EnsDbSnapshotsTeaser.astro"; This page will help you decide whether to self-host ENSNode or use the hosted instances. Includes architecture overview of the ENSNode stack (ENSIndexer, ENSDb, ENSRainbow, ENSApi). @@ -23,6 +24,24 @@ Running your own ENSNode instance is helpful for those that wish to: Note that because ENSNode makes many label healing requests to ENSRainbow while indexing, it's _imperative_ that they be on the same local network to minimize request time. ::: +## Faster paths we're building + +Self-hosting today means standing up a fresh ENSNode instance from zero and waiting on an initial backfill - including the RPC bill that comes with it. We're building **[ENSDb snapshots and a `ensdb-cli`](/docs/integrate/ensdb-snapshots-and-cli)** to flatten that ramp. + + + +The headline value props for self-hosters: + + + + + ### Deploying with Docker The Docker deployment option provides the easiest way to run the full ENSNode suite of services both locally and in the cloud. diff --git a/docs/ensnode.io/src/content/docs/docs/services/ensdb/index.mdx b/docs/ensnode.io/src/content/docs/docs/services/ensdb/index.mdx index 91f5b00332..04002cc3bc 100644 --- a/docs/ensnode.io/src/content/docs/docs/services/ensdb/index.mdx +++ b/docs/ensnode.io/src/content/docs/docs/services/ensdb/index.mdx @@ -88,6 +88,12 @@ ENSDb unlocks a new universe of ENS applications: href="/docs/services/ensdb/integrations/ensnode" /> +## What's next + + + ## Related Projects - **[ENSIndexer](/docs/services/ensindexer/)** — The reference [ENSDb Writer](/docs/services/ensdb/concepts/glossary#ensdb-writer) implementation diff --git a/docs/ensnode.io/src/content/docs/docs/services/ensengine/index.mdx b/docs/ensnode.io/src/content/docs/docs/services/ensengine/index.mdx new file mode 100644 index 0000000000..4d0c863cc2 --- /dev/null +++ b/docs/ensnode.io/src/content/docs/docs/services/ensengine/index.mdx @@ -0,0 +1,100 @@ +--- +title: ENSEngine +description: Coming soon - the planned ENSNode service for push-based, reactive ENS functionality. Watches your ENSDb for changes and turns them into ENS-aware webhooks. +sidebar: + label: Overview + order: 1 +--- + +import { LinkCard, Aside } from "@astrojs/starlight/components"; + + + +## Vision + +Make ENS state changes **subscribable**. + +Today, building an app that reacts to ENS - when an avatar changes, when a name is transferred, when a renewal happens - means either polling endlessly or running your own indexer. Both are heavy. ENSEngine exists to remove that work and turn ENS into a push-based protocol from the consumer's point of view: subscribe, get notified, build. + +## What it is + +ENSEngine is the part of ENSNode that **watches your ENSDb for changes in real time and delivers ENS-aware events** - including webhooks - to any sink you configure. + +It's positioned as a separate service alongside [ENSIndexer](/docs/services/ensindexer), [ENSDb](/docs/services/ensdb), [ENSRainbow](/docs/services/ensrainbow), [ENSApi](/docs/services/ensapi), and [ENSAdmin](/docs/services/ensadmin). Once it ships, it'll be the home for reactive / event-based functionality across the ENSNode stack. + +## How it works + +```mermaid +flowchart TD + Indexer["ENSIndexer
(keeps ENSDb up to date)"] + Db["ENSDb
(live onchain state of ENS)"] + subgraph engine [ENSEngine] + Watch["Watches ENSDb for changes"] + Process["Enriches, filters, transforms, routes ENS events"] + Watch --> Process + end + Sinks["Your sinks: webhooks, cache invalidation, notifications, db sync, ..."] + Indexer --> Db + Db --> engine + engine --> Sinks +``` + +In one sentence: **ENSIndexer keeps ENSDb fresh, ENSEngine watches ENSDb for changes and turns them into ENS-aware events for any sink you configure.** + +The internal pipeline is intentionally simple to describe: + +- **Watch** - observe ENSDb in real time as ENSIndexer updates it. +- **Enrich** - attach ENS-level context to raw changes so consumers don't have to. +- **Filter** - apply subscription rules so each sink only sees events it cares about. +- **Transform** - shape events into the right payload for each sink type. +- **Route** - deliver to webhooks, cache-invalidation hooks, database sync targets, notification systems, and more. + +Implementation details behind the watch layer are intentionally not part of this teaser. Those will land in dedicated docs when the service ships. + +## What it unlocks + +The top priority for ENSEngine is **cache invalidation**. The goal is an ENS-native invalidation signal that lets apps and CDNs cache ENS data much more aggressively, then react when relevant onchain state changes. That's the foundation for web2-grade latency on a web3 protocol, especially for high-traffic ENS profile views. + +Adjacent value props enabled by the same primitive (not promised as separate features): + +- **Notification services** - name-expiry reminders, transfer alerts, registration bots in Discord/Telegram. +- **Database sync** - keep your own app's database in step with ENS state for marketplaces, portfolio trackers, analytics dashboards, search indices. +- **Realtime dashboards** - surface activity as it happens, with no polling overhead. + +For a longer use-case-focused overview from the *integrate* perspective, see the [Webhooks & events teaser](/docs/integrate/webhooks-and-events). + +## Position in the ENSNode stack + +ENSEngine is one of several planned and existing services that build on top of [ENSDb](/docs/services/ensdb). ENSDb is the open standard that holds the live, multichain onchain state of ENS in a plain PostgreSQL database. From there, different services consume that state in different ways: + +- **[ENSApi](/docs/services/ensapi)** - pull model: GraphQL / REST APIs for clients. +- **[ENSDb snapshots & CLI](/docs/integrate/ensdb-snapshots-and-cli) (planned)** - operational model: portable snapshots and CLI tooling. +- **ENSEngine (planned)** - push model: real-time, ENS-aware events delivered to your sinks. + +## What this page is not + +This is a teaser, not a spec. There is no subscription endpoint to call yet, no SDK to integrate against, no event payload schema to validate. Delivery guarantees (at-least-once, ordering, retries) are aspirations that haven't been committed to in writing yet. Release timing is not promised. + +If your use case would benefit from ENS-native, real-time events, it's a great moment to share what you'd need - design choices are still flexible. + +## Related + + + + + + diff --git a/docs/ensnode.io/src/content/docs/docs/services/index.mdx b/docs/ensnode.io/src/content/docs/docs/services/index.mdx index 7473ae52cc..2d5028d8e2 100644 --- a/docs/ensnode.io/src/content/docs/docs/services/index.mdx +++ b/docs/ensnode.io/src/content/docs/docs/services/index.mdx @@ -1,6 +1,6 @@ --- title: ENSNode services -description: Introduction to the services that make up the ENSNode stack, including ENSApi, ENSIndexer, ENSDb, ENSRainbow, and ENSAdmin. +description: Introduction to the services that make up the ENSNode stack, including ENSApi, ENSIndexer, ENSDb, ENSRainbow, ENSAdmin, and the planned ENSEngine. sidebar: label: Overview order: 1 @@ -10,7 +10,7 @@ import { LinkCard, CardGrid } from "@astrojs/starlight/components"; **Developing or contributing to ENSNode?** Use these sections for concepts, deployment, configuration, and contribution guides for the part of the stack you care about. -Each ENSNode instance is composed of **a set of services**. Each service has a clear role in indexing, storing the onchain state of ENS, APIs, name healing, or admin operations. +Each ENSNode instance is composed of **a set of services**. Each service has a clear role in indexing, storing the onchain state of ENS, APIs, name healing, admin operations, or reactive event delivery. @@ -18,4 +18,5 @@ Each ENSNode instance is composed of **a set of services**. Each service has a c + From 2d3d4e8848053c8a1baa72c8476517be81a7e5c0 Mon Sep 17 00:00:00 2001 From: djstrong Date: Wed, 13 May 2026 23:11:32 +0200 Subject: [PATCH 02/11] refactor(docs): update ENSDb snapshots and CLI references for clarity - Revised titles and descriptions for the ENSDb snapshots and CLI documentation to enhance clarity and consistency. - Ensured all mentions of the CLI are updated to reflect the new terminology and context. - Improved overall documentation structure by refining related content. --- .../content/docs/docs/integrate/ensdb-snapshots-and-cli.mdx | 4 ++-- .../content/docs/docs/integrate/integration-options/ensdb.mdx | 2 +- docs/ensnode.io/src/content/docs/docs/self-host/index.mdx | 2 +- 3 files changed, 4 insertions(+), 4 deletions(-) diff --git a/docs/ensnode.io/src/content/docs/docs/integrate/ensdb-snapshots-and-cli.mdx b/docs/ensnode.io/src/content/docs/docs/integrate/ensdb-snapshots-and-cli.mdx index 5e4d3136af..bfc3856a0e 100644 --- a/docs/ensnode.io/src/content/docs/docs/integrate/ensdb-snapshots-and-cli.mdx +++ b/docs/ensnode.io/src/content/docs/docs/integrate/ensdb-snapshots-and-cli.mdx @@ -65,8 +65,8 @@ In the meantime, the goals above are stable enough to plan around. If your proje /> diff --git a/docs/ensnode.io/src/content/docs/docs/integrate/integration-options/ensdb.mdx b/docs/ensnode.io/src/content/docs/docs/integrate/integration-options/ensdb.mdx index 35a0d9674c..b738ed4239 100644 --- a/docs/ensnode.io/src/content/docs/docs/integrate/integration-options/ensdb.mdx +++ b/docs/ensnode.io/src/content/docs/docs/integrate/integration-options/ensdb.mdx @@ -11,7 +11,7 @@ For special use cases that go beyond what the ENS Omnigraph exposes — you can **ENSDb** is an open standard that stores the live onchain **ENSv2** state in a carefully-crafted data model within a PostgreSQL database. Because it's plain Postgres, you can use *any* language with a Postgres driver — **TypeScript**, **Python**, **Rust**, **Go**, and more. :::tip[Coming soon: snapshots & CLI] -We're building [**ENSDb snapshots & a `ensdb-cli`**](/docs/integrate/ensdb-snapshots-and-cli) so you can pull down a fresh ENSDb in minutes instead of paying for a full historical RPC backfill, diff snapshots across versions to validate indexing changes, and operate ENSNode like a database. **Planned - not shipping yet**, but worth peeking at if your roadmap depends on a fast or cheap ENSDb bootstrap. +We're building [**ENSDb snapshots & an `ensdb-cli`**](/docs/integrate/ensdb-snapshots-and-cli) so you can pull down a fresh ENSDb in minutes instead of paying for a full historical RPC backfill, diff snapshots across versions to validate indexing changes, and operate ENSNode like a database. **Planned - not shipping yet**, but worth peeking at if your roadmap depends on a fast or cheap ENSDb bootstrap. ::: :::note[Self-hosting required] diff --git a/docs/ensnode.io/src/content/docs/docs/self-host/index.mdx b/docs/ensnode.io/src/content/docs/docs/self-host/index.mdx index d9c6dd2cbb..39e44de007 100644 --- a/docs/ensnode.io/src/content/docs/docs/self-host/index.mdx +++ b/docs/ensnode.io/src/content/docs/docs/self-host/index.mdx @@ -26,7 +26,7 @@ Note that because ENSNode makes many label healing requests to ENSRainbow while ## Faster paths we're building -Self-hosting today means standing up a fresh ENSNode instance from zero and waiting on an initial backfill - including the RPC bill that comes with it. We're building **[ENSDb snapshots and a `ensdb-cli`](/docs/integrate/ensdb-snapshots-and-cli)** to flatten that ramp. +Self-hosting today means standing up a fresh ENSNode instance from zero and waiting on an initial backfill - including the RPC bill that comes with it. We're building **[ENSDb snapshots and an `ensdb-cli`](/docs/integrate/ensdb-snapshots-and-cli)** to flatten that ramp.