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.

3 reposts77 likes

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.

->

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.

I think you should be able to delete or invalidate 'app.bsky.actor.profile/self' and have that action "deactivate" your bsky profile/posts, without impacting your other atmosphere presence and apps

also the maintainers of 'app.bsky.actor.profile' should be free to be weird and idiosyncratic about adding new fields/features without worrying about how that will impact things like typeahead handle search for login to completely unrelated apps.

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.

ah, interesting. I had been wondering about this for a while… my scenario is importing bookmarks bsky.app/profile/serg...

Sergio@sergio.bsky.col.social

Given bsky's hosted PDS per-account publishing limits, what patterns or mechanisms are used/envisioned for legit bulk data ingestion scenarios? e.g. importing a user’s full set of existing bookmarks #atproto

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)

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