Quote from: dannotestein on April 04, 2014, 11:54:38 PM

Quote from: alt on April 04, 2014, 11:51:54 PM
thank you for the reply.
I am worried if you set rules too later, we have to register funder ID again. At least, we can set a more strict rule for funder ID register now, to avoid register again.

It shouldn't be a problem as all the rules we're contemplating shouldn't affect the founder id set we have.

OK,I agree with you.:)
I will register my funder id with Chinese name if I have. it's cool, especilly maybe the charset will be abondon later.

Quote from: alt on April 04, 2014, 11:51:54 PM
thank you for the reply.
I am worried if you set rules too later, we have to register funder ID again. At least, we can set a more strict rule for funder ID register now, to avoid register again.

It shouldn't be a problem as all the rules we're contemplating shouldn't affect the founder id set we have.

thank you for the reply.
I am worried if you set rules too later, we have to register funder ID again. At least, we can set a more strict rule for funder ID register now, to avoid register again.

Quote from: alt on April 04, 2014, 03:48:36 AM

Quote from: alt on April 03, 2014, 03:25:05 AM
Please disable case sensitive!!
and some other rules for the ID, like disable space.
you can ask toast, he had make some  rules for the  domain name.
It's a good chance!

It's very bad with no rules.
at least we should disable space, I can register a ID of "bytemaster " or "bytemaster               "
who want a ID system like this?

and we should disable utf8 charset
because too much special charset, like chinese space: "bytemaster　"

Case-sensitivity is already accounted for by the name_hash. You get different keys generated with different capitilization, but all the forms of the capitilization will hash to the same hash value, so it's not possible to have someone registered as Alpha and alpha in the blockchain itself. The choice of capitilization used during creation just sets the public key generated (this is why the ID creator should remember the capitilization he used). But phishing attacks based on trying to register Alpha and alpha won't work, since only one will be allowed to register (the first to try).

We're looking into using some ICU functions to eliminate the various unicode spaces in the calculation of the name_hash for keyhotee IDs. Ideally there will also be functions there for taking care of some of the common chars that could allow phishing attacks. This part is still a little fuzzy as we're going thru ICU docs now and they're not fun to read.

Right now we're leaning towards a RFC 3454-style StringPrep to scrub the unicode string, maybe stripping accent marks, then our usual processing of trimming, eliminating consecutive spaces, smashing case, and replacing similar-looking letters

 +5%

 +5%

Quote from: alt on April 03, 2014, 03:25:05 AM
Please disable case sensitive!!
and some other rules for the ID, like disable space.
you can ask toast, he had make some  rules for the  domain name.
It's a good chance!

It's very bad with no rules.
at least we should disable space, I can register a ID of "bytemaster " or "bytemaster               "
who want a ID system like this?

and we should disable utf8 charset
because too much special charset, like chinese space: "bytemaster　"