7 ms·

You won’t have decentralisation on Atproto because the protocol itself incentivises centralisation.

by kevinak 3mo ago

tancop 3mo ago
the only true centralized part is the did:plc registry and thats designed to be fully auditable. all canonical data is stored on your pds so if you self host that you get full control. decentralization is not about the number of app instances but how easy it is to switch from one to another. on that metric bluesky is already better than fediverse.
- kevinak 3mo ago
  That’s a very narrow definition of decentralisation. In any case - both atproto and fediverse are massively centralised compared to something like Nostr, and it’s not even close. The fact that the PDS in practice owns your identity in the vast vast majority of cases is such a dumb trade off that it’s honestly laughable. Should Bluesky decide to splinter off of the network there would be like 50000 people left. Stop telling people that it’s decentralised in any meaningful way and be honest about it instead. That’s the issue. The dishonesty and tricking users.
  - AlienRobot 3mo ago
    There are two kinds of people. 1. People who have no idea what decentralized is. 2. People who would try to figure exactly how decentralized something is. If you are the latter, you would instantly question the data model of Bluesky and of Mastodon as well. If you are the former then that just sounds like a buzzword.
  - steveklabnik 3mo ago
    > The fact that the PDS in practice owns your identity This is incorrect. 1. a PDS stores data, it does not own the identity. 2. Your identity is controlled by a DID, of which most users use DID:PLC. 3. This means the PLC directory controls who owns the identity. 4. Users can upload their own keys into the directory to ensure they have control. 5. At this point, the threat vector is "PLC directory lies", which is why there are transparency logs and independent mirrors.
    - kevinak 3mo ago
      Nope. When I’m talking about identity I’m speaking strictly of the keys that sign your messages and the pub key derived from it. In every other cryptographic system that is your identity. It is absolutely correct that the PDS has complete control over your keys when it comes to 99.99% of users. I challenge you to prove the opposite.
      - steveklabnik 3mo ago
        > When I’m talking about identity I’m speaking strictly of the keys that sign your messages and the pub key derived from it. Me too. > I challenge you to prove the opposite. https://web.plc.directory/spec/v0.1/did-plc https://web.plc.directory/spec/v0.1/did-plc
        kevinak 3mo ago
        Where are your rotation and signing keys stored? Who can access them? Talking here about the majority case.
        steveklabnik 3mo ago
        > Where are your rotation and signing keys stored? Who can acccess them? This uses public key cryptography, so there's multiple answers here. Let's start at the beginning: atproto uses DIDs as its identity standard: http://w3.org/TR/did-1.0/ http://w3.org/TR/did-1.0/ Here is my DID, we'll use this as an example: did:plc:3danwc67lo7obz2fmdg6jxcr There are three parts, separated by colons: The scheme (did), the method (plc), and the DID method-specific identifier (3danwc67lo7obz2fmdg6jxcr). To use a DID, such as did:plc:3danwc67lo7obz2fmdg6jxcr, you resolve it into a DID Document https://www.w3.org/TR/did-1.0/#dfn-did-documents https://www.w3.org/TR/did-1.0/#dfn-did-documents > A set of data describing the DID subject, including mechanisms, such as cryptographic public keys, that the DID subject or a DID delegate can use to authenticate itself and prove its association with the DID. That document contains various properties that describe the identity: https://www.w3.org/TR/did-1.0/#core-properties https://www.w3.org/TR/did-1.0/#core-properties One of those properties is the "verification method", which tells you what to do to verify the identity. So you just do whatever is in that, and that gives you the identity. In other words, the broadest part of the spec is very pluggable, it does not describe the answer to your question in all cases. So let's get more specific: One kind of DID, and the one that's used by virtually all of atproto users, is DID:PLC. As you can see from my DID above, I'm using the PLC method for my DID. Its specification is what I linked you to above, https://web.plc.directory/spec/v0.1/did-plc https://web.plc.directory/spec/v0.1/did-plc. You can see my specific entry here, for example: https://plc.directory/did:plc:3danwc67lo7obz2fmdg6jxcr https://plc.directory/did:plc:3danwc67lo7obz2fmdg6jxcr (Note that, before we get into any other part of it, this document points at my PDS, https://morel.us-east.host.bsky.network https://morel.us-east.host.bsky.network . So already, without going further, this is why your original comment is wrong: my identity points at my PDS, my PDS does not point at my identity.) This specifies what goes into the "verification method" of a DID document that uses this method. In this case, if you look at mine, you'll see that it points (eventually) to https://www.w3.org/TR/cid-1.0/ https://www.w3.org/TR/cid-1.0/, which is what the Multikey stuff is about. From that spec: > Controlled identifier documents identify a subject and provide verification methods that express public cryptographic material, such as public keys, for verifying proofs created on behalf of the subject for specific purposes, such as authentication, attestation, key agreement (for encryption), and capability invocation and delegation. Controlled identifier documents also list service endpoints related to an identifier; for example, from which to request additional information for verification. This is already getting deep in the weeds, but the point is that the publicKeyMultibase is the encoded form of the public key that controls my identity. So that's where that lives. What about its associated private key? Well, it can be anywhere! From an identity perspective, the location of the private key doesn't matter. Only that whoever has that key produces information under that identity, when signed. So let's talk in practice: when you sign up for Bluesky, they store the private key for you. This way, for users that don't care about any of these details, they do not have to think about it at all. It's saved with the rest of your account data, you don't have to worry about backups or anything. However, at any time, any user can register a rotation key with the PLC directory. To do this, you generate a new public and private key, and then store that private key wherever you'd like. All the usual caveats here apply. You can then use your existing private key to add this new public key to your account. Once you do that, it shows up in your DID document as a rotation key. You can use that rotation key to add more keys, remove the Bluesky owned keypair, whatever you want. Now it's not stored by Bluesky. The majority of users have not done this, it's true. But they can. Whenever they'd like.

