Idea: Integrating POKT with Handshake Domains (HNS) and Opera

Hello,

I am new to this project but I recently thought of an idea that could seriously help POKT get wide adoption easily and also benefit users.

First, if no one is aware, opera had partnered with the dWeb foundation https://www.decentralizedinter.net to do an integration of HNS into the browser. This means an instant 4-5 million users (I believe).

Second, HNS has a proposal at HIPs/HIP-0005.md at 1f9a8bae83286be39c627a937cd15f20d1de00ac · handshake-org/HIPs · GitHub that, enables delegating domain queries to ENS-compatible registries. An implementation is here fingertip/ethereum_resolver.go at da10c26665a48a0846b16108679530739229c96c · imperviousinc/fingertip · GitHub fingertip/hip5.go at da10c26665a48a0846b16108679530739229c96c · imperviousinc/fingertip · GitHub.

I see 2 problems here:

  1. You should not need a plugin per network registering an arbitrary “handle” to intercept the request.
  2. You want to ensure you are using a decentralized EVM node.

  1. is solved by integrating POKT as a query network to return a node, and then connecting to it. You would, in theory, just create a TXT record of a defined syntax, and have it be parsed. This would require only a single “plugin” to do this work.
  2. By doing this you don’t use Infura or any other cloud EVM provider.

Now the catch that exists is chatter I have read is stating opera is likely using HNSD GitHub - handshake-org/hnsd: Handshake SPV name resolver which makes sense as it’s a small, lightweight client, but written in C.

So the idea and question is how to integrate with this project since POKT core is GoLang and POKT has a client in JS? There are language barriers here. Additionally how to get involved in the opera integration so that decentralized nodes can be used as an effect of a single EVM delegation support.

A fast and simpler route is probably integrating with fingertip, but I see that as for advanced users and geeks, not average users learning “out of the box”.

Would love feedback on this to see how this can be made a reality since this can solve all the domain registry competition by allowing HNS to be the authority, and supporting simple domain registrations on something like Polygon, XDai, Cosmos, or Arbitrum with delegation. It ALSO solves the need for hosted DNS servers like AWS for HNS domains.

Thanks!

4 Likes

I feel like this might be the first use case / request for PEP-19: The Development of PocketRS, Ongoing Client Support, and Feature-Rich Documentation - #7 by shane, as OP insinuates that a C-interface is needed (cc @Mike_JAMSO_NodeFolio)

Am I reading this the right way?

That assumes opera uses HNSD which is a small client.

How is there a language barrier if we are replacing Infura or other EVM providers? Infura and other providers provide endpoints, similar to our Portal Endpoints, and they can work with any language.

To do an integration, all we would need is a dedicated endpoint for each chain. If they are currently using another provider like Infura, we would be hot-swappable.

If that’s the case, its very doable, so I’m not seeing how there are any barriers at all. Trying to do an SDK integration with Pocket right now isn’t really advised until v1 when many of the QoS features of the Portal will come on-chain, so a Portal integration seems perfect.

Love the idea and props for starting this discussion!

1 Like

How is there a language barrier if we are replacing Infura or other EVM providers?

Because we don’t want to rely on any centralized hostname to do this. Using pokt hosted gateways is no better than infura. You are switching from one cloud provider to another. This means native protocol integration. HNSD is in C. that’s the barrier.

Fingertip is in golang, so that’s much easier if the client library code can be imported and linked.

2 Likes

Yeah, I get that, but that level of decentralization will likely need Pocket v1. To do an integration today, the Portal would need to be the way to go as a starter. As POKT decentralizes from hostnames completely (likely with v1) then the next phase of integration would be on the SDK level.

That’s my take at least :slightly_smiling_face:

To do an integration today, the Portal would need to be the way to go as a starter

Which partially defeats the purpose as the intention is to discover nodes based on a network name and not hard code any domain scheme to query.

As POKT decentralizes from hostnames completely (likely with v1) then the next phase of integration would be on the SDK level.

Any ETA that can be referenced? :smiley:

Yeah, Pocket via an SDK would be an amazing solution for this. It really is the missing link to fully decentralized DNS.

Some info has been talked about in community calls. Full info is to be released soon from my understanding.

Can you please explain this proposal in layman’s terms. Does this tie in with ens domains, unstoppable domains and/or ICANN domains? If so, how?

1 Like

It ties in with any domain registry system in the big picture on a blockchain, but in this, can be any EVM-based chain. The HIP 5 proposal effectively allows plugins to existing to delegate domains (aka TLD) to other blockchains to use their contracts, enabling cross-chain interoperability. By doing this also means you can enable simple registering for domains in how ICANN currently works vs the HNS auction system.

POKT comes into play by being a decentralized glue piece between HNS and finding an RPC node for any requested chain.

1 Like

Almost layman’s terms. Can you give an example of how this would work? Not layman’s terms, but in a way that your grandmother would understand.

So the HNS auction method of domain name acquisition would be replaced by simple domain name purchase?

So the HNS auction method of domain name acquisition would be replaced by simple domain name purchase?

no. HNS sells off things like .com and .shop if it were ICANN and traditionally you lease ownership of mysite.com. The intention is to bring this simplicity back into web3 from web2, be it where a registrar acts like unstoppable domains and sells for life, or a yearly fee.

The broad idea is as an advanced user you can buy an HNS domain in an auction. You can then delegate that to a contract chain of which would be a registrar. That can be set up by you or by someone else.

That registrar/registry can then serve records for just your name or could sell/give away/anything else domain space on the .com/.shop. This is effectively how things like godaddy.com work with ICANN at $10 a year.

POKT comes into play as the glue piece here to give the HNS “resolver” a network to query to get the needed information.

Feel free to let me know if you need any part of this in more detail/explained better.

I am somewhat familiar with Handshake and POKT … They’re decentralizing their respective industries in similar ways. So through your proposition, HNS benefits from using POKT as a relay network for HIP5 essentially? And POKT benefits from added security of direct node connections without CAs? Maybe the incentives for either party need to be clearer. I would love to resolve a HNS name to NodePilot as a public domain; not sure its possible…?