Syntax Highlighting for Handles

[coreh]

Hey there 👋 I would like to propose this as an alternative to #5155 and #5117.

Instead of hiding the domain-like structure of the AT Protocol handles, or special-casing bsky.social or other “well-known” suffixes, this PR aims to make handles more glanceable, and to help users eventually build an intuition about the structure/role of handles in a decentralized social network. It also aims to make at least a subset of domain spoofing attempts (malicious or not) obvious to the user.

Storybook

How it works

We introduce a new HighlightedHandle component, that only renders Text elements, and can therefore be used as a drop-in solution almost anywhere sanitizeHandle() is currently used. This component uses straightforward rules to split a handle into up to three parts: a prefix, a suffix, and a spoof, and applies syntax highlighting. The tldts module is added as a new dependency and is used, along with the existing tlds module, to help with the splitting.

Splitting Rules

• Handles directly under a public (ICANN) domain, regardless of nesting level (e.g. .com, .co.uk, .mg.gov.br) are entirely comprised of the prefix, with no suffix.
• Handles under a private (non-ICANN) domain, have the “deepest” (leftmost) portion as the prefix and everything else as the suffix.
• Suffixes that have a beginning portion that looks like it's under an ICANN domain (but isn't) are split, with the first part being marked as a spoof, and the rest remaining as a suffix.

What this (hopefully) teaches users

• Handles are hierarchical/composed of multiple parts, not unlike email addresses or first/last names
• You should pay attention to those parts
• Handles under private domains represent a “shared” space or community
• Multiple of those shared communities exist
• Handles directly under a TLD or nested public (ICANN) domain stand out and represent some type of (context-dependant) “authority”/"legitimacy"/"verification"/"independency"
• If you want that for your handle, you should/could get or configure a domain name
• Some handles may have parts that look like other domains, but are in fact not associated with those domains
• Multiple handles might have the same prefix but different suffixes

Screenshots

Prior Art

This very much like the URL syntax highlighting provided by web browsers, but with the reverse “focus” on the subdomain instead of the domain part, and a different treatment of public/private domains.

Questions

Do we want to consider non-ICANN but otherwise “public” domains (e.g. .github.io, vercel.app) just like their ICANN counterparts? This is supported by tldts, we just need to set the allowPrivateDomains option to true. Might be more “technically consistent” with how DNS verification is set up, and potentially more inclusive to users on free webhosts who can't afford domains... But feels “weird” and might be confusing to users, who might not understand why these specific handles are not highlighted.

[danninov]

Thanks for the idea. However, this is seems too complex, multiple rule and would add cognitive burden for user, why some user has full handle without highlight etc. Especiallye for this:

What this (hopefully) teaches users

Handles are hierarchical/composed of multiple parts, not unlike email addresses or first/last names
You should pay attention to those parts
Handles under private domains represent a “shared” space or community
Multiple of those shared communities exist
Handles directly under a TLD or nested public (ICANN) domain stand out and represent some type of (context-dependant) “authority”/"legitimacy"/"verification"/"independency"
If you want that for your handle, you should/could get or configure a domain name
Some handles may have parts that look like other domains, but are in fact not associated with those domains
Multiple handles might have the same prefix but different suffixes

No, this would not help teach user, instead will more confusing them. Don't expect common user knew what's TLD, ICANN etc. Too complex without bring any value other than cosmetic improvement.

If this is a part of third-party app then it would be much understandable then forcing this to main and default app for most user.

[shana]

This is not a great idea. With this PR, shana.spoiledcat.com and shana.mastodon.social.ap.brid.gy will both be highlighted as "shana", visually hiding the actual important information from the user. This will teach users to ignore the part after the handle - the actual distinct part that makes them unique - making spoofing much easier, and will have the opposite effect of what you're trying to do here.