From what I understand even in the federated mode all accounts have to be verified by a central server?
Not all, but currently most are. The long-term account identifiers are DIDs, and they currently support two DID methods: the w3c-standardized did:web method (which makes your identity reliant on your DNS name), and bluesky’s centralized did:plc method (which gives you a verifiable cryptographic identity not reliant on you keeping a domain renewed, but which they are responsible for the availability of and could censor).
The log of all operations on the centralized did:plc server is public and auditable, though, so, if i understand correctly, if/when they do censor it that can be detected and people can/will make the various components of the system use uncensored mirrors of it to continue using censored did:plc identities. And other people will choose to use did:web for their identities and be subject to the DNS rules instead (and this choice will be invisible to other users; all implementations are expected to support both methods).
In my opinion, the decoupling of long-term identity from everything else (including your display name, which is also DNS-based but can be changed at any time) is a pretty good idea, and I expect they’ll probably support more than these two DID methods in the future.
Thank you for the explanation. I’m curious what this will look like in the UI and UX. did:web doesn’t seem like something that the majority can/will use. It makes on easily identifiable by DNS (probably even with whois protection).
Not all, but currently most are. The long-term account identifiers are DIDs, and they currently support two DID methods: the w3c-standardized
did:webmethod (which makes your identity reliant on your DNS name), and bluesky’s centralizeddid:plcmethod (which gives you a verifiable cryptographic identity not reliant on you keeping a domain renewed, but which they are responsible for the availability of and could censor).The log of all operations on the centralized
did:plcserver is public and auditable, though, so, if i understand correctly, if/when they do censor it that can be detected and people can/will make the various components of the system use uncensored mirrors of it to continue using censoreddid:plcidentities. And other people will choose to usedid:webfor their identities and be subject to the DNS rules instead (and this choice will be invisible to other users; all implementations are expected to support both methods).In my opinion, the decoupling of long-term identity from everything else (including your display name, which is also DNS-based but can be changed at any time) is a pretty good idea, and I expect they’ll probably support more than these two DID methods in the future.
Thank you for the explanation. I’m curious what this will look like in the UI and UX.
did:webdoesn’t seem like something that the majority can/will use. It makes on easily identifiable by DNS (probably even with whois protection).We shall see how it pans out.