New HIP: TXT Record Naming Standards

[0xStefan]

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.

[rithvikvibhu]

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.

[rithvikvibhu]

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]

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

Kinda of .well-known directory, no?

[lukeburns]

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]

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.

[pinheadmz]

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

[pinheadmz]

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

[0xStefan]

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]

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]

Assigning the HIP-0010

[Falci]

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

[0xStefan]

@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]

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

[0xStefan]

HIP-10 Domain Listings are now implemented on niami/ if anyone reviewing this PR wants to test it.

[Falci]

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