Bluesky => AP: custom usernames in handles

[snarfed]

Some people who bridge a Bluesky account into the fediverse would like to use their own domain for the handle (#1150), eg @mydomain.com@mydomain.com instead of @mydomain.com@bsky.brid.gy. Some of those people would like to go further and choose their username too, eg @alice@mydomain.com.

We technically support this for web => fediverse right now, https://fed.brid.gy/docs#different+username , but it's been a bit brittle and problematic over time. Still, we could extend it to Bluesky => fediverse.

The key question is how a Bluesky acount would set their custom username. From https://github.com/snarfed/bridgy-fed/issues/1150#issuecomment-2219149924 :

Agreed. Bio is awkward and annoying, DNS or HTTP is inaccessible, authed UI is a burden on my end. I haven't heard a good easy (or at least not hard) answer yet. 🤷

cc @frncs-eu @elfprince13

[snarfed]

Re https://github.com/snarfed/bridgy-fed/issues/1150#issuecomment-2237814717 :

I'm curious, why is DNS/HTTP inaccessible? ... What @elfprince13 proposes about checking some configuration file from domain.tld sounds ok to me and similar to what Bluesky already does. I don't know if it is technically impossible, the doc for the website -> AP bridging mentions a similar approach using the .well-known path but surely you know why it can't be used in this scenario and I don't 😛

Setting up custom DNS records is very technical. Serving a web site on a custom domain is less technical, but still some. Having said that, you'll only be able to use a custom username if you've already set up a custom domain, which requires serving .well-known redirects, which is also somewhat technical.

If I choose a way for Bluesky users to set a username for their custom fediverse handle, I'd look for a single, simple, easy, non-intrusive mechanism. I don't love any of the options I've heard so far, but they're all possible.

[mackuba]

authed UI is a burden on my end

What if it was an authed UI, but a pure-frontend one (HTML + JS) that logs in to the Bluesky PDS and creates a custom record of type like gy.brid.bsky.handle or something, and then you listen for those records from the firehose? That way you pass info from the (authenticated) user to your db, but indirectly, and you don't have to keep any tokens or something or even verify anything. It would log in like you log in to Skythread, just making XHR requests to createSession and createRecord on the PDS, from a HTML page with no backend. Would that be easier? (I'm considering doing something like this with some custom feeds I'm thinking about, where you'd log in to Skythread, set some options for the feed there, which would create custom records, and the feed server would get those records from the firehose.)

[snarfed]

Interesting! Could work. But overall complexity is probably even higher than a normal UI built into BF itself, and even if someone else built the UI, realistically I'd still be responsible for maintaining it long term, at least indirectly if not directly.

Honestly I don't really plan to think about this much until #1150 is done. Hopefully eventually!

[frncs-eu]

What about tagging the bridgy user in a post with a custom command? Like the TTRpg labeler does... No UI involved whatsoever Is it terrible?

[qazmlp]

A few labelers can be controlled via DM on Bluesky now (the flag and pronouns ones), which is probably preferable to public tags. It's not terrible, but not great without Telegram-like multiple choice chatbot UX.

I think it would be usable if there was a /help command to list what's possible.

[frncs-eu]

A few labelers can be controlled via DM on Bluesky now (the flag and pronouns ones), which is probably preferable to public tags. It's not terrible, but not great without Telegram-like multiple choice chatbot UX.

I think it would be usable if there was a /help command to list what's possible.

Uh, yeah, DMs are better, not polluting the public timeline. My only doubt is DMs are currently a temporary, off-protocol implementation and monitoring the change in order not to break the functionality when they switch to the e2e/in protocol implementation sounds like a hassle. But we're probably talking months/years from now at current development rate. I think this is the best solution we have so far!

[snarfed]

Agreed! Especially now that we support DMs/chat for other things, adding functionality like this is easier.