Seaport Sales Plugin

[Zimtente]

Official deliverable description:

Ship support for name sales history.

Index all seaport sales for the supported contracts

[lightwalker-eth]

@Zimtente Thanks for creating this issue 👍

A few suggestions:

1. For creating a new plugin, suggest taking inspiration from the work that @tk-o is advancing for introducing a new EFP plugin in PR 771.
2. I'm not sure if we should call this plugin "seaport" or "tokenscope". It's a bit difficult to say for sure until we get further into this effort. Happy to proceed with "seaport" for now and we can see how it goes as we build it up 👍 We can always rename later depending on what we learn.
3. As I understand, this plugin will index all seaport sales events across all NFTs and then within our indexing event handler we will filter which NFT contracts we will store sales data for in our database. To determine those contract addresses, it would be nice to reference these addresses indirectly through the definitions inside our datasources package. Related examples of indirectly getting chainId or address constants from the data models we're defining in this datasources package:
   1. https://github.com/namehash/ensnode/blob/main/packages/datasources/src/index.ts#L51-L52
   2. Please see the changes in progress for packages/datasources/src/index.ts in PR 812.
   3. Please note the pattern we're using of passing in an ENSNamespaceId (such as "mainnet" or "sepolia" or "ens-test-env") to get the specific constants that are relevant for the context.
4. Overall don't suggest getting stuck on any complexity the above suggestions might create. Feel welcome to "just make it work" first and we can always make it more fancy as another iteration 👍

[Zimtente]

A few questions and feedback:

1. As Seaport relies on other plugins to index names (ENS, 3DNS etc) what would the best approach to handle this, as atm it is possible to enable and disable certain plugins. If we do not enable 3DNS we should potentially also not index Seaport sales for 3DNS. As @lightwalker-eth said we need a way to filter by "Contract" as the Seaport OrderFulfilled Event indexes any NFT sale that happens on Seaport.
2. As for seaport datasource https://github.com/namehash/ensnode/blob/main/packages/datasources/src/mainnet.ts does it make sense that we put it into the "ENSNamespace" ?
   [DatasourceNames.Seaport]: { chain: mainnet, contracts: { Seaport: { abi: Seaport, address: "0x00000000000000ADc04C56Bf30aC9d3c0aAF14dC", startBlock: 17129405, }, }, }
3. As for Seaport as well - there are different Version we may look into. Atm my plan is to start with Version 1.6 but down the line we may have to think about a way to support older/newer versions as well.
4. Naming may be important if there is a need in the future to support other NFT marketplace protocols outisde of seaport. though may be not so important atm

[lightwalker-eth]

@Zimtente Great questions 😄

1. Our current strategy for managing dependencies between plugin activations is managed in the building of an ENSIndexerConfig. When ENSIndexer starts up, one of the first things that happens is an ENSIndexerConfig is built. Our strategy is to enforce that it's impossible to create an ENSIndexerConfig with an invalid state. This way, all our code that reads an ENSIndexerConfig can do so with full confidence that all validations and invariants are already guaranteed and no further validation logic is required to spread all over our code. If anything is invalid, ENSIndexer refuses to start indexing and we do our best to give helpful error messages to the ENSIndexer operator to help them fix the configuration issue. Here's a list of some suggested things to have a look at:
   1. Code related to building and validating an ENSIndexerConfig.
   2. Suggest checking out Matt's work in progress on PR 747, specifically the following files on that PR where he's adding enforcement of a dependency between plugin activations:
      1. apps/ensindexer/src/config/config.schema.ts
      2. apps/ensindexer/src/config/validations.ts
2. Yes. We should define a Datasource for Seaport. You can define a Seaport Datasource for the relevant ENSNamespaces. Ex: I'm sure it exists on mainnet and likely also on sepolia too. Not sure of Holesky? It certainly wouldn't exist in the ens-test-env.
3. Good point! It will be helpful if you could include a list of future action items to consider as a comment in the seaport plugin 👍 Let's do whatever is simple on this for now and come back to more advanced logic as a future step.
4. Appreciate your advice on this! Thanks!