Using hdns, it is possible to build an electron
based web browser that is able to natively resolve Handshake names. The hdns library
can be dropped into existing Node.js applications and enable Handshake names to be
resolved, along with doing SIG0 DNS message authentication. DANE/TLSA could also be
added, so that Certificate Authorities are not needed for the "green checkbox" user
experience.
The Lightning Network bolt #10 defines a DNS based way to find peers. A client and server could be built out in a general way, enabling any p2p system to discover peers. The authentication through DNS is very important.
This involves running some Zcash nodes that are addressable by Handshake names and seeing if they could be added as seeder nodes. It would add resiliancy to the network.
There are many HTTP client libraries in JavaScript that give nice interfaces to
the lower level HTTP capabilities. None of these currently include Handshake support,
so releasing a package on npm that is well maintained would be useful.
It could include a curl like tool that utilizes the HTTP client library.
The hdns library is a drop in replacement for the Node.js DNS module
and can be dropped into an HTTP client to be used as a custom DNS lookup
function. This allows an app to include the library and instantly have
access to the ability to resolve Handshake names.
It would be useful if the library was ported to other languages so that applications not written in JavaScript can take advantage of this type of functionality.
(I'll delete this comment after "merge")
Auto-reveal watchtower
REVEALs are required to be confirmed on the blockchain within a specific window of time, or the money is locked forever! Users who BID may not be online during that time, or simply forget. Exchanges and centralized registrars can provide this service for their customers but what about individual full node users like Bob? REVEALs can be pre-signed and sent to a third party watchtower service. The TX can even include an extra output that pays a fee to the watchtower. The watchtower can earn their fee simply by broadcasting the pre-signed REVEAL at the right time.
Recover encrypted blind values from blockchain data
See handshake-org/hsd#378 and especially the comment by pinheadmz at the bottom. Bids are blinded, meaning their actual value is secret and only known to the user. This breaks recoverability by the BIP44 standard which is supposed to only require a mnemonic seed and whatever transaction history is available on the blockchain. Can the secret BID value be encrypted with the user's wallet keys in such a way that the secret nonce (pre-image to the BLIND) can be regenerated?
Federated subdomain management
Everyone wants to know how we can use sidechains on Handshake to decentralize subdomains. Is it possible? We know that Handshake names can be owned by a robust multisig script (like 15-of-20). But what about the zone data itself? is there a cryptographic construction whereby a federation of untrusted nodes can collaborate to create a single DNSKEY that signs a zone?
Nameserver that generates BTC / HNS addresses
An authenticated nameserver that is authoritative over a HNS TLD zone should be able to generate BTC or HNS receive addresses and return them as TXT records when queried. They could be resolved as a pseudo subdomain like
_btc.domain. TXTor_hns.domain. TXT. When a new address is generated by request, it should also be saved to some kind of log file on the server so the user knows how deep the wallet depth is (see BIP44). The server should be a watch-only wallet with anxpubso it only has access to public keys.BTC-HNS cross-chain atomic swaps
See https://bcoin.io/guides/swaps Create a decentralized exchange where users can propose HNS-BTC trades and accept them without trust.