id/ format

[phelix]

Should spaces SINGLE spaces [edited] be allowed in the id/ namespace and sendtoname / sendtonameUI?

I think the benefit does not make up for the additional complexity...

To create a link you would have to do:
nmc:id/satoshi%20nakamoto or something

There is a good reason IMHO why there are no spaces allowed in eMail addresses.


Same goes for upper case in id/ from my point of view.

[domob]

I think that spaces can very well be allowed - currently, they are according to the wiki "spec". This allows for something like "firstname lastname", and IMHO, doesn't really cause many problems. If you want to format the ID as an URL, it is your own "fault" if this gets more complicated. (Apart from the fact that I don't really consider it to be too complicated, just an urlencode(). Client software like NameID should always use urlencode() anyway for security reasons when turning a user-provided name into an URL request parameter.)

[virtual_master]

There is a good reason IMHO why there are no spaces allowed in eMail addresses.
Same goes for upper case in id/ from my point of view.

I agree.

I think that spaces can very well be allowed - currently, they are according to the wiki "spec". This allows for something like "firstname lastname", and IMHO, doesn't really cause many problems. If you want to format the ID as an URL, it is your own "fault" if this gets more complicated. (Apart from the fact that I don't really consider it to be too complicated, just an urlencode(). Client software like NameID should always use urlencode() anyway for security reasons when turning a user-provided name into an URL request parameter.)

You can separate between names with underline or dot also.
We would only open a lot of new problems with space.
Just imagine somebody is giving a name with only spaces or with a lot of spaces between characters. In ID or in the reality. In the reality you also cannot use spaces in your name even if it looks cool.
Why should we confuse people ? Why should confuse some people other people ?
Not to speak about the amount of potential technical problems for what we don't have enough developers and testers.
And the security problems with new phishing threats. Even a security expert wouldn't know how to avoid them.

[domob]

We would only open a lot of new problems with space.
Just imagine somebody is giving a name with only spaces or with a lot of spaces between characters. In ID or in the reality. In the reality you also cannot use spaces in your name even if it looks cool.

Note that the id/ spec on the wiki explicitly mentions that only single consecutive spaces are allowed, and only in the middle of the name. This prevents the problems you are talking about here mostly.

[biolizard89]

I think including spaces will complicate implementation unnecessarily, which may introduce bugs (including but not limited to security bugs). I think using the underscore instead would be best, because the underscore is allowed in an identifier in almost all programming languages and formats. If we use an underscore, then url-encoding isn't necessary (it's not necessary for security purposes either assuming that you use a validation library such as NMControl to filter out invalid things). The underscore should still be subject to all the rules that the space is currently subject to (i.e. more than one underscore in a row is invalid).

[phelix]

Note that the id/ spec on the wiki explicitly mentions that only single consecutive spaces are allowed, and only in the middle of the name. This prevents the problems you are talking about here mostly.

Yeah, I clarified the OP about this.

I think including spaces will complicate implementation unnecessarily, which may introduce bugs (including but not limited to security bugs).

This. It would be nice to simply let the users decide about it but I see some (potential) security problems, too, especially with uri scheme support.

Send the coins to id/domaindealer and I will send you the name right away.

For normal users a space is something in between words and it's hard to grasp that it's just another character.

also: "id/evilknivel 12wnpfqydg5sungkhsemuftt6cembcgwcw" - could trick users into believing the address is displayed after the name.

I think using the underscore instead would be best, because the underscore is allowed in an identifier in almost all programming languages and formats. If we use an underscore, then url-encoding isn't necessary (it's not necessary for security purposes either assuming that you use a validation library such as NMControl to filter out invalid things). The underscore should still be subject to all the rules that the space is currently subject to (i.e. more than one underscore in a row is invalid).

I would prefer underscore to space, too.

[domob]

Ok, I'm fine with disallowing spaces if everyone else thinks this is best. But I wouldn't want the underscore, either. I think in that case, names like "id/firstname-lastname" are best, i. e., use a dash. This makes it consistent with d/. Also, IMHO it looks nicer than dashes.

[phelix]

Ok, I'm fine with disallowing spaces if everyone else thinks this is best. But I wouldn't want the underscore, either. I think in that case, names like "id/firstname-lastname" are best, i. e., use a dash. This makes it consistent with d/. Also, IMHO it looks nicer than dashes.

ACK

[biolizard89]

Ok, I'm fine with disallowing spaces if everyone else thinks this is best. But I wouldn't want the underscore, either. I think in that case, names like "id/firstname-lastname" are best, i. e., use a dash. This makes it consistent with d/. Also, IMHO it looks nicer than dashes.

The advantage of the underscore over the hyphen is that the underscore is allowed in an identifier in most languages, while the hyphen is often used as an operator. But, I don't feel that strongly about that one, particularly since id's can be invalid identifiers anyway since they can start with a numeral, so a hyphen is fine if you prefer it.

[domob]

Ok, I'm fine with disallowing spaces if everyone else thinks this is best. But I wouldn't want the underscore, either. I think in that case, names like "id/firstname-lastname" are best, i. e., use a dash. This makes it consistent with d/. Also, IMHO it looks nicer than dashes.

The advantage of the underscore over the hyphen is that the underscore is allowed in an identifier in most languages, while the hyphen is often used as an operator. But, I don't feel that strongly about that one, particularly since id's can be invalid identifiers anyway since they can start with a numeral, so a hyphen is fine if you prefer it.

That's true, but my reasoning is that (besides underscore looking bad in my opinion) IDs actually aren't supposed to be identifiers in some programming language, but "names". And the closest existing thing to "names" that makes sense, is for me the DNS (either existing or d/). For domains, dash is preferred over underscore. Besides, allowing "-" means that IDN names can be used in theory, if we want to support that in the future. (Although this may of course introduce problems with similar looking characters. How's that solved with domain names and phishing, BTW?)

If everyone agrees, I'll update both my pull request for "send-to-name" and the id/ wiki page. So, to summarise, we want to allow [a-z0-9-] as characters in id/ names, right? Nothing else, and no spaces.