Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

New HIP: TXT Record Naming Standards #46

Open
wants to merge 16 commits into
base: master
Choose a base branch
from

Conversation

0xStefan
Copy link

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.

HIP-xxxx.md Outdated Show resolved Hide resolved
HIP-xxxx.md Outdated Show resolved Hide resolved
HIP-xxxx.md Outdated Show resolved Hide resolved
HIP-xxxx.md Outdated Show resolved Hide resolved
HIP-xxxx.md Outdated Show resolved Hide resolved
HIP-xxxx.md Outdated Show resolved Hide resolved
HIP-xxxx.md Outdated Show resolved Hide resolved
HIP-xxxx.md Outdated Show resolved Hide resolved
HIP-xxxx.md Outdated Show resolved Hide resolved
@rithvikvibhu
Copy link
Member

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.

HIP-xxxx.md Outdated Show resolved Hide resolved
@rithvikvibhu
Copy link
Member

rithvikvibhu commented Feb 28, 2022

Idea: a field called meta with value of a https url. The page must follow the same standard parsing of TXT fields, but since it's served by a website, it can be dynamic. Of course on chain records are possible, and preferred in cases, but with pointing to a website (secured by CA/DANE), it's possible to do a lot more things using existing field standards:

  • Not constrained to 512 bytes (blockchain dns size limit), also leaves more room for other records
  • listing price changes based on page views/time
  • dynamic wallet addresses (though there's HIP-2 for this)

Edit: continuing in a thread here: https://github.com/handshake-org/HIPs/pull/46/files#r815933617

@Falci
Copy link
Member

Falci commented Feb 28, 2022

Idea: a field called meta with value of a https url...

Kinda of .well-known directory, no?

HIP-xxxx.md Outdated Show resolved Hide resolved
@lukeburns
Copy link
Contributor

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.

@rithvikvibhu
Copy link
Member

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.

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:

What is a HIP?
A Handshake Improvement Proposal is a technical document that attempts to standardize a feature or protocol extension across the Handshake ecosystem.

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.
@0xStefan 0xStefan changed the title New HIP: Standard for TXT records New HIP: TXT Record Naming Standard for Domain Listings Mar 10, 2022
@0xStefan 0xStefan changed the title New HIP: TXT Record Naming Standard for Domain Listings New HIP: TXT Record Naming Standards Mar 11, 2022
HIP-xxx.md Outdated

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

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

HIP-xxxx.md Outdated Show resolved Hide resolved
0xStefan and others added 3 commits March 14, 2022 20:37
Co-authored-by: Sirawit Thaya <[email protected]>
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
HIP-xxxx.md Outdated Show resolved Hide resolved
HIP-xxx.md Outdated Show resolved Hide resolved
@pinheadmz
Copy link
Member

It might be worth considering interoperability with ENS: https://eips.ethereum.org/EIPS/eip-634 either matching their spec or at least referncing it.

HIP-xxx.md Outdated Show resolved Hide resolved
@pinheadmz
Copy link
Member

Is it on RFC spec to just use one TXT but multiple values?
TXT profile name=zip,state=CA,eyes=brown

@0xStefan
Copy link
Author

Is it on RFC spec to just use one TXT but multiple values? TXT profile name=zip,state=CA,eyes=brown

I read through some specs and haven't seen such a pattern during my research

@pinheadmz
Copy link
Member

Is it on RFC spec to just use one TXT but multiple values? TXT profile name=zip,state=CA,eyes=brown

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

@Falci
Copy link
Member

Falci commented May 27, 2022

Assigning the HIP-0010

@Falci
Copy link
Member

Falci commented May 30, 2022

Sorry, I didn't realise this PR has 2 HIPs together.
For the second: Assigning the HIP-0013

0xStefan added 5 commits May 31, 2022 09:22
- 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)
@0xStefan
Copy link
Author

@pinheadmz
I updated HIP-0010 and HIP-0013 to contain a recommended implementation with semicolon separated key/value pairs. Think this was a great idea you had.
I also used some ideas from EIP-634 to make this HIP better (E.164 phone format; Services instead of Social networks; Reverse dot notation as service key).

@0xStefan
Copy link
Author

0xStefan commented Jun 5, 2022

Created a HIP-10 (and soon HIP-02/12/13) Helper tool: fourhands ✋🖖🤚🖐

@0xStefan
Copy link
Author

0xStefan commented Jun 7, 2022

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.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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://.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
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

@Falci
Copy link
Member

Falci commented Mar 15, 2024

Forecasting some updates in the HIP-13, I'm wondering if we should split this PR in 2?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

7 participants