handshake-org / hips Goto Github PK

I believe HIP-0002 should be expanded and an endpoint listing available addresses should be implemented.

For example, a GET request to https://<domain>/.well-known/wallets could retrieve a list of supported currencies.

The response could simply be a comma-separated plain-text list. The currencies could either be represented with their symbol, such as BTC,ETH,HNS, or with their SLIP-0044 coin type, such as 0,60,5353.

Other blockchain naming services have implemented similar features.

The primary goal of this GitHub issue is to organize a discussion that will lead to an introduction of a new HIP. The point is to get as many stakeholders as possible involved in the discussion while keeping the process focused on achieving an outcome. This part might appear to be needlessly wordy, but as with any good RFC, the more explicit the framing of the problem, the faster we'll get to a solution.

Once we agree on an approach in the comments on this issue, I (Peter aka allmyhinges) will draft a HIP together with anyone else that would like to be involved, and submit it as a pull request to this repo. I'll be editing this section as discussions progress, to reflect the state of the conversation.

The section called "Related conversations and resources" contains message quotes from Telegram and Discord chats and links to other resources and materials, to use as a conversation starter.

TODO

1. Agree on goals for this HIP
2. Agree on the use cases that it should cover
3. When there's either strong agreement or lack of strong disagreement, draft a HIP and submit a PR

Why

Handshake has spawned a thriving secondhand name market, giving rise to several solutions that help name sellers communicate name availability to buyers, such as Shakedex, Namebase Marketplace, Sinpapeles Parking etc. Each one of them tries to solve the buyer-seller discovery problem from different angles and by catering to different audiences. But all of these systems require having centralized rendezvous points where demand can discover supply. Having robust, well documented, commonly accepted solutions to different parts of this problem would allow companies and individuals that are building on top of Handshake to focus their attention and resources on innovative products that create value instead of endlessly reimplement a "product listing" database table. Doing this earlier rather than later allows the community to shape these solutions to stay true to the core tenets of the decentralized, peer-to-peer Handshake blockchain, before proprietary-but-free-as-in-beer solutions become too dominant.

What

Core idea of this proposal: develop a robust, well documented, decentralized mechanism for a Handshake name owner to signal/un-signal that they are willing to sell/trade/gift the name they control. It should work for the following closely related yet distinct use cases:

1. Name owner can signal that the name is available to be acquired: Allow a software application in possession of the private key that controls a particular Handshake name to signal to the world that the name is available for acquisition

2. Name owner can signal the location where more information about the offer can be found: In addition to signaling that the name is available to be acquired, the owner in use case 1 should be able to provide enough details in the signal for buyers to be able to find out more information about the availability offer

3. Name owner removes the availability signal: Allow a software application in possession of the private key that controls a particular Handshake name to withdraw the signal that the name is available for acquisition

4. Anyone can check whether a name is available for acquisition: Allow a software application that has access to the Handshake blockchain data to determine, without human intervention, whether a particular name is available for acquisition at that moment in time, based on signals sent by the owner of that Handshake name (for some definition of "that moment in time", which might end up being implementation-dependent, more on that later)

5. Anyone can build a list of all names that are available for acquisition: Allow a software application that has access to the Handshake blockchain data, without human intervention, to build a list of all Handshake names available for acquisition at that moment in time

Let's explicitly limit the scope of the discussion:

• This has nothing to do with Handshake's built-in "name auctions" mechanism. This proposal covers only the use cases that arise after a particular Handshake name has been "auctioned off" and is being controlled by a particular Handshake wallet
• This proposal assumes certain amount of human operator involvement, and is not intended to enable something like fully autonomous name trading bots, though it should not preclude such developments, either. We should aim to define just enough machine-readable formats and conventions so that human operated software applications can provide enough information to the operator that 1) name can be acquired and 2) "here's the place you go to get more details".
• This is NOT a full end-to-end system design for facilitating trustless selling and buying of Handshake names, but could be used as one small building block in such a system
• This is NOT intended as a replacement for existing marketplace solutions, and in fact can simplify some of the implementation aspects for existing solutions

Candidate solutions should meet the following requirements:

• Do not require any changes to the core Handshake software (goes without saying, but might as well spell it out)
• Do not create any new requirements for existing software applications to understand any new protocols, conventions or data formats, unless their developers choose to take advantage of the proposed solution
• Work well with existing HIPs
• Do not store data on-chain unless it's absolutely necessary to achieve the goals or fulfill other requirements
• Store data off-chain as much as possible
• Be simple and lightweight enough to be usable by a wide variety of applications, including wallets, online services and marketplaces etc
• Architecturally, be a small and composable building block as opposed to a prescriptive-yet-poorly-defined exercise in overengineering

Ideally, this proposal could serve as a template for solutions to other parts of the buyer-seller discovery problem.

Who

A majority of the Handshake ecosystem participants should be able to benefit from such a solution:

• Name buyers: Having better visibility into the global secondhand name market makes it easier to find names to acquire.

• Name sellers: Having access to a global secondhand name market makes it easier to find buyers for names.

