3 ms·

The ability to make information private fundamentally conflicts with how ATProto is designed. All records have to be sent to all Relays and AppView nodes on the

The ability to make information private fundamentally conflicts with how ATProto is designed. All records have to be sent to all Relays and AppView nodes on the network to provide a "global view" of the network. So there's no way to keep records private without locking out some user's servers from viewing them, and since AppViews are centralized indexing services, they won't function without being able to see the entire network.

NiallBunting 6mo ago
Yeah, apps wouldn't be able to only listen to the firehose. There are some proposals for private files. However, I'm outside the AtProto world so not sure what exactly the suggested implementations are. I just hope they give enough control. I think the technology could potentially be used for way more than microblogging. I would love to use webapps that store the data on my devices and share it with specific people. The data and access under my control. [1]: https://dholms.leaflet.pub/3mhj6bcqats2o https://dholms.leaflet.pub/3mhj6bcqats2o
- blackqueeriroh 6mo ago
  What you linked is by Bluesky’s own staff - it’s him laying out the design plans for the protocol’s private data implementation. He’s doing it to engage publicly with the community, since many of us also build on the protocol.
  - nightpool 5mo ago
    > Sync is pull-based. Applications are responsible for staying in sync with all member PDSes. PDSes assist by sending lightweight write notifications to prompt pulls when new data is written. It looks like this basically just reinvents ActivityPub (local servers can pull or push to remote servers). So it defeats all of the "benefits" you get from Bluesky's firehose-based approach anyway, except for the fact that Bluesky assumes you're going to be using their AppView and they will always have access to your private data.
tardedmeme 6mo ago
What would happen if you returned different content depending on who was asking?
- nightpool 5mo ago
  It would fail the merkle tree validation

NiallBunting 6mo ago

Yeah, apps wouldn't be able to only listen to the firehose. There are some proposals for private files. However, I'm outside the AtProto world so not sure what exactly the suggested implementations are. I just hope they give enough control. I think the technology could potentially be used for way more than microblogging. I would love to use webapps that store the data on my devices and share it with specific people. The data and access under my control. [1]: https://dholms.leaflet.pub/3mhj6bcqats2o https://dholms.leaflet.pub/3mhj6bcqats2o

blackqueeriroh 6mo ago
What you linked is by Bluesky’s own staff - it’s him laying out the design plans for the protocol’s private data implementation. He’s doing it to engage publicly with the community, since many of us also build on the protocol.
- nightpool 5mo ago
  > Sync is pull-based. Applications are responsible for staying in sync with all member PDSes. PDSes assist by sending lightweight write notifications to prompt pulls when new data is written. It looks like this basically just reinvents ActivityPub (local servers can pull or push to remote servers). So it defeats all of the "benefits" you get from Bluesky's firehose-based approach anyway, except for the fact that Bluesky assumes you're going to be using their AppView and they will always have access to your private data.

tardedmeme 6mo ago

What would happen if you returned different content depending on who was asking?

nightpool 5mo ago
It would fail the merkle tree validation