Refine the OwnedName concept

[lightwalker-eth]

The goal for this issue is to explore enhancements to OwnedName. It will help to review the current idea of OwnedName to make it more precise everywhere it is referenced.

Writing this issue while reviewing #82

1. Was there a special reason an OwnedName must end with "eth"?
2. It seems we're currently mixing several ideas together here that should be separated:
   1. The identifier we use to name a plugin, such that we can say we want plugin X or Y to be activated.
   2. The set of names a plugin might potentially index any data about.
   3. The set of names a plugin might index "Registration" records for.

For example, please consider the following:

• the eth plugin indexes more than subnames of ".eth". It can index essentially any ENS name via the NameWrapper (and underlying Registry).
  • NOTE: This also includes subnames of addr.reverse.
  • the eth plugin only indexes "Registration" records for a single registrar: the BaseRegistrar for direct subnames of .eth.
• the base.eth plugin indexes:
  • "Registration" records for a single registrar: the "BaseRegistrar" implementation for direct subnames of base.eth on Base.
  • any subname (at any level of subname issuance) for subnames of base.eth on Base. Note how this is different than the point shared above. For example: consider a name such as abc.123.base.eth. As I understand this name could be indexed by our base.eth plugin but it would not include a "Registration" record.
• Our future roadmap includes more plugins:
  • A plugin for indexing all 3DNS names that live on Optimism. We might want to call that the "3dns.box" plugin. This plugin will have the ability to index pretty much any DNS name (noting how DNS is a subset of ENS).
  • Our upcoming plans for a NameStone plugin for names they manage offchain. We might want to call that the "namestone.com" plugin. This plugin will have the ability to index a number of names under completely different domains. For example: offchain subnames of abc.com or xyz.box, etc.
  • We should assume more examples like these are coming.

A few quick ideas:

• Perhaps we should stop naming plugins with ENS names. This creates too much opportunity for confusion. We might rename our plugins as follows:
  • "eth" -> "subgraph"
  • "base.eth" -> "basenames"
  • "linea.eth" -> "lineanames"
• We might create a more expressive data model for plugins that would include fields for:
  • The "root" name that they are permitted to index data for.
    • For the "eth" plugin this would be "" (this empty string represents the overall ENS root of all ENS names -- check how the namehash function handles it. Ex: returns an all zero hex value representing the ENS root node.).
    • For the "base.eth" plugin this would be "base.eth".
      • Is this really true? For example, does the "base.eth" plugin ever index data for subnames of "addr.reverse"?
    • Etc.. for the "linea.eth" plugin.
  • An oversimplification for the immediate moment, where we assume that each plugin indexes "Registration" events for exactly one Registrar and only direct subnames of that Registrar. Given that oversimplification, an "indexedRegistrar" field might be used to identify the name of this one Registrar for each plugin. We will need a more expressive solution for this that doesn't make such a big oversimplification. Open to solving that as part of this issue or creating a separate issue for it.
    • For the "eth" plugin this would be "eth"
    • For the "base.eth" plugin this would be "base.eth"
    • For the "linea.eth" plugin this would be "linea.eth".
• We might add some enforcement logic for Shadow Registries (in base.eth and linea.eth plugins), such that we verify enforcement of the scope of names written to those Shadow Registries matches what we expect. Ex: the base.eth plugin never writes to its Shadow Registry for any name that isn't a subname of base.eth. Etc.