Making my own kind of resolver

🧑‍💻 ENS Development
1

Not sure if resolver is the right word here, but hear me out.
Could I somehow make my own logic for reverse resolution, in order to create a type of index of particular subnames, for referencing smart contracts, in order to keep track of them, and organize them by project.
Of course this reverse resolution would have to be implemented by whichever front-end you want it to work on.

I know that uniswap has already set up subnames for all of their contracts already (if I recall correctly), but most projects of course have not.

So for example, a small part of the scope of my project might include a custom index mapping to my subdomains, where I (or someone) maps out subdomains to each contract under another subdomain of the project.
Eg:
v1.arb.aave.mysubname.eth
v1.op.aave.mysubname.eth
v2.arb.aave.mysubname.eth
v2.op.aave.mysubname.eth

Through creating this type of reverse resolution, web3 projects that add my resolver would be able to automatically and credibly-neutrally reverse-resolve contracts and display them as they please, for readability and indexing purposes.

What do you think? does it seem practical or even useful?
Curious to hear thoughts, its just an idea at this stage that needs some fleshing out :slight_smile:

1 Like
2

Are you sure you’re talking about reverse resolution here? Reverse resolution is resolving an address to a name, not the other way around.

“Setting up subnames for contracts” does not necessarily require reverse resolution, only regular forward-resolution. Though it may be helpful to also have those contracts reverse-resolve to their respective names.

When you claim the reverse node for an account, you can use any resolver you want, it doesn’t need to be the default public resolver. So yes, you can create your own resolver and set that on your reverse node.

Anyone who wants their contract to reverse-resolve to a name still needs to claim that reverse node via the Reverse Registrar first (if they can, if the contract has been written to allow that). When calling setName or setNameForAddr, their account will automatically reverse-resolve to whatever name they set.

1 Like
3

TOR + TOG can enable this, the only question is where do you want to put your data.

Note: until we have gateways, unless you operate your own offchain server, there’s no general solution for untrusted, non-self-hosted offchain data. You can put pre-signed data on a static server, but then you have invalidation issues.

TOR makes it so you don’t have to deploy anything: just point your ENS name’s resolver to the TOR, and point the TOR to your TOG (or ezccip). Or you can use https://ccip.tools and the official offchain-resolver and build your own storage solution.

TOG is a technical demo of various ways (called routers) you can store data offchain: pull from various websites, databases, use github, airtable, hierarchical json, static json, NFTs on other chains, etc.

One of demo routers is called tree. It is very simple to understand: it dynamically reloads tree.json on change, and interprets the file as namespace in an ENS-friendly JSON notation (called enson), and makes it available to the TOR.

tree.tog.raffy.eth resolves to the root of the tree.

Note: tree.tog.raffy.eth is just where I’m hosting this demo from, you can serve these features from any ENS or DNS name.

I added the following to my tree.json

"sat": {
	"aave": {
		"arb": {
			"v1": {
				"$eth": "0x0000000000000000000000000000000000000001"
			},
			"v2": {
				"$eth": "0x0000000000000000000000000000000000000002"
			}
		},
		"op": {
			"v1": {
				"$eth": "0x0000000000000000000000000000000000000003"
			},
			"v2": {
				"$eth": "0x0000000000000000000000000000000000000004"
			}
		}
	}
}

For example, v1.arb.aave.sat.tree.tog.raffy.eth now has addr(60) of 0x00...01

Since the tree is fully static, the tree router can offer other features. One of the features, controlled by "reverse": "addr.reverse" in tree.json, enables automatic reverse indexing.

For example, 0000000000000000000000000000000000000002.addr.reverse.tree.tog.raffy.eth will resolve to a copy first record with addr(60) that matches. This record has a name() equal to v2.arb.aave.sat but no resolvers show that by default. The above link has some extra logic for showing the NameResolver profile data.

Upon successful parse, TOG exposes this information via GET — give me the tree format of the “tree” router.

Another feature, controlled by "index": { "label": "_", "limit": 100 } in tree.json, enables automatic indexing under any name prefixed with label. For example, _.addr.reverse.tree.tog.raffy.eth will list all of the addr(60)'s that are reverseable in text(description).

For reverse addresses of this type to be useful, you’d need some custom application that reverses using your suffix (addr.reverse.tree.tog.raffy.eth in this example) rather than the default addr.reverse.

A personal address book hosted under your own name is a good example.

TOG offers a few other related routers, however they don’t support reverse lookup since they’re dynamic and just a demo (but they could). And unless you host it yourself, you’re trusting my TOG is faithfully relaying the information.

Like tree router, both of these support arbitrary records at arbitrary depth.