Build an AT Protocol PDS

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.