Getting ens-app to work for a fork of ENS on Handshake

#1

Hello I have set up and deployed a fork of ENS for my Handshake TLD (.badass), you can see here: 0x36fc69f0983E536D1787cC83f481581f22CCA2A1

I also set up an ETHRegistrar and have successfully registered a few subdomains under this TLD. For example see certified.badass registration here: https://etherscan.io/tx/0x41c57394b1740bb8863c9711e65ba369865344cd3096ecdddd6e8a9e6e36888b#eventlog

I would like to set up a fork of ens-app so that others can more easily register and manage their domains. I understand I have to set up a subgraph and change the settings in src/apolloClient.js, but any pointers as to the other parameters to change in order to get this to work would be helpful. I am also willing to pay for this help

For example, besides a lot of hard-coded .eth references, there are also hard-coded contract address, for example here:

etc…

I believe that ENS + Handshake will have a lot of future collaboration and mutual benefit working together, so I am eager and excited to get started!

Thank you

#2

Interesting experimentation! though aren’t you be the source of trust to manually assign tld to mirror handshake? How do you keep syncing .badass subdomain which made in handshake and in this ENS fork?

In terms of hacking ens frontend, in addition to replacing any hardcoded contract address, you have to allow any tld to be listed which I did it in this branch as part of prepping for dns integration.

I am in the mindset of anything gets forkable will be forkable so don’t have issue you trying but if you are going to promote this to handshake community, I suggest you state explicitly that they have to trust you to sync handshake name state into your ENS fork (if I understand your implementation correctly).

#3

awesome, thank you very much for your help! I will check this out

I will not be source of trust because it is only for my .badass TLD. I will send the contract to a burn address so no one will own the keys to it and it can be completely trustless.

If anyone else wants to use this for their own Handshake TLD, I plan to write an article and open source all the steps I have taken so they can also do the same.

#4

you set registrar of .badass into ethregistrar meaning anyone can buy your subdomain by paying fee to you. How does the ENS clone subdomain ownership will be in sync with the subdomain on handshake which (I guess) you will also sell ?

#5

subdomain ownership will only be on the ENS clone. The name data on the ‘badass’ Handshake name will be set to, for example:

{
  "records": [{
    "type": "NS",
    "ns": "0x36fc69f0983E536D1787cC83f481581f22CCA2A1._eth."
  }]
}

This can then be resolveable with a plugin to hsd, which will query the data on the ENS subdomain and resolve the subdomain from this data.

Then we will lock the Handshake name forever with this script:

OPTYPE
0x08 // RENEW
OPEQUALVERIFY

this will make the Handshake name unchangeable by anyone, but renewable by anyone. So it will be completely trustless subdomains via the ENS clone, on a completely trustless root zone (Handshake).

#6

Thanks for the explanation though I am a bit lost as I don’t know much about handshake nor bitcoin.

I understand the latter half of how you can lock name ownership forever but renewable by anyone (similar to how you can do with ENS), but didn’t quite understand the name data bit.

#7

Handshake just supports the root zone, so .badass (the TLD) is decentralized and owned on Handshake. You can set name servers and other data on the name and this goes on the Handshake blockchain. We will set the data on the name to refer to our ENS contract that we have deployed for .badass, so all subdomains for .badass will be resolved through the ENS fork we have deployed for .badass

When I change this line in our ens-app/node_modules/@ensdomains/ui/src/ens.js file: to use our ENS contract address instead of the one in the file, I am getting this error:

contract not deployed (contractAddress=“0x0000000000000000000000000000000000000000”, operation=“getDeployed”, version=4.0.44)

Do you have an idea of what may cause this?

#8

The error indicates that you tried to instantiate a smart contract (registry, registrar, resolver or anything) passing null contract address (hence 0x0000). It happens at various places so hard to pinpoint by looking at the error.

#9

thank you. I think it would be helpful and make ens-app much more robust if there were a list of all of the hard-coded contract addresses and ‘.eth’ references, so that anyone who wants to use this for anything other than the current implementation of ENS will be able to use it. I’m working on it now for the purposes of integrating with Handshake, but I think others would find it useful. For example you can see others have also asked this before: Set up ENS Manager with ENS on private chain

Any help you or anyone else can provide would be great

#10

Please refer to https://github.com/ensdomains/ens-app#end-to-end-testing for deploying to a private chain which doesn’t depend on hard-coded registry addresses.

#11

Hey @makoto so we have our whole system setup including the ens-app. The only thing not working is registering through the app UI (we can do it through etherscan).

We can call the commit function but when the commitment time has elapsed, when we click register we get this error from the apollo client:

Uncaught (in promise) Error: Network error: execution reverted
    at new t (ApolloError.ts:57)
    at Object.error (QueryManager.ts:256)
    at v (Observable.js:140)
    at w (Observable.js:179)
    at e.value (Observable.js:240)
    at observables.ts:15
    at Set.forEach (<anonymous>)
    at Object.error (observables.ts:15)
    at v (Observable.js:140)
    at w (Observable.js:179)

For the life of me I can’t figure out whats causing this since the register mutation is using the same @client modifier and everything as the commit mutation that just worked. There is no indication as to what is actually causing the error either. The whole app including registering new domains works fine on my local setup, its only when we deploy that it stops working.

Have you come across this error before or do you have any idea where it’s coming from?

You can test it out on https://badassdev.surge.sh/ if you want

Unrelated but I’ve made a few changes to ens-app and ui packages (maybe 100 lines changed in total) to make them more configurable and allow multiple tlds to be sold through the app. Do you guys want me to make a PR?

#12

The only thing I can think of is that your local deployment and public net deployment is somewhat different.

The error is standard revert error so can be caused by many different reasons.

allow multiple tlds to be sold through the app

Thanks for the offer but I don’t think we need this feature.

#13

Ok thanks for the help. It’s an Apollo error though not a smart contract error right? I don’t have any outbound register txs from my wallet, only commits

#14

Do you have deployment in testnet? I wouldn’t want to pay high gas on mainnet just to test even for step 1

#15

no testnet, just test in prod haha. Gas isn’t much of an issue.