4 ms·

author here, should you have questions!

theschmed 2y ago
Thanks for making yourself available to answer questions! Hopefully this is not a dumb question. Is plc.directory a single point of failure for BlueSky users who want to take advantage of the benefits of a did:plc? And if so, is that a permanent thing or down the road will there be multiple interoperating did:plc directories?
- __justplaying 2y ago
  yes it's a SPOF. not sure about the second question, but i do know there are plans to transfer its ownership to an independent foundation
  - pfraze 2y ago
    Transferring to an independent org is what we're talking about now, yes. The backstory to PLC is that we picked up the DID standard and looked for an existing registry-method that would satisfy requirements¹. None of them really did. We then surveyed mechanisms for decentralized operation: DHTs, open blockchains, permissioned blockchains, and federated databases. Of them, the two blockchain variants seemed perhaps promising, but still premature since (as of 2022) you there's cost variability due to load and in some cases bad transaction latency (eg 10 minutes). We decided the best decision was to create PLC, which matches all of the requirements except for longterm meta governance. The way we designed it was to make the registry mechanics transferrable to a different protocol in the future, so that if for instance we decided (say) a DHT was suitable (it's not) we'd be able to use the same identifiers but change resolution and mutations to a new process. Then we started talking to other SMEs to get their take. Ultimately the solution that's gotten the most favorable response has been setting up an ICANN-style independent organization to operate it. This can be joined with a couple of interesting systems, such as mirrors which tail a certificate-transparency-style audit log, and which could even serve as transaction witnesses to indicate when the core registry might be rejecting updates ("write censorship"). What can I say, some things take time and stakeholder-building. Look up the history of DNS and Network Solutions Inc for a bit of a wild ride that people have forgotten about. One other thing I should point out is that the DID spec enables multiple registry methods. Atproto currently supports did:web, and if other methods show up which satisfy the requirements then we are interested. ¹ Secure against manipulation by the registry operators, longterm meta governance, highly available, reasonable transaction latency, reliably low cost that's not dogged by token speculation, low ecological impact.
    - jazzyjackson 2y ago
      Hey pfraze, forgive my ignorance but what role does DID serve that DNS doesn't? My favorite part about bsky is using TXT record to prove that I control my domain for username purposes, what's the downside to just generating a keypair, and using the fingerprint of the public key as my identity? (Maybe with some affordance for key rotation vis a vis KERI*) Not doubting youall weighed every possibility, just wondering what I'm missing *Key Event Receipt Infrastructure
      - steveklabnik 2y ago
        Not Paul, but DID is a stable ID over time, whereas dns is not. This lets you change your handle without the network losing track of who you are. I was @steveklabnik.bsky.social before I was @steveklabnik.com, and when I made the switch, all of my previous stuff was still there. This is a fun party trick in some sense, but also a real meaningful feature in another. If I ever decide to move from steveklabnik.com to steve.klabnik.com, a thing I have been considering for a few years, my stuff on @proto/Bluesky will be one of the only services that doesn't have the issue that's kept me from pulling the trigger: updating the entire world that that's where I am now.
        pfraze 2y ago
        Yes! And if this were not the case then account portability between PDS hosts would be really challenging. Same logic as keeping your phone number when you switch cell carriers
        kiitos 2y ago
        DIDs are stable only in the context of a specific 'verifiable data registry' as the spec puts it. https://www.w3.org/TR/did-core/#dfn-verifiable-data-registry https://www.w3.org/TR/did-core/#dfn-verifiable-data-registry DIDs delegate trust and authority to a data registry, in exactly the same way that DNS delegates trust and authority to ~ICANN. The system model is exactly the same. The difference is only in the properties of the authoritative entity.
jervant 2y ago
How are Direct Messages implemented in Bluesky if anyone can access a firehose of all network activity?
- __justplaying 2y ago
  DMs are currently 1:1 only and closed source. They are working on/planning to build proper E2EE DMs that support group chats.
moreati 2y ago
What's in that 4.5 TB? e.g. message metadata? Message text? Media? What time window does it cover? A rolling N day window? Everything since year dot? Can it be pruned? e.g. only data of accounts followed or messages interacted with
mintplant 2y ago
What's the difference between social-app and the AppView?
- pfraze 2y ago
  social-app is the client side, AppView is the backend api surface

Thanks for making yourself available to answer questions! Hopefully this is not a dumb question. Is plc.directory a single point of failure for BlueSky users who want to take advantage of the benefits of a did:plc? And if so, is that a permanent thing or down the road will there be multiple interoperating did:plc directories?

__justplaying 2y ago
yes it's a SPOF. not sure about the second question, but i do know there are plans to transfer its ownership to an independent foundation
- pfraze 2y ago
  Transferring to an independent org is what we're talking about now, yes. The backstory to PLC is that we picked up the DID standard and looked for an existing registry-method that would satisfy requirements¹. None of them really did. We then surveyed mechanisms for decentralized operation: DHTs, open blockchains, permissioned blockchains, and federated databases. Of them, the two blockchain variants seemed perhaps promising, but still premature since (as of 2022) you there's cost variability due to load and in some cases bad transaction latency (eg 10 minutes). We decided the best decision was to create PLC, which matches all of the requirements except for longterm meta governance. The way we designed it was to make the registry mechanics transferrable to a different protocol in the future, so that if for instance we decided (say) a DHT was suitable (it's not) we'd be able to use the same identifiers but change resolution and mutations to a new process. Then we started talking to other SMEs to get their take. Ultimately the solution that's gotten the most favorable response has been setting up an ICANN-style independent organization to operate it. This can be joined with a couple of interesting systems, such as mirrors which tail a certificate-transparency-style audit log, and which could even serve as transaction witnesses to indicate when the core registry might be rejecting updates ("write censorship"). What can I say, some things take time and stakeholder-building. Look up the history of DNS and Network Solutions Inc for a bit of a wild ride that people have forgotten about. One other thing I should point out is that the DID spec enables multiple registry methods. Atproto currently supports did:web, and if other methods show up which satisfy the requirements then we are interested. ¹ Secure against manipulation by the registry operators, longterm meta governance, highly available, reasonable transaction latency, reliably low cost that's not dogged by token speculation, low ecological impact.
  - jazzyjackson 2y ago
    Hey pfraze, forgive my ignorance but what role does DID serve that DNS doesn't? My favorite part about bsky is using TXT record to prove that I control my domain for username purposes, what's the downside to just generating a keypair, and using the fingerprint of the public key as my identity? (Maybe with some affordance for key rotation vis a vis KERI*) Not doubting youall weighed every possibility, just wondering what I'm missing *Key Event Receipt Infrastructure
    - steveklabnik 2y ago
      Not Paul, but DID is a stable ID over time, whereas dns is not. This lets you change your handle without the network losing track of who you are. I was @steveklabnik.bsky.social before I was @steveklabnik.com, and when I made the switch, all of my previous stuff was still there. This is a fun party trick in some sense, but also a real meaningful feature in another. If I ever decide to move from steveklabnik.com to steve.klabnik.com, a thing I have been considering for a few years, my stuff on @proto/Bluesky will be one of the only services that doesn't have the issue that's kept me from pulling the trigger: updating the entire world that that's where I am now.
      - pfraze 2y ago
        Yes! And if this were not the case then account portability between PDS hosts would be really challenging. Same logic as keeping your phone number when you switch cell carriers
      - kiitos 2y ago
        DIDs are stable only in the context of a specific 'verifiable data registry' as the spec puts it. https://www.w3.org/TR/did-core/#dfn-verifiable-data-registry https://www.w3.org/TR/did-core/#dfn-verifiable-data-registry DIDs delegate trust and authority to a data registry, in exactly the same way that DNS delegates trust and authority to ~ICANN. The system model is exactly the same. The difference is only in the properties of the authoritative entity.

jervant 2y ago

How are Direct Messages implemented in Bluesky if anyone can access a firehose of all network activity?

__justplaying 2y ago
DMs are currently 1:1 only and closed source. They are working on/planning to build proper E2EE DMs that support group chats.

moreati 2y ago

What's in that 4.5 TB? e.g. message metadata? Message text? Media? What time window does it cover? A rolling N day window? Everything since year dot? Can it be pruned? e.g. only data of accounts followed or messages interacted with

mintplant 2y ago

What's the difference between social-app and the AppView?

pfraze 2y ago
social-app is the client side, AppView is the backend api surface