"Name is available for acquisition" signaling mechanism

[pbkhrv]

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. Most 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

[pbkhrv]

So....
0. Is it clear what we are trying to do?

1. Do we agree that a mechanism like this would be useful?
2. Do the use cases make sense?
3. Did I misrepresent or incorrectly describe anything or anyone? Just want to make sure I'm not completely off-base.

[Falci]

"[...] all of these systems require having centralized rendezvous points [...]"

Not Parking.Sinpapeles.
Actually, I believe all the 5 points under What are already available on Parking.Sinpapeles.

I agree that Parking.Sinpapeles lacks in a well formatted documentation (aka HIP). My fault. The reason for that is Parking is older than this HIPs repository. You can find references of it here, here and here.

All Parking.Sinpapeles data are on-chain (except page view counter).

[pbkhrv]

Got it, thanks for the input. I replaced "all of" with "most".

Half-seriously: if nothing else works out, maybe you can just add a .well-known to Parking linking to presign files, and we'll have an intermittent standard :-)

[pinheadmz]

I was chatting with someone else about this and they suggested using another /.well-known entity like https://nameforsale/.well-known/HIP0009.json or something. Then the HIP-0009 spec would describe the json format. I think it would include at least one property like type which would be defined in HIP-0009 (sorry Falci just using that number for example ;-) ) Examples of "types" would be hip-0001 meaning the rest of the json file would be the shakedex presigns, etc. We could come up with plenty of other types like "email me with your offer" etc.

I originally thought a subdomain would be cool but actually an https URL might be better, because no matter what a DANE-secured webserver is required to serve the json. Its just a question of convenience for buyers and sellers to access.

This scheme satisfies all five "whats" -- for number 5 anyone could crawl the HNS root zone, attempting to fetch the well-known URL for every domain and compiling a list of names and data that resolves. As the root zone approaches 63,000,000 names however, this crawl may take a few days (?) to complete.

[pbkhrv]

(Take my opinion with a grain of salt, I'm new to Handshake). FWIW I'm with Fernando on the DNS vs TXT. Forcing Bob Wallet to crawl hundreds of thousands of sites that have NS set just to find 100 that are "for sale" sounds like it might devalue the whole mechanism a lot. Outsourcing the crawling to something like Shakedex means we are back to relying on third-party services.

I understand the point of conserving on-chain space, but using a hundred-odd of the 512 bytes allowed for the resource record for this mechanism seems like a worthy tradeoff. Think of it this way - we want as many name owners as possible to use the resource record space to point to a name server and actually use the name for DNS, because that'll increase the overall value of Handshake as a system. Those that bought names as investment or to trade and are sitting on them - let's encourage them to use the resource record space to facilitate the transfer of the name to those that WILL use it for DNS?

[pinheadmz]

That's a good point and actually I'd add it to the list of design goals - by using an on chain TX (in this case it would be an UPDATE with a special TXT) there is an active notification. In fact if we wanted to even let SPV wallets in on the game we could define a special nulldata address that they could add to their bloom filters and catch these TXs in blocks. There would still be some kind of scanning happening though, especially if you just installed Bob and wanted to see if any names had recently set such a TXT record. There will also need to be some kind of expiration timestamp somewhere in case a name is sold but the new owner doesn't bother to change the DNS records.

[pbkhrv]

Scanning is hard to avoid, IMHO. If the HIP recommends to scan TXs and look for UPDATES with TXT records of particular format, at least wallets that want to have the decentralized marketplace feature have a fighting chance of generating and maintaining lists of "names for sale" on their own. It could be an optional feature, that might slow down the syncing a bit as a tradeoff, but it would be very possible. Here are some numbers to add color to this point:

According to a quick-and-dirty script, as of block height 72875, there have been:

• ~89k UPDATE actions/covenants with ~12k unique name hashes
• ~1.2 million REGISTER actions/covenants
• ~1.4 million unique name hashes

[Falci]

You calc is a bit misleading: REGISTER can also acts as UPDATE.

[pbkhrv]

You calc is a bit misleading: REGISTER can also acts as UPDATE.

The script is literally dumping every single covenant and lets me grep REGISTERs, UPDATEs etc, regardless of the "logical operation" that the covenant performs:

▶ node dump-covenants.js | grep UPDATE | wc -l
89051

▶ node dump-covenants.js | grep REGISTER | wc -l
1257057