Allowable names discussion

etherbroker · April 04, 2014, 04:09:16 PM

Wise decision on choosing .p2p

:)

ppcholder · April 04, 2014, 03:18:43 PM

Quote from: toast on April 04, 2014, 04:03:27 AM
We're going with the standard domain charset right now (anything you can use for .com)

Sent from my SCH-I535 using Tapatalk

bingo. other charset is wasting time. especially chinese character.

alt · April 04, 2014, 04:34:23 AM

Quote from: toast on April 04, 2014, 04:03:27 AM
We're going with the standard domain charset right now (anything you can use for .com)

Sent from my SCH-I535 using Tapatalk

that's good. do you know why not set rules for keyhotee id?

toast · April 04, 2014, 04:03:27 AM

We're going with the standard domain charset right now (anything you can use for .com)

Sent from my SCH-I535 using Tapatalk

alt · April 04, 2014, 04:01:46 AM

Quote from: bytemaster on March 18, 2014, 05:22:53 AM
Lets establish the design goals:

1) support as many native languages as possible (Chinese)
2) prevent phishing attacks by allowing similar looking names.
3) backward compatibility

I put a high value on #3 which means that any name should be compatible with existing DNS systems.

Lastly, subdomains should be handled in the value section of the output and thus '.' is not permissible in the name.

dont's enable chinese languages,don't use utf8,because too many special charset
like chinese space "　", I don't think it's a good idea to enable this in the domain name.

bitbadger · March 20, 2014, 02:01:51 AM

I would suggest to add a hyphen or underscore, to allow a word-separator character that is not a period. Plus there is the precedent of traditional DNS allowing hyphens, and traditional e-mail addresses allowing underscores. So, one or the other would be nice.

ebit · March 19, 2014, 01:32:53 AM

bts.es

alt · March 19, 2014, 12:19:25 AM

Should we enable the domains which have using now, like: .com, .org ......?
I think we should disable this now to avoid prevent phishing attacks.

toast · March 18, 2014, 11:27:54 PM

You can verify signatures for normal dns records

Sent from my SCH-I535 using Tapatalk

Troglodactyl · March 18, 2014, 11:18:16 PM

This may be overly ambitious (if that's a term we use around here), but what about reserving '.' as a subdomain delimiter, and '/' as a protocol and path delimiter, but allowing any other character sequence as a domain, no designated TLD required. We could at least temporarily reserve/block all existing or already reserved TLDs until they can be ported to the BitShares DNS system, and the initial plugin would just propagate requests to those TLDs into the traditional DNS system.

To minimize loss of stake as a barrier to entry, it would be good if there were a way to seed the system with a snapshot of current domain ownership, but I don't yet see a good way to do this.

toast · March 18, 2014, 05:04:50 PM

OHHH like you will just route requests to bitshar.es through your site as an alternative to getting the extension. Got it.

bytemaster · March 18, 2014, 05:03:42 PM

Quote from: toast on March 18, 2014, 05:00:12 PM
Wait what? Are you saying it should be a valid subdomain you could use under bitshar.es? Then that directly contradicts requirement 1...

I do not believe all requirements can be met at once, and I submitted that #3 trumps #1 & #2

On the other hand... we can allow 'backward compatibility' for the subset of names that support it and other names that fall under #1 would only be resolvable with custom browser extensions.

toast · March 18, 2014, 05:00:12 PM

Wait what? Are you saying it should be a valid subdomain you could use under bitshar.es? Then that directly contradicts requirement 1...

bytemaster · March 18, 2014, 04:59:05 PM

Quote from: toast on March 18, 2014, 05:29:13 AM
How exactly do you mean "backwards compatible with existing systems"? What legacy systems would this interact with? AFAIK this should only touch the browser extension. Do you mean it should look like a DNS server? That's up to whoever is hosting a node as a "dedicated DNS node" a la DNSchain to do, I guess we could make it easier by making the API expose the same information.

#2 is *really* tough if you want #1

Backward compatibility:

${YOUR_BITSHARES_DNS_NAME}.bitshar.es

toast · March 18, 2014, 05:29:13 AM

How exactly do you mean "backwards compatible with existing systems"? What legacy systems would this interact with? AFAIK this should only touch the browser extension. Do you mean it should look like a DNS server? That's up to whoever is hosting a node as a "dedicated DNS node" a la DNSchain to do, I guess we could make it easier by making the API expose the same information.

#2 is *really* tough if you want #1

bytemaster · March 18, 2014, 05:22:53 AM

Lets establish the design goals:

1) support as many native languages as possible (Chinese)
2) prevent phishing attacks by allowing similar looking names.
3) backward compatibility

I put a high value on #3 which means that any name should be compatible with existing DNS systems.

Lastly, subdomains should be handled in the value section of the output and thus '.' is not permissible in the name.

jwiz168 · March 18, 2014, 01:52:09 AM

im thinking of a fixed octet and an ascii character at the end.

toast · March 18, 2014, 01:39:08 AM

This is *not* a discussion about TLDs or UX.
This is just a discussion for what are permissible strings for names in the name-record store.

First suggestion, lowercase alphanumeric.

Second suggestion, lowercase alphanumeric and periods, but only if you owned the suffix without any periods (so you can emulate subdomains). Still manageable complexity.

Also maybe lowercase alphanumeric and any symbols, with above suffix rule.

Stuff that currently appears after the TLD in your browser bar is not part of the name resolution and is independent of this system so it would remain the same.