The politics of purely client-side apps

Bluesky’s big split: app brains vs your data boss

TLDR: Bluesky’s ecosystem is debating whether posts should go via your personal data server (user control) or the app’s server (speed). Comments split between “make it simple” and “trade-offs matter,” with one user linking the PDS repo while another questions why it’s so complex.

Bluesky’s dev world just dropped a spicy debate: should your post go straight through your Personal Data Server (PDS)—your own little data vault—or should the app’s server do the talking for you? Option 1 gives users power: the PDS can intercept and tweak traffic, keeping apps in check. But it’s messy—“200 OK” can mean “your post shows up… eventually,” turning Tada into “Ta-da (later).” Option 2 feels faster and simpler: your app handles everything and talks to the PDS behind the scenes, but that shifts power from users to apps.

The comments turned into a vibe check. Helpful hero move from kenforthewin dropping the what-is-PDS link, because half the crowd was like, “Wait, what does this acronym even mean?” Meanwhile TekMol brought the flamethrower: “Why is this so complicated? Can’t we just sign posts with a private key and broadcast?” The keep it simple camp cheered, while platform pragmatists shrugged, saying trade‑offs are real. Folks riffed on the article’s own “200 OK” and Tada, joking it’s more like “200 OK, but not OK for my feed.”

Bluesky still runs Option 1 today, but with OAuth (log-in plumbing) arriving, guidance is nudging to Option 2. The community heat: user control vs smooth performance, and nobody’s ready to declare a winner.

Key Points

  • Two posting architectures are outlined: PDS-proxy (Option 1) and app-server-to-PDS (Option 2).
  • Option 1 allows pure clients and PDS traffic interception but lacks server-side computation within a transaction and has indeterminate indexing delays.
  • A workaround in Option 1 modifies `getPostThread` at the PDS to inject recent posts, embedding app-specific logic into a generic component.
  • Option 2 centralizes interaction through the app server, improving immediacy and performance while reducing the PDS’s direct influence.
  • The Bluesky app still uses Option 1, but with OAuth available, current guidance favors adopting Option 2; community alignment is needed.

Hottest takes

"If, like me, you were wondering what PDS stands for:" — kenforthewin
"Why is this so complicated?" — TekMol
"Shouldn't this be enough?" — TekMol
Made with <3 by @siedrix and @shesho from CDMX. Powered by Forge&Hive.