I might have missed this suggestion in the thread, but why not just proxy all xrpc calls for routes which could be personalized (like feeds, threads or profiles) through the PDS and then remove/modify posts from the request there before serving it to the user?

In that case no third-party would ever need to know about your private data like mutes

@jaz.bsky.social do you have thoughts? seems like a smart way to do it. appview would hydrate public state, pds would hydrate private state (and thus private state stays private)

We don't do this because of things like mutelists where a user could be subscribed to a mutelist that they don't own and that their PDS doesn't have. The PDS doesn't have a reasonable way to index all lists referenced by private state of repos it owns and keep them up to date.

The PDS could sync the relevant mute lists from the AppView, basically be a mini-appview with a partial view of network data relevant for its users. iirc you worked on a lexicon-specific lightweight firehose with filters, that could work well for this use case

That puts a lot more app-awareness into the PDS than we really want and requires the PDS to keep a view of the network which breaks the model of the PDS being light and cheap to operate I think.

true, so I guess the better solution would be a new "mini-personal-appview" actor in the federation architecture, and ship that as part of the default PDS

but if the personal appview ships with the PDS surely that destroys account portability in terms of new kinds of appview coming online with new lexicons

it wouldn't really part of the pds itself, what I have in mind is more like a "self-hosted bluesky package" which includes the PDS and the mini-appview

so if I make insta-sky, users would have to spin up their own mini-appviews to manage their private state on this new app?

Your PDS needs to know a bit about insta-sky anyways, because it might enforce lexicon rules on the records for that app. So maybe a simple extension to the lexicon defs/features could work well enough to make features like mutes work cross-lexicon.

it can enforce the Lexicon schema validation in a generic way at runtime; it doesn't need to be aware of instasky ahead of time

there are some exotic ideas to have a WASM runtime in PDS and distributing little executable plugins which are app-specific (lambdas or edge-compute in PDS), but that is a whole can of worms and way down the road