id/ format
id/ format
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.
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.
Re: id/ format
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.)
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: 541
- Joined: Mon May 20, 2013 12:03 pm
- Contact:
Re: id/ format
I agree.phelix wrote: 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.
You can separate between names with underline or dot also.domob wrote: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.)
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.
http://namecoinia.org/
Calendars for free to print: 2014 Calendar in JPG | 2014 Calendar in PDF Protect the Environment with Namecoin: 2014 Calendar in JPG | 2014 Calendar in PDF
BTC: 15KXVQv7UGtUoTe5VNWXT1bMz46MXuePba | NMC: NABFA31b3x7CvhKMxcipUqA3TnKsNfCC7S
Calendars for free to print: 2014 Calendar in JPG | 2014 Calendar in PDF Protect the Environment with Namecoin: 2014 Calendar in JPG | 2014 Calendar in PDF
BTC: 15KXVQv7UGtUoTe5VNWXT1bMz46MXuePba | NMC: NABFA31b3x7CvhKMxcipUqA3TnKsNfCC7S
Re: id/ format
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.virtual_master wrote: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.
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: 2001
- Joined: Tue Jun 05, 2012 6:25 am
- os: linux
Re: id/ format
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).
Re: id/ format
Yeah, I clarified the OP about this.domob wrote: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.
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.biolizard89 wrote:I think including spaces will complicate implementation unnecessarily, which may introduce bugs (including but not limited to security bugs).
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 would prefer underscore to space, too.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).
Re: id/ format
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.
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/
Re: id/ format
ACKdomob wrote: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.
-
- Posts: 2001
- Joined: Tue Jun 05, 2012 6:25 am
- os: linux
Re: id/ format
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 wrote: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.
Re: id/ format
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?)biolizard89 wrote: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 wrote: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.
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.
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/