Post

thread of some protocol hot takes from my time off that I hope to expand on...

mirroring existing catalog records (books, films, venues, etc) in to atproto records is tempting, but (IMHO) an anti-pattern. instead of copying that data in and referencing with an AT-URI, you should reference them by existing identifiers (ISBN, OSM identifier, etc). appviews sync the catalog.

public broadcast and permission spaces deserve different sync mechanisms (and probably URI schemes). public into a global shared heap is sort of a special-case audience/scope. but it is important and different enough that the MST+firehose are worth it. all the other affordances+tooling is reused!

I've changed my mind and there probably should be a generic/fallback profile record type for atmosphere accounts. something like gravatar.

OTOH, in most cases I think we (as an ecosystem) should balance the benefits of common/popular lexicons against diversity and heterogeneity. having multiple opinionated+idiosyncratic record schemas for the same use-case is often good, and appviews can+should support them. (with some exceptions)

hack for bulk importing records (eg, "migrate your posts from old system"): write all the original data as a blob (eg, zip/tar), and point to it from an import status record. periodically (daily?) poll status, write next (small) batch of records, and update the status record.

the composable moderation system (labeling) has never been fully integrated into the bsky app. we never shipped the full original vision, and definitely haven't iterated based on feedback+experience. the core concept may or may not be flawed, but hard to tell w/o giving it a real go

My thoughts about current public moderation lists ->

considering what happened with Aegis, I can't tell if that should be bracketed "(definitely haven't) (iterated based on feedback+experience)" or "(definitely haven't iterated) (based on feedback+experience)"

there is a short list of ongoing protocol rollouts/migrations/deprecations (eg, sync 1.1), and another short list of jank around bsky's deployed implementation of the protocol (eg, default appview proxying). having a frank enumeration of these, and their current status, would probably be helpful

we have ended up making somewhat of a list like that out of necessity while making tranquil. mainly due to the fact that we now support disabling, at compile time, all the special case things we need to do just to have the official bluesky client work properly. theres still a few cases of that we