Post

P(aul) Frazee
@pfrazee.com

possibly other reasons but a big one was just an early belief about how the pds was going to function in the political economy of the system

0 reposts23 likes

P(aul) Frazee
@pfrazee.com

again, this isn't the whole story - there were practical benefits to it, and we didn't yet have the oauth story so it was harder to do the inverse but

P(aul) Frazee
@pfrazee.com

In the early days the conceptual framework for AT was that the PDS was your user agent in the cloud. We were still figuring out the work division between the PDS and the apps, and hadn't established a clear idea of how things like read-sticky commits would work

P(aul) Frazee
@pfrazee.com

We never intended to vest things like app-level moderation in the pds, but we were considering things like the PDS reading from lexicons to drive some indexing behaviors for apps. For very good reasons, we moved away from that

Kuba Suder 🇵🇱🇺🇦
@mackuba.eu

Oh lol, that's literally what I wrote in my ATProto blog post (but then Dan told me it's probably not gonna be the right metaphor forever)

Kuba Suder 🇵🇱🇺🇦@mackuba.eu

Does this metaphor I used in this blog post that your PDS is kind of like your user agent make sense? 🤔 What I mean is, at least in the current setup, if it's under your control, it "represents" you on the AppView, it hides your client IP from it, can lie about verification, override things etc.