Samuel
@samuel.fm
@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
JazWe 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 5redsolverThe 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 4JazThat 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 7redsolvertrue, 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 4Samuelbut 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 2redsolverit 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 3Samuelso 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 3redsolverYour 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 newboldit 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 4bryan newboldthere 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 3JazThere are also cases in which we may want to use mutes inside the AppView i.e. when generating recommendations for follows and/or when generating notifications where the data that goes back doesn't necessarily proxy through the PDS. Push notifs don't hit the PDS at all right now.
1 2redsolverI feel like letting the AppView do this many things (which could also be achieved by filtering notifs or recommendations PDS-side after the initial ones are generated by an AppView) increases the centralization risk a bit higher than would be necessary in the AT Proto architecture
2 3redsolverOf course this adds quite a lot of complexity, but long-term it's worth it imo to keep privacy of private data and the global appviews shouldn't be stateful
1 2bryan newboldthe main reason to not do it this way is to get app-aware logic out of the PDS. otherwise when you make a lexicon/app change you need to update client-app, AppView, *and* wait for all the PDS instances in the ecosystem to upgrade
1 4bryan newboldthe goal is to make PDS selection commodity and not app-specific. it is a bummer if a new app comes out and you want to try it (full-featured), but your PDS doesn't support; and PDS hosters which do support it don't support other apps you are already using[
1 4bryan newboldwe aren't perfect on this right now: there is still some bsky logic for read-after-write.
some complex things that can be made generic in the future: validating Lexicons (via "resolving" Lexicon schema at runtime), blob extraction (via $type:blob at any nesting)
1 1bryan newbolda similar thing comes up with labels: why not have PDS hydrate labels privately?
if you look at the label set schemas, we did in fact carve out a way to do that in a generic (Lexicon-agnostic) way, at least in theory
1bryan newboldand tbc this thread of thought is to enable app/lexicon developers to "move fast" while maintaining interop. optimistically this resolves much of the problems expressed by Moxie and Signal (that famous old talk about product evolution)
1bryan newboldother priorities and values are also possible though: a community open-source project doing Lexicons might prioritize PDS integration and be willing to have a slower pace of future feature development
1