Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
snarfed opened this issue May 5, 2024 · 11 comments
Open

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

snarfed opened this issue May 5, 2024 · 11 comments
Labels
compat Protocol differences that need special handling.

Comments

@snarfed
Copy link
Owner

snarfed commented May 5, 2024

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
Copy link

qazmlp commented May 5, 2024

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
Copy link
Owner Author

snarfed commented May 5, 2024

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
Copy link

qazmlp commented May 5, 2024

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.

@snarfed snarfed changed the title AP => Bluesky: support usernames that begin or end with _,-, or ~ AP => Bluesky: support usernames that begin or end with _, -, or ~ May 5, 2024
@h-2
Copy link

h-2 commented Sep 20, 2024

My main account on Mastodon is [email protected] 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
Copy link
Owner Author

snarfed commented Sep 20, 2024

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 Tamschi added the compat Protocol differences that need special handling. label Oct 31, 2024
@Tamschi
Copy link
Collaborator

Tamschi commented Nov 16, 2024

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
Copy link
Owner Author

snarfed commented Nov 16, 2024

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
Copy link
Collaborator

Tamschi commented Nov 16, 2024

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
Copy link
Owner Author

snarfed commented Nov 16, 2024

Definitely possible!

@tesaguri
Copy link

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
Copy link
Owner Author

snarfed commented Nov 30, 2024

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
compat Protocol differences that need special handling.
Projects
None yet
Development

No branches or pull requests

5 participants