Add Reverse Record to Account query

[ChaituVR]

Right now Account only returns

id: ID!
domains: [Domain!]!
registrations: [Registration!]

it would be helpful to add a reverse record to the schema

[scottrepreneur]

#26

[Arachnid]

@scottrepreneur Thanks for the contribution!

The ReverseRegistration event isn't a 100% reliable way to detect what name an address has set as its reverse record, though, as a user can set their reverse record to a custom resolver and change the name that way. A better way would probably be to add a resolvedName field to the Domain type in the same manner as resolvedAddress, and then you can look up reverse records in the subgraph by querying the namehash of <address>.addr.reverse and getting its resolvedAddress.

Two caveats for this approach, though:

• You must also do a forward resolution on that address in order to check that it resolves to the same name. Anyone can claim their address reverse-resolves to a particular name; you shouldn't accept that assertion unless you've verified the name also points at their address.
• Looking up the reverse record via events like this cannot be 100% reliable, as users may write custom resolvers that have custom logic for updating the records, meaning that an event may not be emitted for every change.

[fafrd]

I came looking for the exact same thing- I ended up creating my own API to do this.

You can host it yourself using Cloudflare: https://github.com/fafrd/ens-reverse-lookup

[kasparkallas]

@Arachnid What happened to your suggestion? Seemed like a good proposal.

I have an app with list views full of addresses and I need to get the primary ENS names in one or two round-trips. I don't want to spam the RPC-s so I figured that I could do one batched call with Subgraph... but that does not seem to be the case if I understand this issue correctly. What is the recommended way to approach this situation -- handwrite a multicall implementation?

[ivelin]

I came looking for the exact same thing- I ended up creating my own API to do this.

You can host it yourself using Cloudflare: https://github.com/fafrd/ens-reverse-lookup

This looks like the correct solution for reverse ENS lookup that can be added to the official ENS subgraph.

@fafrd have you tried pushing a PR to this repo with your work?

[fafrd]

@ivelin I don't think I have the bandwidth to write and test the subgraph change at the moment.

If anyone is looking to solve this issue, they should follow the instructions in Arachnid's comment above.

Alternatively, it's possible to get this data directly on-chain: call the function getNames() from contract 0x3671aE578E63FdF66ad4F3E12CC0c0d71Ac7510C. You should be aware though that users can 'fake' reverse resolution, so you must also do a forward-resolution to ensure correctness.

[ivelin]

@ivelin I don't think I have the bandwidth to write and test the subgraph change at the moment.

If anyone is looking to solve this issue, they should follow the instructions in Arachnid's comment above.

Alternatively, it's possible to get this data directly on-chain: call the function getNames() from contract 0x3671aE578E63FdF66ad4F3E12CC0c0d71Ac7510C. You should be aware though that users can 'fake' reverse resolution, so you must also do a forward-resolution to ensure correctness.

Thank you for commenting. We are using the ethers js RPC option for now. It is not optimal because it makes unnecessary RPC calls to a read-mostly data structure. Would be good to see this function in the ENS subgraph at some point. I will add to my backlog.