New HIP: TXT Record Naming Standards#46
New HIP: TXT Record Naming Standards#460xStefan wants to merge 16 commits intohandshake-org:masterfrom
Conversation
|
One thing I'm curious about is how much space can be saved by using a single TXT instead of 1 TXT per field. Is it significant? Might need to look at how records are serialized. |
|
Idea: a field called
Edit: continuing in a thread here: https://github.com/handshake-org/HIPs/pull/46/files#r815933617 |
Kinda of |
|
Is there a reason that this should be a HIP rather than a convention that e.g. Bob and Parking.Sinpapeles decide to both use? One worry I might have is conflicts with other protocols that just happen to use the same conventions, but aren't used the same way. OTOH, I could imagine some sort of standard like this being useful for interfacing with the other HIPs on name swaps or auctions in some way. |
Exactly why a standard now will help everyone use the same fields and formats. If Bob and PS decide on a convention that isn't standard, it makes it harder for others (ex: niami - run by this HIP author :p) to follow - and keep up with in case of updates. HIPs are pretty lenient. From the README:
|
This is my updated proposal for the TXT Record Naming Standard for Domain Listings. I will create one more for Identity and one for NFT's. This will make it easier for discussions and to maintain the proposals.
|
|
||
| ### <a id="avatar"></a> (3) Profile Attribute: Avatar | ||
|
|
||
| The avatar attribute is optional. It enables a domain owner to provide an avatar for the domain. The expected value is a fully qualified URL that must start with http:// or https:// that points to an image file. |
There was a problem hiding this comment.
Is this limited to be only http:// and https:// hence the "must"?
I think this should also accept something like ftp:// or decentralized storage protocols like ipfs://, ipns://, sia://, ar:// or maybe anything that follows RFC3986 standard
There was a problem hiding this comment.
Not sure about ftp://. When would you need that?
With the others I totally agree but would IMO only add them after they receive full support in most major browsers.
It just doesn't make sense. TL;DR Wallet TXT records are easier for the everyday user, but much harder for devs to implement. HIP-002 is easier for devs to implement but harder to set up for everyday users. See discussion here: https://discord.com/channels/822591034202521641/822591754477371443/956843184376401930
|
It might be worth considering interoperability with ENS: https://eips.ethereum.org/EIPS/eip-634 either matching their spec or at least referncing it. |
|
Is it on RFC spec to just use one TXT but multiple values? |
I read through some specs and haven't seen such a pattern during my research |
OK, might be worht discussing / considering since it will save blockchain / urkel tree space |
|
Assigning the |
|
Sorry, I didn't realise this PR has 2 HIPs together. |
- HIP number added - New title to better distinguish HIP-10 and HIP-13 - Added optional symbol => for minimum price offer
- New title to better distinguish between HIP10 and HIP13 - Add HIP number
- Renamed 'social' to 'service' as recommended by [EIP-634](https://eips.ethereum.org/EIPS/eip-634) - Used the reverse dot notation as the service key for better compatibility and flexibility - Added recommended implementation via semicolon delimiter - Changed phone format to [E.164](https://www.twilio.com/docs/glossary/what-e164)
|
@pinheadmz |
|
Created a HIP-10 (and soon HIP-02/12/13) Helper tool: fourhands ✋🖖🤚🖐 |
|
HIP-10 Domain Listings are now implemented on niami/ if anyone reviewing this PR wants to test it. |
|
|
||
| **TXT** `profile <attribute name>=<attribute value>` | ||
|
|
||
| There are currently five supported attributes: **[email](#email)**, **[phone](#phone)**, **[avatar](#avatar)** and **[service](#service)**. All attributes are optional but at least one attribute needs to be present, for a Domain to count as a profile. |
There was a problem hiding this comment.
What are your thoughts on adding "name" to this list? Could be an individual's name or a company's.
| TXT profile service=<service-key username> | ||
| ``` | ||
|
|
||
| The service key is made up of a reverse dot notation for a namespace the service owns, ex: com.twitter, com.namebase, io.github. Service keys must contain at least one dot. So if a service is hosted on a Handshake TLD, the service key has to end with a dot. |
There was a problem hiding this comment.
Is this supposed to be io.keybase instead of io.github?
|
|
||
| ### <a id="avatar"></a> (3) Profile Attribute: Avatar | ||
|
|
||
| The avatar attribute is optional. It enables a domain owner to provide an avatar for the domain. The expected value is a fully qualified URL that must start with http:// or https:// that points to an image file. |
There was a problem hiding this comment.
I'm fine with this, but thoughts on mandatory https? Can't think of a reason why any website would be http-only, and as a standard, might be better to encourage secure sites.
|
|
||
| ## <a id="alt"></a> Recommended Implementation | ||
|
|
||
| To save blockchain / urkel tree space it's encouraged to use only one TXT record for the profile. A semicolon is then used to seperate each `<attribute name>=<attribute value>` pair. |
There was a problem hiding this comment.
Is semicolon (the delimiter) prohibited as values? If no, are they supposed to be escaped? Maybe add a note somewhere.
Curious how your fourhands implementation handles it.
|
|
||
| ### <a id="url"></a> (2) Listing Attribute: URL (optional) | ||
|
|
||
| The listing url attribute is optional. It enables a domain owner to provide a url, where visitors can find more information about the domain. It can also be used to point visitors to a parking website or a private marketplace. The expected value is a fully qualified URL that must start with http:// or https://. |
There was a problem hiding this comment.
same comment re: http from before/below
| ### Valid Listing Example with the semicolon delimiter | ||
|
|
||
| ``` | ||
| TXT listing price=>HNS 1000;url=https://www.learnmore.com/about/my/domain |
There was a problem hiding this comment.
| TXT listing price=>HNS 1000;url=https://www.learnmore.com/about/my/domain | |
| TXT listing price=HNS 1000;url=https://www.learnmore.com/about/my/domain |
|
Forecasting some updates in the HIP-13, I'm wondering if we should split this PR in 2? |
I created this HIP as recommended by @pinheadmz
I tried to keep it as simple as possible for the end-user and used only one-word TXT entries.
It's important to keep in mind, that we cannot verify any TXT entries that are submitted on-chain. Therefore the site owner or app has to do the heavy lifting.
This is really just a draft and I'm happy for any polite pushback.