The politics of purely client-side apps

You post a post on BlueSky. how does this work?

Option 1:

• your customer calls putRecord on user’s PDS

• 200 ok, record made

• Records go to Bluesky server via relay

• Bluesky servers index new records

Option 2:

• your customer calls createPost on bluesky server

• bluesky server call putRecord on user’s PDS

• Bluesky servers update their indexes

• 200 ok, record made

• (The record becomes visible again through the relay and can be re-indexed if necessary)

Both of these are now possible in the atmosphere, but which option is “good”? It turns out, this is a very subtle question.

Option 1 – PDS proxies all traffic

Option 1 is the “PDS proxies all traffic” philosophy. In this model, the client logs in to the PDS and then sends all traffic to Atmosphere by proxying through the PDS.

This has some interesting results:

1. Customer converts records by writing directly to PDS

2. PDS is able to intercept and modify traffic on apps

3. There is no opportunity for server-side calculations within the lifetime of the transaction

Points 1 and 2 have positive political implications. The ability to write directly to the PDS means that third party “pure clients” (with no backend of their own) have a lot more freedom in the way they work. The ability to then intercept and modify traffic means that a PDS can make decisions on behalf of its users that may contradict the decisions of the application. Both of these are a good balance against the power of an app.

However point 3 is absolutely useless. What is not clear about the flow of option 1 is that the time between “200 OK” and “Bluesky server indexes the record” is indeterminate. 200 OK ends the transaction from the client’s perspective, so now the client has to struggle to show the user the action they just took.

Right now, PDS takes advantage of traffic blockage to modify getPostThread And inject user’s recent posts. This works, but means that the PDS has Bluesky business logic built-in. Not only is this an ideological violation of PDS – which is considered normal – but it is also an option that is not available for every app.

Option 2 – App server talks to PDS

Option 2 is the “app server talks to the PDS” philosophy. In this model, the client logs into the app, which in turn logs into the PDS, and then the client talks entirely to the app. The app then talks directly to the PDS to modify requests.

This basically removes all 3 results in option 1. There is no problem in ensuring that users see the action immediately after the transaction, but now that the customer is not in communication with the PDS the political power of the PDS is reduced.

What should we do here?

Ultimately, the atmosphere community will need to align on one of these two approaches. The BlueSky app still uses option 1, but now that OAuth is here the guidance we’re giving is option 2. Is this the right call?

I’m really torn on this. I’m just going to dump a variety of ideas, some of which are contradictory.

• Purely client-side apps are a good thing

• This sucks when you’re building entirely client-side and can’t do exactly what you want to do, or can’t get your customizations to perform well.

• Services like Microcosm are great for enabling those customizations

• Option 2 is more intuitive to me than option 1.

• Option 2 will always perform better

• Currently it is very expensive to build a full network app server in Atmosphere

• The ability of PDS to stop and modify traffic is really good

• The role of PDS within the political economy of the environment is still not entirely clear, but acting as some kind of counterbalance to applications is a really promising idea if we can get more clarity about how this would work.

My mind says that we should lean towards option 2 because it is more straightforward and because it enables app developers to do more. To handle costs I think Bluesky’s servers should be available almost like a cloud service, which would greatly reduce costs and generally increase the ability to implement new or different behavior for third party apps. This would essentially transfer the political power of the PDS (i.e. to intercept and modify traffic) to third party applications.

Just some thoughts.