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.
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.