Post

charlotte 🐇
@char.lt

broken record ik but it's very unfortunate that this is set in past tense when PDS -> app service proxying is key to actual use cases of altering undesired app behavior today (e.g. age assurance circumvention, feedgen sponsored item elision, etc)

P(aul) Frazee@pfrazee.com

So anyway, one of those early ideas was that by proxying through the PDS we created similar benefits to having an extensible browser. Rerouting or blocking requests to alter application behaviors, things like that. The logic was to act as a political backpressure to the applications

charlotte 🐇
@char.lt

just doesn't feel like skipping one header on the client and targeting the url straight at the app server is a DX benefit big enough to justify ceding control from infrastructure the user controls to opaque (unchangeable!) territory of the future adversary, even if u do get to do serverside RYOW

charlotte 🐇
@char.lt

feels much less ulysses pact feels much less locked-open when the app server can just go "yeahhh well im gonna keep ingesting this data u give me but i wont keep writing records to PDSes because i got a competitor trying to adversarial interop me"

0 reposts21 likes

*ptr
@starptr.andref.app

Wait this is a good point. What’s stopping new appviews from just not writing to the PDS and using their own storage? This is already happening with some (very popular) apps (tbf, for decent reasons)