WIP Event Support

README.md

@@ -2,9 +2,9 @@
 
 > powered by ponder
 
-estimated backfill time @ 50rps = 24-36 hours on M1 Macbook (~10x speedup)
+estimated mainnet backfill time @ <=500rps = ~12 hours on M1 Macbook (~14x-28x speedup vs subgraph)
 
-### goals
+## goals
 
 > an optimized, multichain ens indexer that the community loves and integrates
 
@@ -23,26 +23,26 @@ estimated backfill time @ 50rps = 24-36 hours on M1 Macbook (~10x speedup)
   - (possible) continued backwards compatibility with subgraph
   - support indexing subset of data, i.e. only domains under parent node
 
-#### next up
+## next up
 
+- [ ] implement events
+- [ ] implement polymorphic events resolver on each relevant entity
+- [ ] `_nocase` case-insensitive where filters
+  - not used interally but ensjs does technically expose this as an available filter to users
 - [ ] confirm all the schema relations are configured correctly
 - [ ] integrate rainbow tables for label healing
   - load the table dump into pglite (or just postgres) & query synchronously to match existing behavior
   - https://github.com/graphprotocol/ens-rainbow
-- [ ] subgraph graphql implementation within ponder
-  - [ ] implement subgraph-style pagination api
-  - [ ] support the well-known queries in `GRAPHQL.md`
-  - [ ] support collection queries as well, to power `snapshot-eq`
 - [ ] CI/CD with indexing?
-  - more recent endlbock for gut checks
+  - integrate index to recent block (10m?) and validate with `snapshot-eq` b4 passing
 - [ ] better understand reverse resolution & how that pertains to L2 primary names and impacts the future schema, etc
 
-### notes
+## notes
 
 - eth registry is ERC721, has many controllers (), no knowledge of pricing — delegated to registrar controllers
 - eth old registry & new registry migration due to security issue, new then fallback to old, therefore ignore all old evens on domains that have been seen by new registry
 
-### ENSIP Ideas
+## ENSIP Ideas
 
 - unable to automatically identify subname registries via onchain event, CCIP standard dosn't include any info about data source, so we'll need to encode manually for now
 - ENSIP - shared interface for subdomain registrars

docs/GRAPHQL.md

@@ -1,5 +1,13 @@
 # graphql info/spec
 
+## backwards-compatibility notes
+
+the following features of the subgraph graphql api are explicitly unsupported, because they are not used by ensjs or ens-app-v3
+
+- [fulltext search queries](https://thegraph.com/docs/en/subgraphs/querying/graphql-api/#fulltext-search-queries)
+- 1-level-nested Entity `_orderBy` param
+- subgraph `_Meta_` object (ponder's `_meta` is available)
+
 ## goals
 
 1. ponder indexer 1:1 equivalency of results as compared to subgraph

docs/V2.md

@@ -41,6 +41,8 @@ the 'empty' domains should be handled more accurately, depending on how importan
   - removes need to increment during domain creation
   - new impl likely needs to exclude 'empty' domains (see registry notes for context)
 
+domain createdAt should not update on re-registration, should be original createdAt
+
 various resources use both null and zeroAddress to indicate emptiness, this is horrible and creates numerous checks like [this](https://github.com/ensdomains/ensjs/blob/main/packages/ensjs/src/functions/subgraph/getNamesForAddress.ts#L255) where they check for `!== NULL && !== zeroAddress`
 
 wrappedOwnerId should not be materialized onto domain, should just be resolved through wrappedDomain.owner
@@ -75,6 +77,8 @@ any resolver that implements the CCIP Read standard will have to have its record
 
 in the subgraph implementation, resolver handlers must upsert resolvers because people can set records etc for a node that has not (yet) specified this resolver as active, meaning the create in `Registry:NewResolver` has yet to fire. in the ideal scenario, this lookup is keyed only by `(chainId, address)` and we can use pure updates instead of an upsert
 
+v1: resolvers are discovered by tracking all emissions of events that look like resolver spec events. very inefficient, as a resolver is only relevant to the protocol once it's been set as a resolver. for v2, we could use factory like normal, starting to track events on `Registry#NewResolver` and then backfilling the events (using the same handlers) with ponder's cached viem client. not sure if this is more or less intensive than just parsing every event ever
+
 ### registrar
 
 the subgraph implements all of the BaseRegistrar, EthRegistrarController, and EthRegistrarControllerOld logic together

package.json

@@ -1,5 +1,5 @@
 {
-  "name": "ens-multichain",
+  "name": "ensnode",
   "version": "0.0.1",
   "private": true,
   "type": "module",
@@ -13,8 +13,17 @@
   },
   "dependencies": {
     "@ensdomains/ensjs": "^4.0.2",
+    "@escape.tech/graphql-armor-max-aliases": "^2.6.0",
+    "@escape.tech/graphql-armor-max-depth": "^2.4.0",
+    "@escape.tech/graphql-armor-max-tokens": "^2.5.0",
+    "change-case": "^5.4.4",
+    "dataloader": "^2.2.3",
+    "drizzle-orm": "^0.38.3",
+    "graphql": "^16.10.0",
+    "graphql-scalars": "^1.24.0",
+    "graphql-yoga": "^5.10.9",
     "hono": "^4.6.14",
-    "ponder": "^0.8.17",
+    "ponder": "^0.8.24",
     "viem": "^2.21.57"
   },
   "devDependencies": {