Has there been any discussion regarding refactoring d/name etc -> d/name.bit?
I would like to outline a proposal, but I can't imagine that this hasn't been pitched before. However, it's not a very google-able concept, I've only found some really old discussions relating whether we should enable multiple TLDs or not.
Refactoring Namespace: d/name -> d/name.bit
-
- Posts: 801
- Joined: Sun Aug 18, 2013 8:26 pm
- os: mac
Refactoring Namespace: d/name -> d/name.bit
DNS is much more than a key->value datastore.
-
- Posts: 94
- Joined: Sat Mar 29, 2014 2:20 pm
- os: linux
- Location: Sheffield, England
- Contact:
Re: Refactoring Namespace: d/name -> d/name.bit
It'll be hard enough to get one TLD recognised. Is there much use for more than one?
-
- Posts: 801
- Joined: Sun Aug 18, 2013 8:26 pm
- os: mac
Re: Refactoring Namespace: d/name -> d/name.bit
Ahh, that's off topic for now : )John Kenney wrote:It'll be hard enough to get one TLD recognised. Is there much use for more than one?
DNS is much more than a key->value datastore.
Re: Refactoring Namespace: d/name -> d/name.bit
why? Should we like to add a tld some far time in the future it would get it's own namespace.indolering wrote:Has there been any discussion regarding refactoring d/name etc -> d/name.bit?
I would like to outline a proposal, but I can't imagine that this hasn't been pitched before. However, it's not a very google-able concept, I've only found some really old discussions relating whether we should enable multiple TLDs or not.
.bit is not fixed, could be we will be forced to use .b or something should ICANN not play along nicely. Support for alternate endings instead of .bit like ".b" for the same namespace were recommended by Vinced I think. Actually it would be nice if all implementations would work with .b today.
-
- Posts: 94
- Joined: Sat Mar 29, 2014 2:20 pm
- os: linux
- Location: Sheffield, England
- Contact:
Re: Refactoring Namespace: d/name -> d/name.bit
I think I agree with phelix, if we add another tld it should be for some subtly different purpose to .bit & get it's own namespace. It'll be easier than refactoring the blockchain to make it larger, adding '.bit' to every existing name in the blockchain.
Just use tld/name rather than d/name.tld
I think it should be a goal to get icann recognition for .bit. If we add too many other tlds needlessly it'll make that job harder, especially if they might conflict with any of the other new tlds that icann adds.
Just use tld/name rather than d/name.tld
I think it should be a goal to get icann recognition for .bit. If we add too many other tlds needlessly it'll make that job harder, especially if they might conflict with any of the other new tlds that icann adds.
Re: Refactoring Namespace: d/name -> d/name.bit
I also agree with the previous posters. The .bit ending should not be part of the name. If we want to have, as you mentioned, ICANN-compatible TLDs in the future, it makes sense to have them in their own name space anyway (so that we have different name spaces for purposes with different rules (ICANN vs decentralised)).
BTC: 1domobKsPZ5cWk2kXssD8p8ES1qffGUCm | NMC: NCdomobcmcmVdxC5yxMitojQ4tvAtv99pY
BM-GtQnWM3vcdorfqpKXsmfHQ4rVYPG5pKS
Use your Namecoin identity as OpenID: https://nameid.org/
BM-GtQnWM3vcdorfqpKXsmfHQ4rVYPG5pKS
Use your Namecoin identity as OpenID: https://nameid.org/
-
- Posts: 801
- Joined: Sun Aug 18, 2013 8:26 pm
- os: mac
Re: Refactoring Namespace: d/name -> d/name.bit
Aghh! I haven't made the proposal yet, I promise it will be a bit more compelling than "it makes more sense when you look at the API"
DNS is much more than a key->value datastore.