You’re using the British definition of “public school” here, which is a “private school” in the US. US public schools are equivalent to UK state schools, in that both are run by the state.
DID is basically one extra level of abstraction, allowing for different methods.
did:web: eg is literally HTTP, did:dns: is DNS, and there’s loads of others.
This extra level of abstraction allows of arbitrary IDs, which is what the PLC DIDs were created for.
Let’s say that I am currently known as rmccue.com.au. I move overseas and now want to be rmccue.scot - or worse, because I am no longer in .au, I can’t even keep my old domain name. How do you persist this identity?
With PLC, I can instead be an abstract did:plc:hv27plmlx6zkuv7bnzbqb6xr (an arbitrary hash of the genesis entry for my DID). I associate rmccue.com.au with this via a TXT record, and back the other direction by recording the domain as an alias.
If I change my handle, I’m still the same arbitrary handle everywhere, everyone keeps following me, and in theory old references to my alias could even continue resolving.
(Similarly, this solves the issue for trademark changes, name changes throughout a person’s life, and changing job roles.)
There’s some DHT-based DID methods so it’s possible - one of the nice things about the DID abstraction layer is that could be added.
As I understand, atproto is intentionally limiting to PLC and Web for now, and monitoring the ecosystem. Every method has to be implemented by every client, so you naturally want to be cautious in how many you support.
(I don’t work for or represent Bluesky, so can’t speak to any plans other than what they’ve stated publicly!)
What stebalien might be referring to is that your DID document for PLC specifically is controlled by anyone with the rotation key.
In the Bluesky implementation, this is Bluesky for convenience’s sake, to make it possible for users to easily sign up. (I’m not sure internally if it’s part of the PDS or held separately.)
PLC has a mechanism allowing “higher” keys to override “lower” ones within a certain time window, so being able to add your own rotation key that “outranks” Bluesky’s would solve this issue.
Alternatively, use web DIDs and then it’s fully self-managed just as DNS would be.
This is mostly separate to the PDS - Bluesky is more like the client here (albeit, they also currently run the PLC service). It’s part of your DID document which they manage for you mostly, but there’s ways to take ownership of your PLC DID - see Dan’s links for that.
For our non-atproto uses of the PLC directory, we have similar needs, and we’ll likely let users provide their own public key before we create their document to help solve this. We have a technical audience though, so that solution may not make sense for Bluesky - but there’s a lot of people thinking about how to improve this in the atmosphere.
Excellent explanation as always from Dan, and timely with the latest news from Bluesky on moving the PLC management.
We picked the same DID systems for https://fair.pm/ to decentralise WordPress plugin distribution (and general management for user-facing packages; think App Store rather than Cargo).
The Bluesky folks (especially Bryan) were super helpful in helping us out - even shipping Ed25519 key support so we could use libsodium.
(We’re designing our protocol on top of DIDs and using Bluesky’s stackable moderation, but chose not to use atproto directly - but the great thing is that DIDs are a W3C standard, and PLC isn’t tied to atproto.)
Not gonna lie I can't resist asking for more info on who is "we" (and a link with more about the "what"), it sounds like a technical solution is coming down the pipe vs. all the WordPress drama.
Isn’t PLC (a did method created by bluesky) tied to bluesky (or some other central authority)?
Why do they call it a did when it’s centralised?
As did:plc isnt portable, why didn’t they just use did:web, and decorate the identity docs with PLC-like behaviour?
Why isn’t the method-specific-id part of the did something deterministic/portable, like a hash of a public key that can at least permit some revolver-driven portability?
Why didn’t they use some mechanism for decentralisation, like a DHT (e.g. did:pkarr)?
It seems to me that PLC is thinly veiled attempt for another master to exert control.
I think they're saying using PLC as an identity method is not tied to buying into the whole AT spec. So you can use it for something else.
>Isn’t PLC tied to bluesky (or some other central authority)?
Yes, PLC is currently tied to Bluesky, and is in the process of moving out into a separate legal entity (https://docs.bsky.app/blog/plc-directory-org). It would indeed remain centralized.
>Why didn’t they use some mechanism for decentralisation, like a DHT (e.g. did:pkarr)?
>did:dht is interesting and maybe could work, for atproto, but there have been many DHT projects in the history of decentralized computing, and only a small handful have really worked out. AKA, been resilient to abuse, attacks, neglect, etc, over years and decades. magnet links are cool but kind of the exception to the rule. I think if the W3C standardized did:dht it could be a real contender, but somebody needs to carry the flag and demonstrate it working "in real life" with millions of users, and I suspect that will be difficult, and I would not expect Bluesky to lead that charge (we already have our own pet DID method to maintain and support).
DIDs are a W3C standard, not invented by Bluesky. The PLC method specifically is currently hosted by them, but they’re working on moving it, as Dan says.
The method specific ID for PLC is a hash of the genesis operation, so it’s not just an arbitrary ID that the PLC server creates.
The PLC DID method is absolutely created by bluesky.
I never said the id they use is arbitrary, I said why not use something deterministic, so it can be handled by alternate resolvers - something that is absolutely possible while still maintaining plc integrity.
I never said it wasn’t created by Bluesky, so I’m really not sure why you’re trying to argue that I am. The point is that PLC is usable as a DID method for things that aren’t atproto.
The ID is deterministic, you can reconstruct it by hashing the genesis entry in the audit log.
I’m not even suggesting people use their own did:web - for that very reason.
I am saying that Bluesky could have used a did:web that uses the plc domain with exactly the same effect.
As is all did:plc resolution is effectively hardcoded to https://plc.directory so what exactly does having its own method change (given they could decorate the docs with any additional functionality)?
I don’t think did:web is the way forward either, as any domain “ownership” is temporary - including plc.directory.
Even extending did:key (so the identity is actually owned by the user via a keypair) and providing a doc resolver (users could register with multiple “resolvers” including bluesky controlled ones) would at least mean an id not tied to a central authority - but they chose to use their own assigned method specific identifiers.
I run my own PLC read-only mirror and do resolution that way, the main PLC is not hardcoded and is a variable you can configure in the official packages
There is also talk of supporting the did:webvh (or something like that) which addresses the domain loss iirc.
> multiple “resolvers
As an ATProto developer, how many authorities would I have to consult? Where would that list come from and live?
More builders are welcome if you want to work on this problem. I'm working on private data and permissions for ATProto
At present you would have one - bluesky. Just as with PLC.
I would hope that some form of truly distributed resolvers would become commonplace - such as those that leverage mainline DHT - and bluesky could then switch to that as well.
Where do these discussions take place? I’d love to get involved somehow.
fyi, the PLC is moving to an independent foundation and governance. It is unlikely to go away or change significantly in the near-term.
fyi2, there are two methods already, did:plc and did:web. The most likely next addition would be did:webvh, but I'm also not involved in any of that stuff. I don't think there is much work on this front because "if it ain't broke, don't fix it". The PLC is useful, even if too "centralized" for some people's preferences
Word of caution, please don't go into a new ecosystem and start by telling them what you think needs to be changed.
First understand why things are they way they are today. ATProto has attracted developers precisely because it's not a purist dominated ecosystem. The underlying ethos to everything is user choice and agency
The last sentence is most likely, also blockchain is looked down upon here as it has never lived up to the supposed benefits. They come with a host of problems something like the proof-of-authority ledger the PLC uses does not have.
Yes, some centralization was exchanged for not being blockchain based, an acceptable tradeoff imho
There are lots of options not using blockchain - I never even mentioned blockchain once.
The proof of authority ledger that PLC uses can still be used via canonical resolution of actual decentralised did methods. Right now it’s not a did (decentralised identifier) - it’s just a centralised bluesky plc id masquerading as a did.
DHT is effectively synonymous with blockchain if you need to have distributed, permissionless writes. How do you envision the DHT being updated and not being blockchain based?
Also, commenting about downvoting will get you more downvotes
> How do you envision the DHT being updated and not being blockchain based?
By being a DHT, not a blockchain? There are many ways for permissionless updates, such as those employed by BEP-44 on mainline DHT (BitTorrent - not blockchain based), IPNS (part of IPFS - also not blockchain based).
I don’t really care about the downvotes - I just want people to comment why, because I’ve said little that isn’t true.
There are lots that have been done to reduce the impact of Sybil attacks on all major DHTs - deterministic node ids, replication, signed payloads, key abuse detection and mitigation, iterative lookups through trusted nodes, etc.
Those complications are why Bluesky chose something simpler for the PLC that gave them the features they needed given the resources they have available to manage this part of the protocol and infra.
Again, and as I said, DHT resolution is just one of many options.
As for “the complications”, those “complications” are just software - as implemented in dozens of libs - and already running on hundreds of thousands (if not millions) of nodes on some of the larger DHTs.
The “features” they needed were equally solved with did:web using plc.directory - which could absolutely be backed by the PLC transparently.
> Second if Oxbridge are so good then why is all the world's research still essentially American with some satellite results coming out of Europe and perhaps (very cautiously) China?
Additionally, running on a different computer allows for eg adjusting scenes in OBS or moderating Twitch, without losing focus from the running app/game.
reply