charlotte 🐇

@char.lt

charlotte or cinnamon. 25 ^-^ technician & artist en/fr/한/es OK, 🔎 char.lt/bio

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)

Paul Frazee@pfrazee.com · 10mo ago

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

i don't really know what to post on main i'm having lots of fun lately but not really working on software or music which is kinda what i wanted to distill down to on here

alternatively the pds could generate some state that only the client needs to know and shove it in the fragment part of the uri on post-oauth redirection. then you make your requests with the token + the server's assertion that the client secret is known + the client-only state

charlotte 🐇@char.lt · last yr.

on oauth in particular i think it would solve some concerns if the client could pepper the pds' tokens with additional cryptographic state on the first request this way u need access to the nonces AND the server's tokens, so u can't make spurious requests without going through the user's own device

the idea of a bluesky client having to proxy requests to a server who could be logging god knows what just so i don't get logged out at the end of the week disgusts me

the best action Bluesky PBC can take to further indiesky decentralization development is to abolish their on-call rotation for a day or two and let everyone on the team chill out and have a little downtime maybe