BitShares Forum
Other => Graveyard => KeyID => Topic started by: toast on 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.
-
im thinking of a fixed octet and an ascii character at the end.
-
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.
-
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
-
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
-
Wait what? Are you saying it should be a valid subdomain you could use under bitshar.es? Then that directly contradicts requirement 1...
-
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.
-
OHHH like you will just route requests to bitshar.es through your site as an alternative to getting the extension. Got it.
-
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.
-
You can verify signatures for normal dns records
Sent from my SCH-I535 using Tapatalk
-
Should we enable the domains which have using now, like: .com, .org ......?
I think we should disable this now to avoid prevent phishing attacks.
-
bts.es
-
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.
-
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.
-
We're going with the standard domain charset right now (anything you can use for .com)
Sent from my SCH-I535 using Tapatalk
-
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?
-
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.
-
Wise decision on choosing .p2p
:)