Building a blog around PDS

[mechwire]

Hiya! Sorry if this isn't the right place, I had random questions with regards to the PDS.

The use case I'm interested in trying is using PDS as a backend for a blog. On my blog, I'd like to show posts from other apps, like Bluesky. But I'd also like to store self-defined data (like longform blog posts).

Am I correct that:

1. All PDS data is 100% public regardless of if I auth. Auth just assists in writing data to the PDS from third party apps. When a third party app retrieves your data, it does so by looking for specific lexicons / collections.
2. The way to use PDS is that Third Party Apps (like Bluesky) will save data alongside a Lexicon. It's not necessarily kosher for a Third Party App to make a lexicon available for use, such that you can write data as that Third Party App without being that third party app. Saving data alongside a lexicon also helps manage schema changes over time.

And given those assumptions, my questions are:

1. Is there a snippet somewhere defining how one reads data from the PDS, resolving the raw data and lexicon into a structured object (either map / dict or typed object)?
2. What prevents people from polluting collection names with bad schemas? Is the data reader meant to ensure the collection has the expected lexicon?

[bnewbold]

This is a great and very welcome use-case!

Yes, all data in user repositories (hosted by their PDS) is 100% public. There are public endpoints to download the entire repo, and a firehose (websocket) which blasts out every create/update/delete event to all firehose subscribers; neither endpoint uses auth. Private data, like preferences and mutes, gets stored separately from the repo. The "private data" API is a bit hard to use at the moment, we are planning to iterate on that... private data might be useful in a blog context for things like drafts.

Blobs (images) are also uploaded to the PDS and are publicly available (no auth).

Lexicons are the schema of data; all the data records with the same Lexicon are stored in a collection under the name of that Lexicon. The architecture of the system is that anybody can create Lexicons, with the authority of "who controls the lexicon" based on the (reversed) domain name used to refer to the lexicon. The expectation is that the Lexicon schema (a JSON file) is published somewhere publicly; we plan to have an automated mechanism to find and "resolve" lexicons on-demand, but haven't specified that yet. But anybody can find and use the Lexicons as they want; the "authority" only controls the schema, not how other folks use it. So, for example, anybody can make a client app using the app.bsky.* lexicons that Bluesky Social uses (and several folks have made such apps!). Individual Lexicons have "rules" for evolution over time, similar to protobuf, to ensure backwards-compatibility; this ensures that 3rd party apps don't break when cross-pollinating Lexicons. For example, you might want to re-use the app.bsky.graph.like Lexicon for "liking" posts. You can do this confidently, without worrying about us breaking the schema, because of the evolution rules.

Records are usually created/read/deleted using simple JSON. Currently the reference PDS implementation will allow you to bypass Lexicon validation when creating records; in the future we hope to support dynamically fetching new Lexicons on-demand and doing automatic validation, but for now the PDS can only validate the known Lexicons (com.atproto.*, app.bsky.*, and tools.ozone.*). So you'll need to validate in your app.

People can and already have created random schemas and records under random collections. It isn't that big of a deal? There are rate-limits about creating records in general.