handshake-org / hips Goto Github PK
View Code? Open in Web Editor NEWHandshake Improvement Proposals
Home Page: https://hsd-dev.org/HIPs
Handshake Improvement Proposals
Home Page: https://hsd-dev.org/HIPs
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.
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.
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:
Candidate solutions should meet the following requirements:
Ideally, this proposal could serve as a template for solutions to other parts of the buyer-seller discovery problem.
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.
WIP...let's first agree on WHY and WHAT before we get to HOW...
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:
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.
TODO:
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.
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:
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.
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.
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.
A declarative, efficient, and flexible JavaScript library for building user interfaces.
๐ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. ๐๐๐
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google โค๏ธ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.