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.

hosted atproto handles should work as a customizable personal homepage by default (eg, PDS acts like blento). huge "show don't tell" for atmosphere/web integration. (I think folks are aware of the juice and working towards this, but I wish it had shipped ages ago)

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

dont have in there either because we're still considering if we'd rather wait for the client to be fixed for some of these things (this mainly applies to proxying since the bsky client still does a few weird things in that regard) and there are some things where doing it the proper protocol way