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
redsolver
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?
1 3
Samuel
@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)
1 3
Jaz
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.
2 5
redsolver
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
2 4
Jaz
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.
2 7
redsolver
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
1 4
Samuel
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
1 2
redsolver
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
1 3
Samuel
@samuel.fm
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?
1 3
redsolver
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.
2 3
bryan newbold
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
2 4
bryan newbold
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
2 4
shreyan (wise)
for this specific case, instead of appviews *storing* private state, why not make that part of the PDS in a separate, private version of the repo? then it can delegate access to this to the appview with similar semantics (if not the same data structure) as the public repo...
1 3
bryan newbold
the state is canonically in the PDS, and appview is granted access, potentially by namespace prefix. this makes switching providers easier
1 4
shreyan (wise)
yeah that's a good, generic solution. it requires some trust in the appview not to give out the data, so probably no DMs or super sensitive stuff should be stored like that
1 2
Samuel
I feel that’s a fair thing to trust, if you’re going to trust a new client to have access to this stuff then it’s only fair you’d grant the same level of trust to its associated appview
1 2
Samuel
yeah and thus it’d be nice to try out a new client by opting out of sharing private stuff until you’re comfortable
3
redsolver
but yeah, that basically just shifting the mini-appviews impl to a configuration language
2