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.

17/8/26, 10:05 pm5 reposts101 likes

@katelynsills.com

can you say more on this?

Bailey Townsend 🦀

Big fan of this. It's what I did with Lichess puzzles. Used their IDs and referenced them in the record while also providing a XRPC endpoint for them. xrpc-puzzles.wafflehouse.dev/xrpc/org.lic...

@nonbinary.computer

yeah, avivia doing the same thing with deckbelcher.com was smart. scryfall ids are a de facto standard, so why not just use them

deckbelcher.comdeck belcherOrganize, build, and share Magic: The Gathering decks on the Atmosphere.

what about things like ontologies? if every CURIE was eventually stored on atproto as an immutable record, in a repo owned by a consortium that oversees the ontology, wouldn't you want to be able to reference the AT-URI, and the record has the existing identifier in there?

bc some ontologies do have identifiers that will never change and that happen to be https URLs, actually. but that should be fine. the ID is just an ID (for indexing), and the AT-URI could become canonically used to refer to the record on the protocol.

do you see ontologies living on the protocol in the future? or do you not see atproto as right for them? this is particularly applicable for #ATScience

We've built our place review system on atproto, the osm id is the key.

Hard agree

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!

@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.

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

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

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.

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