Build an AT Protocol PDS the hard way (from scratch).
On Feb 1, while reflecting on slink, the Go XRPC code generator that I built in January, I casually wondered “what else do I need to build a PDS?” Thinking through it, I estimated that it would take at least a few weeks and at most a couple of months, which seemed doable and worthwhile for reasons listed below.
Now here we are.
Pros#
- This gives me a deeper understanding of AT Protocol and the infrastructure needs of the community.
- I can use this to control my own identities.
- An independent and minimal PDS implementation could be a great starting point for experimentation.
- Building the producer side of OAuth can help me improve IO’s consumer-side OAuth support.
- There are a lot of parts of IO that I can reuse.
- An independent PDS implementation could be better matched to my own editorial opinions about what a personal PDS should be.
- Building the PDS in parallel with IO might give me insights that make both better.
Cons#
- It takes time away from IO.
- It’s not aligned with community work on existing PDS implementations.
- My implementation follows architectural decisions from IO (project structure, SQLite storage, SSH TUI and CLI) that ultimately might not be right for a PDS.