Why AT URIs are not valid under IETF RFC-3986, what the impact is, and some possible ways forward.

A small tweak to the labeling system to allow richer context and annotations

Some very in-the-weeds papercuts with event stream sequence numbers, and some ideas to address them

Riffing on some ways to make network services more legible to humans and machines

Proposes some small additions to lexicon schema language.

mini-proposal for referencing atproto blobs in AT-URIs

Scaled-down design patterns

Hacking in 'const' output behavior

A couple of weeks ago at Eurosky I talked to some friendly Erlang hackers who wanted to get involved with AT development. The AT network is a big data-intensive distributed system, and it is the sort of thing the BEAM runtime is well-suited for. I know Chad Miller has been using Gleam for parts of Slices, and services like relays, jetstream, and the forthcoming tap tool could all be re-implemented using Erlang-y tools. But I think these tools, written in Go, are already in a pretty good place: they are efficient enough, are not too hard to operate (IMO), and have capacity to scale. hose.cam lists 9 full-network relays from 7 distinct parties.

The people, they want post editing!

When I first started working at Bluesky, the team was all remote and I worked out of a rented office. I'd almost always procrastinate lunch and end up walking to a nearby bakery for a late afternoon slice of pizza. Inevitably i'd end up thinking over little protocol warts and design challenges. Sometimes these related to current work priorities, but often they were tangential or just small things that bothered me.

How should public community-controlled spaces be represented in atproto?