• Decentralized marketplaces such as Shakedex Web: the hosted online Shakedex API has several purposes, one of them being a publicly accessible database of auction listings (which, for the purposes of this discussion, should be considered distinct from the repository of "presign" files which Shakedex also maintains). This proposal should significantly reduce or eliminate the need for Shakedex to maintain a centralized sale listings database if they choose to do so.

• Centralized marketplaces such as Namebase Marketplace: decentralized "for sale" signaling mechanism effectively becomes a free product supply channel that marketplaces can tap into to better serve their customers, at minimal cost to them, increasing name liquidity. This leaves plenty of room for companies and individuals to build innovative products and extract revenue by facilitating sales for their customers in a multitude of ways, be it private sales, complex purchasing agreements, lease-to-own etc.

• Wallet software such as the Bob Wallet: it already has a frontend to the Shakedex decentralized marketplace, though Shakedex's hosted online "auction listing" service is currently a single point of failure. If done right, this proposal should enable wallet software users to offer names for sale and to search lists of "for sale" names without relying on any third party services specifically built for that purpose.

• Registrars and second level domain service providers: having access to a global secondhand market makes it easier to find TLDs to address customer demand.

• Name parking, landing page hosting and related services such as Sinpapeles Parking: A free publicly accessible way to signal name availability is yet another marketing channel they can take advantage of.

• Name gifting initiatives, such as HNS Name Claim: A free publicly accessible way to signal name availability increases their chances of reaching gift recipients.

• A plethora of companies and products that provide various services to name market participants such as name value appraisal, brokerage, custody etc. They all get access to more data points about name values, sales, demand and supply.

How

WIP...let's first agree on WHY and WHAT before we get to HOW...

Related conversations and resources

Discord message from @kurumiimari dated June 16, 2021 in shakedex/#general:

So far the only HIP here is https://github.com/handshake-org/HIPs/blob/master/HIP-0002.md, which is only tangentially related to to this idea

Discord message from @pinheadmz dated June 17, 2021 in shakedex/#general

@Falci is also working on an idea for on-chain marketplace signalling: https://gist.github.com/Falci/f5213da5d914ce6ebf98c46eb844094f

and there's a place for it in my "live" auctions idea too: https://gist.github.com/pinheadmz/57b1db2edd9d55da928aafd581b2cb90

but in general I'm opposed to ideas that commit too much data on chain, they will not scale and end up getting squeezed out by fees (if HNS is successful enough!)
the great thing about HNS though is that these assets can point securely to websites! Which is a great place to host large files :wink:
so the standard could be something like a subdomain that we all agree will point to the marketplace for your name like lets say we agree on a standard and it gets labeled HIP-0009. Then you could set up a subdomain at https://hip-0009.allmyhinges and thats where your pre-signs would be, or live auction details etc
services like shakedex, sinpapeles even namebase could help support this since it will require a nameserver and a webserver
open source anon warriors can maybe install handout to host this on their own server
then if you want to know if a name is for sale via dex, just try going to that url
sites like shakedex could crawl the HNS root once in a while looking for these SLDs to resolve and maintain a list

Telegram message from @rithvikvibhu dated June 16, 2021 in https://t.me/bobwallet

Based on the number, time, rate, etc. the file could be huge. So storing on the blockchain might not be a great idea. Could link to a url though.

Telegram message from @brandondees dated June 16, 2021 in https://t.me/bobwallet

depending on file size it might need to be stored off-chain somewhere but the HIP could specify how to handle it via url

also feels like probably a good use case for footnote

Links:

• live auctions HIP pull request
• On-chain marketplace signalling idea by @Falci

As we work to provide a templated HIP-001 and Readme, we will first need to initialize the repo. If we start with a blank Readme.md by one of the existing maintainers, I can fork and then submit a PR.

We discussed this in dev chat, that hip2 names should always be prefixed with @ so the user (and wallet software) knows its not intended to be a valid address. Also I think if the string is a valid address (even with the @ included) then hip2 resolution should be aborted.

TODO:

• Link unfurl: HTML's meta tag for sharing links;
• Table of content: right sidebar;
• "Edit on GitHub" link;

I think we should define "informational" vs "standards" tracks similar to this: https://github.com/bitcoin/bips/blob/master/bip-0002.mediawiki#bip-types and then maybe re-evaluate the existing HIPs. I think all the existing HIPs are actually informational because they do not apply do layer-1 blockchain consensus and "implementers are free to ignore them."

We should probably also define statuses like this: https://github.com/bitcoin/bips/blob/master/bip-0002.mediawiki#BIP_status_field and I think all HIPs so far submitted are technically "final" -- and I think at this stage we can probably open PRs with that status.

The known wallet file, .wallet, is not actually fully secured by the chain of trust in this proposal. The certificate itself is but not the contents of the web server which are served out of band.

There are better options:

Coupling the name and the receive wallet

1. The name itself is associated with a UTXO, and therefore, a wallet already.

Decoupling the name and the receive wallet

1. A receive address can be stored on chain as a TXT record.
2. A receive address can be served as TXT record by a DNSSEC secured authoritative zone.
3. Use suggested HTTPS method, but with a signed message containing the receive address.

There are likely other options. By including the language in Decoupling#3 or by using one of the other options, a sender can rest assured they are sending to an address verified by the chain of trust as opposed to a potentially hacked web server that continues to maintain the right cert.