Yeah, this is definitely something that I'm finding to be a problem overall with ActivityPub, though, interestingly, some AP authors are arguing that we shouldn't actually have handles (yes, really), rather than just fixing how we do handles to make actual sense. icy.leaflet.pub/3m47cll72hs2...

Why in the world would a social media protocol not have handles??? Who is arguing this? (I'm genuinely interested in who is arguing that and why.) Also curious, does Bluesky hardcode the handle into the mention within a skeet or does it include an ID to the user account?

The references to everything use your DID (which can't change) and the handle is pretty much only for display purposes, not so much resolution. (you can resolve a handle to a DID, but when transmitting data you always use the DID and not the handle)

which is bad design as it makes switching from PLC to WEB or something else much harder and breaking

Please do say what stable identifier you'd use instead, because without an alternative, this statement is pointless

A globally unique ID generated with enough factors (initial service / PDS name, timestamp, name..) to be reliably unique

what do you think a DID is?

That isn't what the discussion is about. It's that Bluesky's links are designed in a stupid way where changing the DID method breaks virtually everything, and the PLC DID method is deliberately centralised and in Bluesky's hands

oh and you cant change the DID method even if you wanted for all I know, talk about vendor lock in

right, but the likelihood of changing the DID method is next to none. There's literally no other identifier you could use that would give you the same properties, because you need to be able to resolve the identifier *somehow*

did:web exists and is widely used elsewhere. In my eyes it's deliberately designed to force you to forever stay on Bluesky's PLC bullshit. Peak centralisation in an otherwise genuinely perfectly decentralised protocol. No clue how that went through even the first idea phase

and thats what i said earlier. Use that globally unique unchangeable ID and done. That is literally the solution

did:web is _terrible_ tbh, since it relies on retaining domain names indefinitely. (that's $$), plus it doesn't keep a history for the DID, did:webvh is marginally better, but even then, you're still dealing with DNSSEC as the primary security mechanism which is generally well beyond most people.

You loose all your posts when you change your identity on Mastodon (they stay on the old server), all past interactions point to your old server. If you "moved" your posts to your new server, you'd be doing a copy of them, because everyone's `@id` values in JSON-LD documents would be pointing wrong