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.
Collection
Updated 2h
On the infrastructural and political positioning of the PDS in atproto, in concept and how it's played out so far.
I think there could be a genuine use case for PDS proxying and modifying requests lurking with app preferences.
The disconnect between the social filesystem and web pages. - Chris's Corner
blog.chrisshank.me𝕮 • Chris Shank
A proposal for opening AT URIs
one thing in the current atproto landscape that worries me a bit is how much (particularly post-oauth) a lot of the ecosystem is starting to build around or assuming patterns where we dont draw a distinction between clients/user-agents vs the rest of an application and where the application backend
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.
𝕮 • Chris Shank
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.
This seems like a crucial questions about what "data ownership" means for atproto. If the 3rd party doctrine applies, as Mike suggests, then I'm not sure it's possible to claim ownership unless it's self-hosted or it doesn't apply to your PDS host. Something to watch when permissioned data lands.
Tynan Purdy ⁂
@masnick.com I’m listening to your interview with @reckless.bsky.social. This third party doctrine is interesting. Do you think that atproto data would be considered properly owned by the account individual? Would be interesting implications if that public data fall under search and seizure rights.
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.
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
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.pubTaking this a step farther, what if we popularize the idea of Account Service Providers (ASP) and advocating for laws where: - accounts on the internet are separate from apps/platforms - ASPs follow net neutrality - ASPs must interop so accounts freely move between them (like phone numbers)
Robin Berjon
One thing I've been toying with, instead of talking about "PDS" and cryptic nonsense like that is: Atmosphere Service Provider, like an ISP but for the social internet. Part of the motivation is that "Sign in with Atmosphere" only works if people have seen that before.
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
I think we need a "PDS as a Service". There are a bunch of little apps I'd love to make, but I don't want to have to host a PDS for each of them for anyone who doesn't already have an account. But I'd be fine with allowing them to register to a PDS with my app's domain and pay a fee per sign up.
