Use reverse resolution to fetch main ENS name from address

[santteegt]

GitHub Issue

Fixes #186

Changes

Apparently, it's no that easy to identify the main ENS name from an address using the subgraph. Going through the ENS docs, I find out how it uses Reverse Resolution using a special purpose domain to set the primary ENS name a.k.a main reverse record. The recommended approach is to use an etherjs provider and call lookupAddress, otherwise seems that we need to manually concatenate .${address}.addr.reverse, namehash it and look for the resolver in the subgraph.

I used the recommended approach to fetch the main ENS record. If not found, it fallbacks to query the subgraph for the first non-expired ens domain registered by an account address.

Packages Added

None

Checks

Before making your PR, please check the following:

• Critical lint errors are resolved
• App runs locally
• App builds locally (run the build command for any impacted package and check for any errors before the PR)

[santteegt]

Tasks done: explore subgraph queries that allow us to identify the main ENS record from an address. Ended up implementing reverse resolution using etherjs
Time spent: 3 hours

[skuhlmann]

@santteegt Is there no way to get this from the subgraph?

I was really hoping to avoid dependency on the rpc provider. You're importing HAUS_RPC for that - which is fine for mos of our apps - but what if someone is using this package outside of daohaus connect they will need a way to pass the provider/rivet key.

[skuhlmann]

If there is no way to use the subgraph, maybe this function should take a provider url as an argument. our apps can pass it from HAUS_RPC. But then others can use it and pass their own.

[santteegt]

After digging a little bit more into how to get the same data from the subgraph, I found this in the docs:

...
Listing all primary names
...
...
TheGraph = subgraph currently does not index primary name info ([github issue](https://github.com/ensdomains/ens-subgraph/issues/25))
...
...

Going through the issues I found the following here:

The new reverse registrar, currently deployed on testnets,
will support emitting the appropriate events - so we will need to 
write support for that rather than doing transaction tracing like this.

It looks like this is still WIP.

On the other hand, I also found a PR that Bryan pushed for DAOHaus V2 however it also relies on an RPC endpoint.

Until there's primary ens domain data indexed by the subgraph, I think it's better to use etherjs library instead of our own implementation so I'm going to go with the second approach to update my PR: passing the RPC to the profile function. @skuhlmann now my question is, which one is better to pass over: the RPC URI or the etherjs provider instance?

[skuhlmann]

@santteegt

Cool. I'd say pass the provider url and set up ethers in the function.

[o-az]

You can call the reverse resolution directly through a fetch call w/o needing ethers