Making my own kind of resolver

🧑‍💻 ENS Development
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.