Bluesky’s federation model is actually quite interesting, they go for a very portable approach vs activitypub’s instance-basis. Unfortunately, there’s still a massive centralization point (the main relay, the only thing that can really handle the firehose), and identity is also centralized, albeit has mechanisms to be decentralized.
I believe that’s your handle, not your identity. Your handle resolves to your identity, but your identity isn’t directly tied to it, in case you lose the domain.
While they definitely do this for handles I’m pretty confident this is also done for DIDs (Decentralized identifiers) and it doesn’t provide a solution if you lose your domain. I think Bluesky (Appview) specifically gets around this by also tying your DID:web to your DID:plc, in case of domain loss. So I think it exists on the protocol but they don’t automatically utilize the decentralization for end-user experience(domain loss) but other appviews can. But I could be wrong.
Yeah, did:web exists, but I still called it centralized because it still relies on did:plc pretty much everywhere (though honestly domain name handles might actually be did:web, not sure). Didn’t know about that dual setup by Bluesky though!
Bluesky’s federation model is actually quite interesting, they go for a very portable approach vs activitypub’s instance-basis. Unfortunately, there’s still a massive centralization point (the main relay, the only thing that can really handle the firehose), and identity is also centralized, albeit has mechanisms to be decentralized.
Aren’t identities already decentralized by using domains you own as your identity? Ex. Incase you’re unfamiliar, my Bluesky @ is my domain I own.
I believe that’s your handle, not your identity. Your handle resolves to your identity, but your identity isn’t directly tied to it, in case you lose the domain.
While they definitely do this for handles I’m pretty confident this is also done for DIDs (Decentralized identifiers) and it doesn’t provide a solution if you lose your domain. I think Bluesky (Appview) specifically gets around this by also tying your DID:web to your DID:plc, in case of domain loss. So I think it exists on the protocol but they don’t automatically utilize the decentralization for end-user experience(domain loss) but other appviews can. But I could be wrong.
https://atproto.com/specs/did
Yeah, did:web exists, but I still called it centralized because it still relies on did:plc pretty much everywhere (though honestly domain name handles might actually be did:web, not sure). Didn’t know about that dual setup by Bluesky though!