How do we talk about atproto to non-developers?
The beauty of AT Protocol is that all of your data from different apps is available on your PDS, your own folder on the internet containing your stuff as JSON. This means that you can switch which app you use to view that data, without losing anything. It also makes it very easy to make connections between data stored using different lexicons, or just display activity in one place. Sifa does a nice job of this on your profile page. For web developers, and people who understand webhosting, the concept is reasonably easy to understand. I know that any atproto app I join is going to store data in my PDS, any other people will be able to see it.
atproto-wc ยท atproto-wc
Framework-agnostic ATProto web components. Content from PDS. Engagement from Constellation. Zero AppView dependency.
Can atproto scale down?
Decomposing the Bluesky appview and self-hosting the pieces
ATProto Architecture
Visual summary of the AT Protocol architecture: PDS, AppView, identity, records, lexicons.
This is partly why I think atproto needs a more convincing vision about being a post-app protocol. A future where atproto is a bunch of apps and each app governs their own lexicon diminishes a lot of its potential in the long-term.
Laurens
yeah i think i might actually, theres a very interesting story here that the main thing that matters is a focal point around which consensus over a lexicon can get formed
Every post, like, and blog entry on atproto sits in your Personal Data Server (PDS) as structured data you own, which means building experiences that are extremely customized to you has never been easier. atproto + AI is incredibly powerful! #atproto
Atproto Is the Context Window You Own - The Tropopause
pckt.blogsome thoughts on atproto as a post-app paradigm
Ecosystem Plugins
notes.wesleyfinck.orgImagining atproto as a post-app protocol starts with materializing the social filesystem โ decomposing apps and their data into materials and instruments. For the time being, this guestbook is a good example where the display element is a material and the sign element is an instrument.
dan
in any case, the end game is composing these little guys, whatever goes on behind the scenes. social components
Hot take but I think itโs problematic for atproto that lots of developers i see talking about making stuff focus mostly on things absolutely no end user gives a shit about to fuel their protocols and architecture fetish, and itโs a failure there isnโt another app with like 100k+ users active even.
An underappreciated #atproto feature is that whenever apps want to update your data: 1. they ask your PDS for permission, 2. your PDS asks you, 3. you can say no, + 4. your PDS enforces your wishes As of today, the @tranquil.farm PDS UX lets you give "partial no" answers to question 3. Bravo!
Trezy
This is awesome. I made a PR last week to add better support and display for permission-sets to the OAuth consent screen for @tranquil.farm. Now every time I log in to my Atmosphere account, I can actually see my fingerprints on Tranquil. ๐ #atproto
What's the intended app/user etiquette for atproto apps with regards to publishing to the same lexicon? Like, say I build an atproto app, would it catch users by surprise if the wrote to the same records (e.g. posts, likes, etc?) that show up in the bsky.app? Or should my app be isolated?
the single most important part of atproto is the PDS as a user-controlled auth and storage layer to which clients can connect directly. death to appviews
Authenticated Transfer Enables Orchestration - nekomimi
blog.nekomimi.petto reiterate on this, an AppView server should NOT be interposed between the user and the PDS: the client and PDS are in the user sphere of trust, but the service is adversarial. the PDS is the most important write sink and should be primary, since an app can't be trusted to not shut off PDS writes
mary๐
doesn't mean i shouldn't try. mary.my.id/musings/atproto-and-oauth
It would be great to get some transparency in here. @janlindblad.bsky.social: 1. will users be able to use the w social app with any #atproto account? 2. will users be able to verify themselves (to be able to post) with any atproto account or do you require users to move their accounts to your pds?
Rehashing this... if the main concern for atproto clients writing directly to the PDS is not having optimistic writes, then I don't get why we'd want to move towards a app server architecture as opposed to a local-first one. Are there other examples when server side computation is necessary?
The politics of purely client-side apps
pfrazee.leaflet.pub
