Samuel
3rd party apps running their own appviews kinda makes sense but it'd be a bit weird for mutes to be per-app. I wonder if there's a plan to be able to sync private state between separate appviews run by different parties
4 15
Jaz
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.
2 17
Jaz
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.
2 8
Jaz
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.
1 7
Samuel
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
1 6
Jaz
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
2 5
Samuel
@samuel.fm
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?
1 1
Jaz
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
3 6
Samuel
yeah that's absolutely fair, I think that is probably too much of a compromise
1
Jaz
The “dumb” version in my brain is the PDS maintains a list of webhooks and permissions objects attached to them and then emits an update event or some kind of nudge to the webhook url when things change to prompt the service to scrape the new private state. Depending on how big it gets though…
1 1 3
Jaz
Syncing the entire private repo, even if it’s scoped down, could be expensive.
2 2
Samuel
what would be the scale issue here? if a user interacts with too many separate appviews?
1 1
Jaz
And the sheer number of requests depending on the size of the PDS. Handling back pressure and rate limiting in these scenarios could be difficult. If users have to explicitly register each service though it might be viable. There is _that_ much private state activity atm.
1 2
Jaz
Err there isn’t much private state activity atm is what I meant to say. Multiple orders smaller than the firehose.
1
Jaz
Also this means the PDS would need to scale based on the number of private state listeners and needs to have complex logic to retry these hooks somehow to give at least a little best effort on making the third party service aware of the changes. Of course the third party could just scrape regularly
1 2
Jaz
I haven’t spent too much time thinking about it but it could be a place where using another CRDT (like an MST) would be viable. Providing cryptographic proof of private data feels leaky though from a security standpoint. Can’t pinpoint why atm but feels risky. Anyhow gonna try to go back to bed now.
1 2
Thomas Dickerson
The key you use to lookup the private data has to also be encrypted but in such a way that authorized servers can independently recreate it by encrypting some other state that changes with very low frequency (probably at end-user request when revoking an app view’s permissions)
1