It’s definitely a current limitation of the protocol. Private state syncing is hard when you don’t have preestablished trusted parties and/or ways to easily scope permissions for access to some kind of central private state. Wonder if your PDS could store it and selectively give access.

Paul prolly has a lot of smart ideas about it but yeah. Syncing with the PDS often for that data would probably be prohibitively expensive on the side of the PDS and/or the third party though. We solve it by having the PDS push mutes/etc to our appview directly but it’s not very clean.

All I know is we definitely don’t want private data living inside the public repo even if it’s encrypted or something so we need to figure out some method of giving a PDS a way to store, query, and mutate private state for a repo in a generic and scoped manner.

yeah I suppose you'd want the PDS to keep 2 repos in a way, one public and distributed across the network, and one private

Yeah, figuring out a model for syncing that private state is hard though. You can’t really have a firehose of private state since you’d basically need one per repo which wouldn’t scale. We need to think of some other scalable sync primitive for it that will make sense with not always available svcs

out of my depth here but could you do something like publishing the uri of the record without its content, so an appview knows if it's copy of the private state is up to date without needing to hit up the PDS directly, and just sync directly as needed?

I don’t think we’d want to make it transparently visible when a user makes changes to the contents of their private repo. I thought about it being included in firehouse events with its own Rev clock or something that only moves when it updates but also you only want svcs with perms to know about it