Collection
The political economy of the PDS
Updated 2d
On the infrastructural and political positioning of the PDS in atproto, in concept and how it's played out so far.
Collection
Updated 2d
On the infrastructural and political positioning of the PDS in atproto, in concept and how it's played out so far.
Why Backend-for-Frontend for Solid is categorically wrong
Recently the Inrupt team (@maxleonard) posted an article titled “Backend for Frontend for Solid”, and here is my response to that (originally posted on LinkedIn) Backend-for-Frontend for Solid is absolutely and categorically the wrong approach for building Solid applications, in my opinion. This results in Solid just effectively being used as data storage, without the other benefits of controlling & knowing where your data is and what systems your data feeds into or is stored into. All the app...
Authenticated Transfer Enables Orchestration - nekomimi
Digital Topology & Economic Power
The autonomous file, once the basic unit of user agency in personal computing, was first hollowed out through proprietary formats and data internalization, then abolished entirely by cloud platforms, relocating control toward incumbents at each stage. Enclosure succeeds not by offering users less, but by bundling genuine capability gains with topological restructuring, so that the user cannot accept the improvement without accepting the new relationship of power.
What I Wish Someone Had Told Me About AT Protocol and Bluesky - Stuff Rob Wrote
I've been interested in atproto (the protocol that Bluesky, Blacksky, and many other applications - including pckt, where this blog is hosted! - run on) for abo...
The politics of purely client-side apps - Paul's Leaflets
There's a surprisingly nuanced discussion in development about the political economy of clients and servers in the Atmosphere
AT Protocol, OAuth, and well, decentralization
I've been very happy with how Bluesky and AT Protocol as a whole is going, except for one thing: OAuth.
to add to this, there’s a few product-y reasons why I would really like a createPost API 1. we could run a server-side language detection model that actually works, so we wouldn’t need the language select in the client (it sucks) 2. you wouldn’t need to specify a createdAt time anymore (cont.)
P(aul) Frazee
Nerding out about the question of whether the client or the server should be the one who speaks to the PDS
to 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
atproto offers an fascinating example of what it means to restructure this relationship. End-users get to choose who and how much trust they delegate to software producers, the delegation of trust becomes tangible and revokable.
𝕮
Networked computing, in a fundamental way, changed the producer-consumer relationship we have with corporations. In the material world that relationship ends with the transfer of material and money; I buy a pencil and some paper, and the producer is out of the picture while I use them to write.
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
