4 ms·
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 implementatio
by rmccue 1y ago
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.
- stebalien 1y agoIs there any documentation on how to do this without running a custom appserver and/or PDS? Can I create my own DID and delegate to another DID?
- rmccue 1y agoThis 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.
- danabramov 1y agoAh yes, this might be relevant then: https://www.da.vidbuchanan.co.uk/blog/adversarial-pds-migration.html https://www.da.vidbuchanan.co.uk/blog/adversarial-pds-migrat...