I'm not quite sure I'm following what you're saying.
Basically, there's two main roles in the system:
- A user's personal repository -- that's sort of like Git hosting, with a server that can serve a JSON record or a stream of commits. That's PDS. It's application-agnostic. Bluesky's open source implementation of PDS does in fact use sqlite (per each user :). Each user has exactly one repo that stores data of all apps.
- An app -- that's any arbitrary app backend. Could be literally anything. These write data to user's personal repo (for the stuff user creates). They can directly ask a particular user's repo for data (like explained in the article) or they can subscribe to the commit stream and mirror the data they care about in a local database. Then it can be queried and retrieved with no delays, and also can be aggregated (e.g. calculate count of likes for a given post, even though they "live" in different users' repos).
Basically, there's two main roles in the system:
- A user's personal repository -- that's sort of like Git hosting, with a server that can serve a JSON record or a stream of commits. That's PDS. It's application-agnostic. Bluesky's open source implementation of PDS does in fact use sqlite (per each user :). Each user has exactly one repo that stores data of all apps.
- An app -- that's any arbitrary app backend. Could be literally anything. These write data to user's personal repo (for the stuff user creates). They can directly ask a particular user's repo for data (like explained in the article) or they can subscribe to the commit stream and mirror the data they care about in a local database. Then it can be queried and retrieved with no delays, and also can be aggregated (e.g. calculate count of likes for a given post, even though they "live" in different users' repos).
Does this make sense?