Right. Also no "-" as first/last or "--"domob wrote: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.
In the end security comes down to correctly reading a word. To make this as simple as possible these rules should also go for domain names IMHO. Note that my native language does have some fancy characters but I just don't want anybody to be able to go fishing with kräken.bit and the like.