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!

17/8/26, 10:09 pm1 repost50 likes

@chrisshank.com

curious why it's called permissioned spaces rather than permissioned data?

@chrisshank.com

I have a feeling that the framing of permissioned spaces is leading us down the route of a different URI scheme and the space as an authority, where as permissioned data acknowledges this is all the same scheme and records can consensually travels between many potential spaces.

𝕮@chrisshank.com

Let's take a look at long-form writing, an essay might flow though many permissioned spaces: - initial draft (size: 1) - feedback from close friends (size: 5) - newsletter for paid subscribers (size: 100s-1000s) - public distribution (size: millions)

I think I understand the vision you are advocating for, and see that others have been writing about it. but i'm not really convinced that data should be referenced+synced the same way across a lifecycle like that. I think having a common schema/representation is the main win.

@chrisshank.com

Totally onboard that sync is different but i have a feeling that a different addressing scheme breaks object permanence and there might be repercussions to that. Will start a thread of the forum to discuss this more!

there has been enough discussion that a longer form response is warranted (aka, I don't want to get in to the details here in this reply thread)

fuckface "squeaky" from:me

"AT Protocol" was always a misnomer, it's more like "AT Protocols"

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.

->

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.

fuckface "squeaky" from:me

we already have one, it's called app.bsky.actor.profile

wrong, sorry. the atmosphere is more than bsky

fuckface "squeaky" from:me

wrong. the internet is twitter

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.

@sergio.bsky.col.social

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)

thoughts on making once-permissioned data public? we’re setting up to need to do this pretty much constantly iameli.leaflet.pub/3mprgzkytjs2c it’s that or publish the same records twice inside and outside the space

iameli.leaflet.pubWhat is an atproto repository?One repo with multiple ways to sync

@chrisshank.com

this was my q too bsky.app/profile/bnew...

bryan newbold@bnewbold.net

I think I understand the vision you are advocating for, and see that others have been writing about it. but i'm not really convinced that data should be referenced+synced the same way across a lifecycle like that. I think having a common schema/representation is the main win.

this will deserve a longer written reply. would also be happy to chat it through 1:1, eg in seattle or nyc

hell yeah, flying to new york thursday