Post

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.

What do you think of this idea? ->

fry69@fry69.dev

Shower thought idea: What about expanding the role of the PDS for account management? E.g. when signing up on atproto with any app/service for the first time, redirect to the already existing account interface (`/account/`) already present on reference PDS, making this flow mandatory to support.

0 reposts0 likes

->

fry69@fry69.dev

From there, creating an account via a wizard, filling mandatory generic account lexicon (+optional an extended tailored account lexicon) with data, as needed. This would be a start towards moving more and more authority away from Bluesky (the app/company) and more towards user controlled PDS.