Support new protocol: Mirror distributed.press on decentralized a Handshake (HNS) name

[johnnywu-namebase]

How to operate a node

https://github.com/handshake-org/hsd or https://github.com/handshake-org/hnsd ...

URL scheme and domain name system

Instead of renting the "distributed" subdomain from the owner of the ".press" top-level domains, Handshake names are decentralized top-level domains, which means Distributed Press could fully control its own domain names. One caveat is that most major browsers do not yet natively support Handshake, so visitors will need to use a Handshake-compatible browser like Puma Browser, a gateway like HNS.to, a public resolver like HDNS.io, an application that resolves Handshake like NextDNS, or a Handshake node to access Handshake domains.

One option is to use a Handshake name as a "backup" for distributed.press, so that in the event where the distributed.press domain name is seized, its contents can still be accessible via the Handshake name.

docs.namebase.io will probably be helpful for this effort. ...

Publishing process and cost (computation or financial) for content and DNS

Handshake works identically to the existing DNS system, so there shouldn't be any issues here. ...

HTTP gateway support

I don't totally understand what's being addressed here but it should be possible. ...

[benhylau]

Thanks for submitting this. Some questions!

Handshake works identically to the existing DNS system, so there shouldn't be any issues here.

Right now we use Digital Ocean to manage and publish TXT records using its API. How can I do this with HNS?

I don't totally understand what's being addressed here but it should be possible.

I think you already answered this above with HNS.to. Essentially what we need is to run a gateway ourselves and do welcome.nb -> http://welcome.nb.hns.to. Instead we want hns.distributed.press to be the gateway and it can turn one.compost.digital into something like https://one.compost.digital.hns.distributed.press?

First Q is how do I run such a gateway.

Then I imagine the above isn't possible bc I can't get wildcard certs of arbitrary subdomain levels. How are you handling this?

[rithvikvibhu]

Hey @benhylau, just checked the project and and it's super cool! I read the readme on what's expected out of new protocols and feel like Handshake is not really a new protocol, just an extension of custom domains that's already supported. Handshake doesn't have a dedicated scheme, it works at the DNS level.

From what i understand, you wouldn't need a dedicated gateway for Handshake (just like you wouldn't spin up a new IPFS gateway for every custom domain). It can point to the existing IPFS gateway.

The blockchain DNS is referral only so will not be updated every 15 minutes, just a 1-time update to set the NS records.

Process

The process is pretty much the same as custom domains:

• Someone (say User) wants to add http://dpressonhns/
• User sets the NS records on chain to ns{}.digitalocean.com
• User submits the config.json with the API as usual
• Digital Ocean creates the zone as usual like any other custom domain
• All DNS updates (setting TXT, etc) happens directly with Digital Ocean like with any other domain

The catch

There catch here is that Handshake domains are Top-Level Domains, so some nameservers don't host TLD zones. I'm not sure if Digital Ocean does (normally, they wouldn't expect to host a complete .com or .org lol.)

If they already work with TLDs or if their support can enable it, then no changes to this code well be needed.

If not, another nameserver (as an alternative to Digital Ocean) would be needed. And the DNS update API calls would be made to that nameserver.

Edit: there's nothing special about a nameserver for handshake, any will do (powerdns, bind9, etc.)