AP => Bluesky: support usernames that begin or end with `_`, `-`, or `~`

[snarfed]

We currently convert these characters to -, which ATProto allows in the middle of handles, but not at the beginning or end.

Fediverse usernames that begin or end with these characters are rare, but definitely exist. Examples in #982.

Users need to translate handles themselves in order to search for users across the bridge, so I'm trying to keep that translation UX as simple as possible. Barring a more complicated translation process, I don't yet have a good idea for how to support these usernames.

[qazmlp]

It's a bit out there, but maybe IDNA2008 could work here (also for internationalisation)? The Bsky names are supposed to be domain names, after all, and rendering IDNs at least for supporting TLDs may be something desireable on their end too.

Unicode has a good FAQ with a bunch of links here: https://www.unicode.org/faq/idn.html
The easiest option would be to just use an IDNA2008 library, though.

The scheme isn't pretty, per se, but iinm it keeps the ascii-part of the handle readable, at least, and is unambiguous.

[snarfed]

Oof. The use case is, a Bluesky user sees someone in the fediverse, and they want to find and follow their bridged account on Bluesky. To do that, they need to manually translate the fediverse address into a bridged Bluesky handle. Punycode, IDNA2008, etc are useful, but not human-usable for that use case.

[qazmlp]

Right, but this is something they wouldn't be able to do anyway with any sort of non-trivial mapping, which you'd need to cover more than a very limited set of cases. They'd have to use https://fed.brid.gy/ to look up the account (once the request function is online), and that can do a complex conversion for them easily.

(You could still give out ambiguous mappings on a first-come-first-serve basis, of course, but personally I use such characters starting/trailing especially when the plain name is taken, so collisions seem decently likely to me.)

Bsky also indexes users by display name, so such-translated bridged users would most likely still appear quickly in search there. I can't test this since my display name is also my handle, but the bridged account is clearly indexed and others do show up in search for their display name specifically.

[h-2]

My main account on Mastodon is __h2__@mastodon.social so I'd be very interested in the problem getting resolved!

On a related note: could I use a regular domain I own as my BSky handle for the bridged Fedi account? I think the documentation only covers the other way around...

[snarfed]

On a related note: could I use a regular domain I own as my BSky handle for the bridged Fedi account? I think the documentation only covers the other way around...

Hopefully eventually! That's #826

[Tamschi]

https://fed.brid.gy/docs#troubleshooting still links to #982 for unsupported handles instead of this one.

#826 is now implemented, but if I'm not mistaken that flow requires the account to already be bridged, so it doesn't work for account currently blocked by this issue here.

[snarfed]

https://fed.brid.gy/docs#troubleshooting still links to #982 for unsupported handles instead of this one.

Fixed, thanks for the nudge!

#826 is now implemented, but if I'm not mistaken that flow requires the account to already be bridged, so it doesn't work for account currently blocked by this issue here.

True!

[Tamschi]

What do you think about letting users allocate a DID and set up a custom handle without bridging the account yet?
That would work around the issue here quite nicely without making the default handle mapping more complicated.

You could work that suggestion into the error message for accounts not supported plainly. (#758, just to cross-reference)

[snarfed]

Definitely possible!

[tesaguri]

Would Bluesky accept DIDs with "alsoKnownAs":["at://handle.invalid"], or "alsoKnownAs": null? If so, I think BF could not only let users allocate a DID, but also start bridging their account right away without allocating a handle (of course the Bluesky Social app would display "⚠Invalid Handle" though).

[snarfed]

@tesaguri interesting idea! I think that should work, yes.