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*

like, if you said all the at:// URIs are: at://<universally unique identifier>[/<collection>[/<rkey>]] Then you'd need some way to resolve that universally unique identifier. What's your mechanism for doing that? You need *some* anchor point for that.

DNS solved this kind of issue 41 years ago and it's a fucking shame that modern software needs to reinvent the wheel, as a square

Even if you used DNS via did:web, you still wouldn't be able to change from one did:web to another. And that's a lot more likely of a change given how domain name registrars work, especially with ccTLDs where they can literally sell them whilst you still own them, before you've had a chance to renew

No. What I mean is a DNS-like system for the globally unique IDs I proposed, where information of where the user is stored (which PDS) is relayed and the user's current PDS is the result, if that makes sense. Basically makes the did secondary only.

That way, not a domain or a PLC would hold the truth, but the user's PDS. There surely are some loopholes and issues with that but I can't get over how unnecessarily restrictive bluesky did it by locking you into PLC

How do you find the user's PDS when you don't know who the user is. I give you a record that has a link in it of: at://did:key:z6MkrJVnaZkeFzdQyMZu1cgjg7k1pZZ6pvBQ7XJPt4swbTQ2/app.bsky.feed.post/3lxd54zft7k2s How do you locate the PDS that holds that data?