Great questions! Yeah, this is something I want to write about it in the future. An app can write to PDS if the user grants it access via OAuth. Currently this

Great questions! Yeah, this is something I want to write about it in the future. An app can write to PDS if the user grants it access via OAuth. Currently this access is very coarse (which is bad!) although backing up the entire repo is easy (which is good! but should be made more accessible to normies). There is an active workstream on OAuth Scopes (already partially deployed) which will let apps request more granular access (e.g. apps can write to "their own" collections but also ask to write e.g. Bluesky posts). In UI, this is done through sort of "bundles" of permissions. See https://github.com/bluesky-social/atproto/discussions/4118 https://github.com/bluesky-social/atproto/discussions/4118 for tracking issue. > what if it pretends to write data in the Bluesky format, but e.g. leaves out a field that the Bluesky Appview expects, or writes data in a different format than it expects? Atproto data is governed by "lexicons" which are essentially type definitions used by app authors. E.g. `app.bsky.feed.post` type definition is maintained by the Bluesky team. There's a codegen that generates validation code from that definition. If validation doesn't pass, the Bluesky app server will just ignore that record. Records are generally treated by apps as untrusted input, similar to form submissions. They can be validated during ingestion or in the process of usage later.