id/ format

[phelix]

I've updated the wikipage now. Note that disallowing double dashes prevents IDN names, but I can live with that for now. They don't seem to be too much in demand for now anyway, and we can revise the decision later. Please, can someone with the right permissions (however that is handled) mark the wiki page as "verified" (or whatever it is)?

I'll update the pull request shortly.

Are names starting with numbers prohibited now? Like id/1212sdaf ? I don't mind these.

No, I think they are allowed. (But look at the regex to be sure what exactly is allowed and what not. It should be the same in the code as on the id/ wiki page.)

I forgot about the namespace. So id/1231asdf is ok but 1232namespace/asdfsdf is not. I think that is reasonable or we can still modify it should the need come up.

[domob]

I forgot about the namespace. So id/1231asdf is ok but 1232namespace/asdfsdf is not. I think that is reasonable or we can still modify it should the need come up.

Exactly.

[John Kenney]

I'd rather keep the single space in my ID, it's my name, it has a space in & it was in the spec in the wiki page I read, I don't see a real reason to change that spec. Could allow middle names too, that'd help when multiple people with similar names register.

IMO, it's a name, so it should be formatted like one.

[domob]

I'd rather keep the single space in my ID, it's my name, it has a space in & it was in the spec in the wiki page I read, I don't see a real reason to change that spec. Could allow middle names too, that'd help when multiple people with similar names register.

IMO, it's a name, so it should be formatted like one.

I'm also slightly in favour of allowing spaces, but it seems the majority doesn't want this. However, it also depends on the actual implementation - currently, the "sendtoname" in Qt doesn't allow spaces (since this was the majority decision), but you can still use the names for NameID and other things. We could reevaluate the decision later on when more participants are interested in joining the discussion. But I can't speak for the whole team, of course, so take this as my personal opinion. (I have registered also some names with spaces, just so that noone can take them.)

[John Kenney]

Another thing to think about is international language characters. Might be better just escaping a few special characters & allowing most unicode rather than having a restrictive white-list, at least in the values stored under a name if not the names themselves. I'd rather keep my "id/John Kenney", I think it looks nicer, but I have it registered without a space too & 'id/jkenney' as well, so It doesn't really matter to me. I'd prefer a more liberal approach, if it ever gets popular then there will be lots of people with similar names, I wouldn't want to be johnkenney7896 because I was a latecomer. I'm not really that fussy though, just want a clear spec, there's the "name" value to write your name, the id/name is just an identifier.

As long as there's a clear spec then there shouldn't be too many security concerns? Maybe similar appearing .bit domains & dns compatibility is a problem? Maybe life would be easier if we just follow dns specs?

I'll just use my id/jkenney from now on, that should pass the most restrictive specs.

[mightbemike]

I think spaces are crazy. It's not good to just shrug and say that it's the end user's problem.

How does an application of some sort disambiguate if the string is embedded in text, e.g. email, document, forum post, etc

Code: Select all

please see id/myid T his id for my details

that whole text could correctly be interpreted as part of the id string, althogh it's probably not what the author intended

also did somebody say no double dash, '--'? This is needed for other language support via punycode, no?

[John Kenney]

I had a rethink. I think the easiest answer is to standardise all namespaces on something similar to DNS, for compatibility. Allowing names that aren't allowed in DNS will make it harder for programmers & users to deal with, being more restrictive would restrict the possible names too much. So, maximum 63 chars, case insensitive, no spaces, international characters using punycode, stick to DNS naming specs, there's no need to reinvent that part.

If we're going to have a standard then it should be enforced at the lowest level, hard fork, wipe out any names violating the standard & don't allow any future violations in the blockchain. We should probably think about enforcing valid json too. I just registered id/johnkenney so I have that as well as id/JohnKenney now, both with different values, how do DNS servers translate .bit domains if there are conflicts like that on d/ ?

[mightbemike]

I just registered id/johnkenney so I have that as well as id/JohnKenney now, both with different values, how do DNS servers translate .bit domains if there are conflicts like that on d/ ?

Wow that's not good - id/ names are case-sensitive? Imagine if that were true for d/

legacy DNS system treats all domain names case-insensitive

It's a really unpleasant thought to consider a blockchain system that distinguished between kenney.foo and KENNY.foo and Kenney.foo not to mention kenny.FOO

[domob]

I just registered id/johnkenney so I have that as well as id/JohnKenney now, both with different values, how do DNS servers translate .bit domains if there are conflicts like that on d/ ?

Wow that's not good - id/ names are case-sensitive? Imagine if that were true for d/

legacy DNS system treats all domain names case-insensitive

It's a really unpleasant thought to consider a blockchain system that distinguished between kenney.foo and KENNY.foo and Kenney.foo not to mention kenny.FOO

Names in Namecoin are simply case-sensitive - however, it is up to the application / namespace to interpret them accordingly. For d/, only all-lowercase names are actually treated as domain names. I. e., if you own d/google and I have d/gOOgle, then a correct resolver should always point to your domain no matter what the user enters (google.bit, gOOgle.bit, GOOGLE.bit, ...).

[phelix]

I just registered id/johnkenney so I have that as well as id/JohnKenney now, both with different values, how do DNS servers translate .bit domains if there are conflicts like that on d/ ?

Wow that's not good - id/ names are case-sensitive? Imagine if that were true for d/

legacy DNS system treats all domain names case-insensitive

It's a really unpleasant thought to consider a blockchain system that distinguished between kenney.foo and KENNY.foo and Kenney.foo not to mention kenny.FOO

Names in Namecoin are simply case-sensitive - however, it is up to the application / namespace to interpret them accordingly. For d/, only all-lowercase names are actually treated as domain names. I. e., if you own d/google and I have d/gOOgle, then a correct resolver should always point to your domain no matter what the user enters (google.bit, gOOgle.bit, GOOGLE.bit, ...).

IMHO the same should go for IDs. Because of id/Kingphisher