First class support for non-latin characters.

[Spacedesolate]

Despite how popular and mainstream Twitter was (until recently) in the anglosphere, it has small userbase and barely manages to rank in top 20 social platforms.

I think for @ protocol to be global and ubiquitous network, it is necessary to have first class support for non-latin characters everywhere including @Handles. Many tech companies/ISPs would also take an interest in federating in other countries, if they can provide a network with better accessibility to their end users.

Switching keyboards in an annoyance on mobile devices, but is a major headache on PCs and laptops (which frequently have weird outdated layouts), so I hope dev team for the protocol has this understanding when they develop and test the protocol.

Thanks for reading.

[morrisallison]

Here's some relevant information:

tldr; The AT protocol itself accepts non-latin characters, but applications will have to detect and parse punycode handles for display.

AT Protocol Handles

The overall handle must contain only ASCII characters, and can be at most 253 characters long (in practice, handles may be restricted to a slightly shorter length)
https://atproto.com/specs/handle#handle

Internationalized Domain Names ("IDN", or "punycode") are not directly relevant to the low-level handle syntax. In their encoded form, IDNs are already valid hostnames, and thus valid handles. Such handles must be stored and transmitted in encoded ASCII form. Handles that "look like" IDNs, but do not parse as valid IDNs, are valid handles, just as they are valid hostnames. Applications may, optionally, parse and display IDN handles as Unicode.
https://atproto.com/specs/handle#usage-and-implementation-guidelines

XRPC strings

Strings are Unicode. For non-Unicode encodings, use bytes instead. The basic minLength/maxLength validation constraints are counted as UTF-8 bytes.
https://atproto.com/specs/lexicon#string

[morrisallison]

Separate from the AT Procotol, Bluesky posts should be associated with a language.

atproto/lexicons/app/bsky/feed/post.json

Lines 32 to 36 in d96f7d9

	"langs": {
	"type": "array",
	"maxLength": 3,
	"items": { "type": "string", "format": "language" }
	},

[pfrazee]

This is correct -- punycode is how handles will support non-english characters. We haven't baked support for that into the app yet because there are difficult phishing concerns, but we will almost certainly add support at some point in the future

[pfrazee]

Phishing may be a confusing term to use for this: more like "impersonation" concerns.

Here's a somewhat obvious example: paul versus pául

[Jofre]

Almost a year later, are there any news about this? Is punycode support for handles still in the works?

Not for any real accessibility reason, but I just think it would be cooler to have jofre.çç.cc as a handle rather than jofre.xn--7caa.cc

Ideas to minimize phishing:

• use a different color if the handle contains punycode
• add a hover tooltip showing the raw punycode

Additionally:

• preemtively ban known phishing domains
• preemtively ban domains that are clearly designed to be used for phishing (i.e. xn--bk-vmc4e.social, which is bѕkу.social as opposed to bsky.social)

---

This seems like it would be better categorized under client app rather than protocol (the protocol uses punycode like everything else). I don't think I have the right permissions to change the category.