search

bluesky-social / atproto

Social networking technology created by Bluesky
Other
7.51k stars 537 forks source link

Please define a clear separation of interfaces between PDS and AppView #2221

Closed imax9000 closed 9 months ago

imax9000 commented 9 months ago

Currently PDS proxies most requests to AppView. This is suboptimal, because the user doesn't have control over which AppView is used (and which moderation policies apply).

Ideally a PDS should know nothing about any of AppView instances, and it should be up to the application to use an appropriate instance, and even allowing the user to choose an instance.

bnewbold commented 9 months ago

That is roughly the plan: the client will set an HTTP header which specifies which appview instance to use for the request.

There are a some bike-shed decisions to make (standard HTTP proxy header? or something atproto-specific? what about caching?), and security issues to think through (should PDS check that the remote server "speaks atproto" before forwarding?), but this is the general direction.

imax9000 commented 9 months ago
  1. Is there anything preventing an app to talk to appview directly?
  2. Clearly defined interface split has other benefits too, e.g. less ambiguity when writing an independent PDS implementation.
bnewbold commented 9 months ago

Requests to the appview are currently authenticated using "service auth", basically a JWT. If a client wanted to talk to an appview on-behalf-of the user, it would need to wrangle such tokens, which are currently created and controlled by the PDS. IIRC this is now technically possible (via a new endpoint intended for account migration), but it would probably be inefficient, and this wasn't the intended use of that endpoint. As OAuth gets going, there might be some way to wrangle that in, but seems complicated.

But in general, no, nothing is really stopping an app (or any other software) from speaking directly to an appview. For example, logged out clients and apps must talk directly to the appview. There is a somewhat open question around what is "best practice" for authenticated clients, and what should be encouraged. There are potentially metadata privacy and security advantages of folks having a high-trust relationship with their PDS, and making basically all atproto network requests through their PDS. There are some network latency and efficiency arguments for doing direct requests to AppViews though, especially if your PDS is in a remote geo-region without anycast (or similar).

Definitely no argument that a clear separation of interfaces between PDS and AppView makes sense. Do you think they are particularly unclear right now, having dug in to the details? Effectively everything app.bsky is AppView, and everything com.atproto is PDS (or infra/admin). We definitely need to indicate better which require auth. There is a bunch of moderation service stuff in com.atproto that we will probably move out, specifically to make the interface boundaries clearer.

imax9000 commented 9 months ago

Definitely no argument that a clear separation of interfaces between PDS and AppView makes sense. Do you think they are particularly unclear right now, having dug in to the details? Effectively everything app.bsky is AppView, and everything com.atproto is PDS (or infra/admin). We definitely need to indicate better which require auth. There is a bunch of moderation service stuff in com.atproto that we will probably move out, specifically to make the interface boundaries clearer.

I have very little experience with serving HTTP requests from typescript, so the code looks like a rats nest to me 😅

Thanks for clarifying that it's mostly separated on the namespace boundary, that helps a lot!

Requests to the appview are currently authenticated using "service auth", basically a JWT. If a client wanted to talk to an appview on-behalf-of the user, it would need to wrangle such tokens, which are currently created and controlled by the PDS

IIRC, user's bearer token is also a JWT. But technical details are probably a subject of a wider topic of inter-service auth and identity forwarding/assertion.

My only note on that for now is that AppViews should not pay much attention to whether it's PDS sending a request, or a client directly, since in general case it's impossible to distinguish them from each other.