4. there is interest in pre-commit scanning. I'd categorize that is a PDS implementation feature request. maybe we can coordinate other folks in the ecosystem who could collaborate on that

AT service operators and moderation thinkers: I put together an early proposal around infra abuse notices across organizational boundaries. really looking for feedback on this one, it is bait for counter-proposals and references to prior work! github.com/bluesky-social...

I'm pretty skeptical of simple down-votes in the form of public records, but I don't have a firm counter-proposal. store them as preferences and share w/ services? interoperable embeddings, somehow? NER, or wikidata QIDs?

I don't think mod tooling is a lost cause: it should be a small part of online life, but dispute resolution is important. I think having "spaces" would give structure signals (up and down) and help with issues elsewhere in the network via spillover.

"composable moderation" is about the ability to use multiple mod services at the same time, and that mod services can be operated independent of other infra (aka service modularity)

if there are implementation bugs let's get them! or inconsistency in any written specs

but I also want students/hackers to use the tools they have at hand to *read* data, and in a lot of situations that will be a generic CBOR library which doesn't enforce any special encoding rules

I know we don't want one bad *record* to break an entire *repo*. I think PDS should be very strict, ours maybe is not, and that is urgent to fix. I would love if every SDK and service consistently did full validation and consistently rejected bad records...

but in our IETF text we should only reference formal standards, so we will ref CBOR RFCs and re-describe details. still no floats. more ambiguous question is where all this is expected to be validated, and behaviors if it fails. PDS, relay, SDKs, etc

but yeah have wanted an "Automated Account" indication forever