You won’t have decentralisation on Atproto because the protocol itself incentivises centralisation.

by kevinak 3mo ago

You won’t have decentralisation on Atproto because the protocol itself incentivises centralisation.

the only true centralized part is the did:plc registry and thats designed to be fully auditable. all canonical data is stored on your pds so if you self host that you get full control. decentralization is not about the number of app instances but how easy it is to switch from one to another. on that metric bluesky is already better than fediverse.

kevinak 3mo ago
That’s a very narrow definition of decentralisation. In any case - both atproto and fediverse are massively centralised compared to something like Nostr, and it’s not even close. The fact that the PDS in practice owns your identity in the vast vast majority of cases is such a dumb trade off that it’s honestly laughable. Should Bluesky decide to splinter off of the network there would be like 50000 people left. Stop telling people that it’s decentralised in any meaningful way and be honest about it instead. That’s the issue. The dishonesty and tricking users.
- AlienRobot 3mo ago
  There are two kinds of people. 1. People who have no idea what decentralized is. 2. People who would try to figure exactly how decentralized something is. If you are the latter, you would instantly question the data model of Bluesky and of Mastodon as well. If you are the former then that just sounds like a buzzword.
- steveklabnik 3mo ago
  > The fact that the PDS in practice owns your identity This is incorrect. 1. a PDS stores data, it does not own the identity. 2. Your identity is controlled by a DID, of which most users use DID:PLC. 3. This means the PLC directory controls who owns the identity. 4. Users can upload their own keys into the directory to ensure they have control. 5. At this point, the threat vector is "PLC directory lies", which is why there are transparency logs and independent mirrors.
  - kevinak 3mo ago
    Nope. When I’m talking about identity I’m speaking strictly of the keys that sign your messages and the pub key derived from it. In every other cryptographic system that is your identity. It is absolutely correct that the PDS has complete control over your keys when it comes to 99.99% of users. I challenge you to prove the opposite.
    - steveklabnik 3mo ago
      > When I’m talking about identity I’m speaking strictly of the keys that sign your messages and the pub key derived from it. Me too. > I challenge you to prove the opposite. https://web.plc.directory/spec/v0.1/did-plc https://web.plc.directory/spec/v0.1/did-plc
      - kevinak 3mo ago
        Where are your rotation and signing keys stored? Who can access them? Talking here about the majority case.
        steveklabnik 3mo ago
        > Where are your rotation and signing keys stored? Who can acccess them? This uses public key cryptography, so there's multiple answers here. Let's start at the beginning: atproto uses DIDs as its identity standard: http://w3.org/TR/did-1.0/ http://w3.org/TR/did-1.0/ Here is my DID, we'll use this as an example: did:plc:3danwc67lo7obz2fmdg6jxcr There are three parts, separated by colons: The scheme (did), the method (plc), and the DID method-specific identifier (3danwc67lo7obz2fmdg6jxcr). To use a DID, such as did:plc:3danwc67lo7obz2fmdg6jxcr, you resolve it into a DID Document https://www.w3.org/TR/did-1.0/#dfn-did-documents https://www.w3.org/TR/did-1.0/#dfn-did-documents > A set of data describing the DID subject, including mechanisms, such as cryptographic public keys, that the DID subject or a DID delegate can use to authenticate itself and prove its association with the DID. That document contains various properties that describe the identity: https://www.w3.org/TR/did-1.0/#core-properties https://www.w3.org/TR/did-1.0/#core-properties One of those properties is the "verification method", which tells you what to do to verify the identity. So you just do whatever is in that, and that gives you the identity. In other words, the broadest part of the spec is very pluggable, it does not describe the answer to your question in all cases. So let's get more specific: One kind of DID, and the one that's used by virtually all of atproto users, is DID:PLC. As you can see from my DID above, I'm using the PLC method for my DID. Its specification is what I linked you to above, https://web.plc.directory/spec/v0.1/did-plc https://web.plc.directory/spec/v0.1/did-plc. You can see my specific entry here, for example: https://plc.directory/did:plc:3danwc67lo7obz2fmdg6jxcr https://plc.directory/did:plc:3danwc67lo7obz2fmdg6jxcr (Note that, before we get into any other part of it, this document points at my PDS, https://morel.us-east.host.bsky.network https://morel.us-east.host.bsky.network . So already, without going further, this is why your original comment is wrong: my identity points at my PDS, my PDS does not point at my identity.) This specifies what goes into the "verification method" of a DID document that uses this method. In this case, if you look at mine, you'll see that it points (eventually) to https://www.w3.org/TR/cid-1.0/ https://www.w3.org/TR/cid-1.0/, which is what the Multikey stuff is about. From that spec: > Controlled identifier documents identify a subject and provide verification methods that express public cryptographic material, such as public keys, for verifying proofs created on behalf of the subject for specific purposes, such as authentication, attestation, key agreement (for encryption), and capability invocation and delegation. Controlled identifier documents also list service endpoints related to an identifier; for example, from which to request additional information for verification. This is already getting deep in the weeds, but the point is that the publicKeyMultibase is the encoded form of the public key that controls my identity. So that's where that lives. What about its associated private key? Well, it can be anywhere! From an identity perspective, the location of the private key doesn't matter. Only that whoever has that key produces information under that identity, when signed. So let's talk in practice: when you sign up for Bluesky, they store the private key for you. This way, for users that don't care about any of these details, they do not have to think about it at all. It's saved with the rest of your account data, you don't have to worry about backups or anything. However, at any time, any user can register a rotation key with the PLC directory. To do this, you generate a new public and private key, and then store that private key wherever you'd like. All the usual caveats here apply. You can then use your existing private key to add this new public key to your account. Once you do that, it shows up in your DID document as a rotation key. You can use that rotation key to add more keys, remove the Bluesky owned keypair, whatever you want. Now it's not stored by Bluesky. The majority of users have not done this, it's true. But they can. Whenever they'd like.