Bluesky => fediverse: simplify *.bsky.social handles

[KDederichs]

Hey,
dunno if anyone ever asked but would it be possible to simplify handles a bit? (I'm asking cause a lot of people seem to be put off by those really long handles).

I was thinking that it should be possible to just omit the bsky.social part on your end making the fedi handle @[email protected] instead of @[email protected] (like 50% character reduction).

Obviously that only works with standard bsky.social headers but it should be fairly simple to just fall back to that if the handle has no other domain part (maybe you can even just match for a . in there)

[snarfed]

Yes! Great idea. I like it.

One drawback is that it makes it more complicated to determine a Bluesky account's fediverse handle. Not too bad though, still reasonable.

(Another drawback is that if someone ever uses a bare TLD as their Bluesky handle, eg just com, they'd collide with the corresponding com.bsky.social handle. Technically possible, there are lots of TLDs, but I think the odds of it happening are more or less zero.)

[KDederichs]

Yeah the Bluesky -> Fediverse handles are especially bad. If one could simplify those as well somehow that would be fantastic. (Mine is like ladon.mastodon.ladon-dragon.net.ap.brid.gy which is just ridiculous tbh)

I don't know how feasible it is but maybe there could be some sort of alias system where account holders can request a shorter handle on brid.gy maybe?

Maybe something like DM the bridge bot with the desired handle "Assign alias: foo" or something and then you'll get foo.bird.gy (if that's free)
Honestly a bit like NickSrv on IRC.

[snarfed]

Yes! The answer there is #1150, I'm hoping to work on that soon.

[Tamschi]

(Another drawback is that if someone ever uses a bare TLD as their Bluesky handle, eg just com, they'd collide with the corresponding com.bsky.social handle. Technically possible, there are lots of TLDs, but I think the odds of it happening are more or less zero.)

I just noticed this while looking the syntax up for another issue, but ATProto doesn't allow bare TLD handles, so there is no collision risk in that regard: https://atproto.com/specs/handle#handle-identifier-syntax

[snarfed]

Aha, "there must be at least two segments," true, thanks!

[tesaguri]

This is a rather philosophical question, but should Bridgy Fed really bless *.bsky.social handles, when even the official bsky.app client doesn't do that? I feel like that would discourage users from using custom domain handles on the atproto side.

If you still want shorter Fediverse usernames, can you consider a more generalized rule, e.g., allowing owners of foo[.sld].tld apex domains to take the @[email protected] Fediverse username on a first-come-first-serve basis, and treating bsky.social as if it's an effective TLD (although it's not on the Public Suffix List (yet))? (Not that I like this idea either. This is just a contrived example.)

[snarfed]

Philosophical indeed!

You're right that bsky.social isn't special in AT Protocol itself. It very clearly is special in the real world, however. It's run by the Bluesky team, it's the default PDS for new users (at least in the main client app), and it's where the vast majority of all users currently are.

I have no plans to actually implement this any time soon, but if I do, I'd probably be ok with "blessing" bsky.social, and I have no illusions that if I did, it would have much meaningful additional impact on how decentralized Bluesky is in practice.

And a generalized rule like you mention is interesting! The problem is that it would make the bridged fediverse handle for a given Bluesky user nondeterministic. Bridging is already hard enough for many users to understand as it is; I'm reluctant to do anything that would complicated its UX even more.

[Tamschi]

There's also something else to consider here, which is:

Should Bridgy Fed expose distinct ATProto apps (Bluesky, WhiteWind, Smoke Signal, picosky?, Linkat?) that use the same DID under a single shared Fediverse account?

On both networks, you currently (usually) only see only one app's activity when looking at another account:

• On ActivityPub, this is because each identity (with very few exceptions) is managed by only one application, so while many distinct apps are interoperable to an extent, users often have several distinct identities and you can follow them separately to select which stream you want to see.

• On ATProto, while users have a shared DID between multiple applications, the apps usually aren't interoperable. Notably, Bluesky follows are app.bsky.graph.follow, so they are in an app-specific lexicon. I would have to ask the ATProto maintainers, but to me this suggests the follow graph may well differ between different apps. It seems ATProto itself doesn't have a concept of what it means to follow someone.

  Additionally, ATProto apps sometimes have their own profile records: events.smokesignal.app.profile, app.bsky.actor.profile.

Currently, Bridgy Fed processes only app.bsk…. top-level records, if I'm not mistaken. If we want to in the future bridge e.g. Gancio ⇄ Smoke Signal, should the smoke signal activity get mixed into the Bluesky posts under @<handle>@bsky.brid.gy or does it make more sense to have it under e.g. @<handle>@ss.brid.gy and WhiteWind posts under @<handle>@ww.brid.gy?

To me it seems a little more sensible to shorten a handle on its native app than otherwise. But on the other hand, if Bluesky goes under then the lexicon and @bsky.brid.gy would stick around while the @….bsky.social handles are at least somewhat less likely to. (Of course in an ideal world Bridgy Fed could cheaply switch over the preferred ActivityPub usernames if needed to shorten a different pattern, but at least currently that's not where the majority of AP observers is at in terms of implementation.)

[snarfed]

Philosophical indeed! Love it. Thanks for the writeup @Tamschi! You're right about the protocol-level details here, eg follows and profiles are app-specific, not protocol-wide. (DIDs and handles themselves are protocol-wide, of course, but that's a different point.)

I hope we do eventually support more ATProto apps! ...but I haven't thought through the details at all, at least no more than #1178 a while back. Probably a good candidate for a dedicated issue! Either expanding #1178 or separate new one.