Internationalization & Localization about stacks HOT 8 CLOSED

Namespace

Interesting, currently we use the existing DNS character set (latin alphanumerics plus dashes) to save space in the blockchain. So instead of embedding each domain character in a byte and working in ascii/base 256, we're compressing the information into base 40, which let's us pack 1.5x the characters (so domains can be something like 24 letters max instead of just 16).

Do you think it would be valuable to use bytes instead? This would allow for all ASCII characters to be encoded, and with a special encoding it could be easily extended to unicode.

Multiple Languages

Hm, I like the latter as well. One way to do this would be to include an object within the top-level object called something like "translations" or "language" that provides the translated names in other languages along with their mappings.

Branding & Communications

Yes, I agree that we need to be cognizant of making sure our branding and communications translate well across languages. Looks like we're mostly set on passname, but that should translate ok right? Doesn't have to be an exact one. Also, as you mentioned in the other thread, we can use various carefully chosen phrases to describe it.

from stacks.

Do you think it would be valuable to use bytes instead? This would allow for all ASCII characters to be encoded, and with a special encoding it could be easily extended to unicode.

It could make sense if our goal is to support all unicode characters. Supporting all unicode characters leads to other complexities like homograph attacks and how (if?) we want to try to prevent them (say by excluding confusables from the namespace).

from stacks.

Hm, yeah because of homograph attacks, I don't think this can work, even by excluding confusables. It's just too hard of a task and the attack space is so large there'll always be something you miss.

Also, even if we figured it out, I just realized that we want this name system to be backwards compatible with ICANN DNS, so we need to support the same character set or a subset of those characters.

Moreover, it'd be ideal just to use the same rules and encodings as the existing system. There are a ton of advantages of this. Thus I'd make the case for going with byte encoding in blockstore and limiting the valid character set to alpha-numeric-dash (just like ICANN DNS).

In ICANN DNS, a peace sign is encoded as xn--7bi, so the domain would look like this: xn--7bi.com (which redirects to angel.co). The same would go for our TLDs, so it's really simple to add native browser support for them.

from stacks.

IDN is still poorly implemented and therefore not that widely adopted. Case in point: iOS mail app bug below: 7bi.com definitely doesn't forward to angel.co

Just to make sure I understand, are you suggesting at some point Passcard will use IDN encoding like ICANN DNS? If so, will we see the same rather "lazy" (slow, sloppy) implementation in the ecosystem?

Or are you saying we should stick with ^[a-z0-9_]{1,60}$?

It's just too hard of a task and the attack space is so large there'll always be something you miss.

Yes. Too complicated.

from stacks.

Some of the reasons we don't use unicode in name registrations:

1. The main reason is that we want to be backwards compatible with existing DNS infrastructure which uses Punycode to store unicode characters in ascii names
2. When we designed this, bitcoin's OP_RETURN size was 1/2 as big and unicode characters take up a lot more space which means would have been limited in length.
3. Uniqueness in internationalize names is a very hard problem: should 中國 be consider as the same or different name than **？To users reading them they are the same, but to computers they are different names.

from stacks.

On the topic of uniqueness being a challenge in the full unicode space - this is a problem in the latin alphabet as well which is why DNS names (and our names) are not case sensitive. LaRrY.iD is the same as larry.id.

from stacks.

Issue moved to blockstack/blockstack-core #904 via ZenHub

from stacks.

Issue moved to blockstack/blockstack-core #905 via ZenHub

from stacks.