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
104 changes: 104 additions & 0 deletions HIP-0010.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,104 @@
# HIP-0010 : Standard for Domain Listings via TXT Records

```
Number: HIP-0010
Title: Standard for Domain Listings via TXT Records
Type: Standards
Status: Draft
Authors: 0xStefan <https://twitter.com/0xStefan>
Created: 2022-02-22
```

## Abstract

A proposal to create a standard for the labels of string attributes in TXT records for domain listings — following the [RFC 1464](https://datatracker.ietf.org/doc/html/rfc1464) standard.

## Motivation

If a domain is not listed on an open marketplace like Namebase or Shakedex, it's hard to know if a domain is for sale by the owner or not. Furthermore a domain seller has no reliable way to provide that information.

## TXT Record Standard: Domain Listing

For the above to work we need standards so any website or app can properly render the TXT records. The records should be flexible, short and easy to understand. It's important to note, that all values should be checked by the application before serving them to the user.

The general syntax for domain listings is:

**TXT** `listing <attribute name>=<attribute value>`

There are currently two supported attributes: **[price](#price)** and **[url](#url)**.

Although each `<attribute name>=<attribute value>` pair can be provided as individual records, please consider using the **[recommended implementation](#alt)**.

### <a id="price"></a> (1) Listing Attribute: Price (mandatory)

The listing price attribute is mandatory to create a domain listing. It enables a domain owner to provide a listing price for the domain. The expected value is the unit as a string, followed by the amount as a number. If the number contains decimals, a dot must be used as a seperator.

```
TXT listing price=<unit number>
```

#### Valid Listing Price Examples

```
TXT listing price=HNS 1000
TXT listing price=USD 50
TXT listing price=EUR 999.99
TXT listing price=BTC 0.000224
```

The value can be prefixed with a greater-than symbol (>) to indicate it's a minimum price offer.

```
TXT listing price=>HNS 1000
TXT listing price=>USD 50
```

The value can also be 0 or null:

```
TXT listing price=0
TXT listing price=
```

Which means the domain is for sale and offers are accepted.

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


```
TXT listing url=<URL>
```

#### Valid Listing Url Examples

```
TXT listing url=https://www.learnmore.com/about/my/domain
TXT listing url=https://learnmoreaboutmydomain/
```

## <a id="alt"></a> Recommended Implementation

To save blockchain / urkel tree space it's encouraged to use only one TXT record for the listing. A semicolon is then used to seperate each `<attribute name>=<attribute value>` pair.

```
TXT listing price=<unit number>;url=<URL>
```

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

```

## Security Concerns

There is a slight chance of Cross Site Scripting (XSS). Therefore a site owner should always verify the provided URL data before adding it to the DOM.

### Example

`<a href="javascript:alert('Hello World!');">Execute JavaScript</a>`

## References

[RFC 1464 Standards](https://datatracker.ietf.org/doc/html/rfc1464)
130 changes: 130 additions & 0 deletions HIP-0013.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,130 @@
# HIP-0013 : Standard for Profile Data via TXT Records

```
Number: HIP-0013
Title: Standard for Profile Data via TXT Records
Type: Standards
Status: Draft
Authors: 0xStefan <https://twitter.com/0xStefan>
Created: 2022-02-22
```

## Abstract

A proposal to create a standard for the labels of string attributes in TXT records for profile data — following the [RFC 1464](https://datatracker.ietf.org/doc/html/rfc1464) standard. Parts of this standard where inspired by [EIP-634](https://eips.ethereum.org/EIPS/eip-634).

## Motivation

Handshake domains can also be used as usernames. Domains are used to sign in to websites and to identify users in the Handshake ecosystem. Therefore it's useful to be able to attach profile information like an email, phone, avatar or service to a Domain.

This Standard can also be used to provide contact information for domain listings according to [HIP-0010](https://github.com/handshake-org/HIPs/blob/master/HIP-0010.md).

## TXT Record Standard: Profile Data

For the above to work we need standards so any website or app can properly render the TXT records. The records should be flexible, short and easy to understand. It's important to note, that all values should be checked by the application before serving them to the user.

The general syntax for profile data is:

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


Although each `<attribute name>=<attribute value>` pair can be provided as individual records, please consider using the **[recommended implementation](#alt)**.

### <a id="email"></a> (1) Profile Attribute: Email

The email attribute is optional. It enables a domain owner to provide an email for the domain. The expected value is an email address.

```
TXT profile email=<email-address>
```

#### Valid Email Examples

```
TXT profile email=hello@niami.io
TXT profile email=hello@niami
```

### <a id="phone"></a> (2) Profile Attribute: Phone

The phone attribute is optional. It enables a domain owner to provide a phone number for the domain. The expected value is a phone number as an E.164 string (a number up to fifteen digits in length starting with a '+'). Regex: `^\+[1-9]\d{1,14}$`

```
TXT profile phone=<phone-number>
```

#### Valid Phone Examples

```
TXT profile phone=+15368886253
TXT profile phone=+47538886253
```

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


Allowed image formats are: APNG, AVIF, GIF, JPEG, PNG, SVG, WebP according to [Common image file types](https://developer.mozilla.org/en-US/docs/Web/Media/Formats/Image_types).

```
TXT profile avatar=<URL>
```

#### Valid Avatar Examples

```
TXT profile avatar=https://mywebsite.com/avatar.png
TXT profile avatar=https://siasky.net/MABn4I5M6yPT0aCjIMU2OjlTWmKysaqoCeP0gSJw5moVrg
```

### <a id="service"></a> (4) Profile Attribute: Service

The service attribute is optional. It enables a domain owner to provide a username to a service. The expected value is a service key followed by a username.

```
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?


#### Valid Service Examples

```
TXT profile service=com.twitter niami
TXT profile service=com.github 0xstefan
TXT profile service=io.keybase pinheadmz
TXT profile service=hnschat. skmo
```

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


```
TXT profile mail=<email-address>;phone=<phone-number>;avatar=<URL>;service=<service-key username>
```

### Valid Profile Example with the semicolon delimiter

```
TXT profile email=hello@example.com;phone=+15368886253;avatar=https://mywebsite.com/avatar.png;service=com.github 0xstefan
```

## Security Concerns

There is a slight chance of Cross Site Scripting (XSS) when using URL's in attributes. Therefore a site owner should always verify the provided URL data before adding it to the DOM.

### Example

`<a href="javascript:alert('Hello World!');">Execute JavaScript</a>`

## References

[RFC 1464 Standards](https://datatracker.ietf.org/doc/html/rfc1464)

[Common image file types by mozilla](https://developer.mozilla.org/en-US/docs/Web/Media/Formats/Image_types)

[EIP-634: Storage of text records in ENS](https://eips.ethereum.org/EIPS/eip-634)

[Official ITU E.164 recommendation](https://www.itu.int/rec/T-REC-E.164/en)