The Great Western Railway was established in the UK in 1835. A fundamentally networked technology, rail started as contingent, idiosyncratic tendrils carting goods short distances on proprietary tracks, each designed for the particular needs of the company that built them. Idiosyncratic widths worked fine for isolated networks operated by independent companies with non-overlapping services. Narrow gauges are cheaper to build, and work better in mountainous areas, typically. Wider tracks offer more stability for the cars atop. In the early era, contingent preference chose the path forward.

Over time, as rail proved increasingly vital to the way of life and increasingly central to economic prosperity, what once began as those contingent tendrils grew like bacteria on an agar plate until they met the boundaries of their neighboring networks. At those boundaries were “break-gauges” (illustrated above), or platforms where two different track gauges met. All persons and cargo would de-board the train at one edge of the network frontier, and re-board to continue their journey on the other network.

By the time these networks grew to sufficient scale so as to butt up against one another, institutions, bureaucracies, cultures, grew around them. What had once been contingent decisions about the gauge width instead became competitive moats that locked customers in with a lack of interoperability. The costs of rebuilding the network from the ground up were too great, the customers too valuable, the contingent decisions buried too deep in the sedimentary layers of the organizations. As the value of the network continued to scale exponentially, the friction induced by the intransigence of the companies became more stark. “Wars” broke out in the US and the UK, and on the path to broad adoption of the standard gauge many once unthinkably large companies went bankrupt by digging in their heels and refusing to change. Trains that continue to use non standard width exist, albeit at much higher unit cost and on much more limited networks (see BART vs The NYC Subway).

ATProto as Standard Gauge

ATProto is the standard gauge moment for human-to-human communication online. We can see echoes of the history of rail in the benefits of ATProto in Dan Abramov’s Open Social post, or the ongoing series of we can just do things moments in the ATmosphere the last few weeks. Incumbent platforms built their empires upon a once-contingent set of small decisions about how to lay out their idiosyncratic tendrils 20 years ago. Over time, as those networks have competed for our time, they’ve grown to justify a lack of interoperability as a “competitive moat” - a tool to lock us in, to force us to the break gauges if we ever hope to go somewhere else. Better to keep you looping around in the network than to let you frictionlessly go where you may desire.

We work at Graze because we envision a future of open social that is locked open by default for all stakeholders - for all curators to build the experiences they think need to exist in the world for themselves and others, for all readers to consume information the way they want, and for all platforms to be free of the burden of reinventing that wheel every time. A vast, open, interoperable exchange where people curate and consume what they want, with no exit costs, creates the conditions for fair competition. Fair competition on a common network, in turn, creates the conditions for an internet that is more responsive to a broader set of stakeholders - high exit costs out, credible exit in.

One Small Case Study

To bring everyone along into this future, we have to keep showing how we can just do things. In that effort, we wanted to share a recent sprint we did with Skylight. As a result of the continued capricious decision-making around TikTok, Skylight’s seen a 50x increase in signups, which in turn cranks up the urgency of building great feeds that users want.

In the pre-ATProto world, it’d be immensely painful to start helping Skylight. We’d have to get access to all their data. We’d have to encode all the videos on their platform into our database, get some vector representations for all the videos, and work through their idiosyncratic track widths of how they laid out their system, from API down to record schema. Because we are interoperable though, the work was already done. We had records of all the videos they were already showing their users. We were already encoding all those videos, because we have a ton of other reasons to do it for our other users on Bluesky before we even started chatting about helping out. We’re on the standard gauge, so we just kept rolling along.

Within a day, given a sample of watch time data, we had a workable engine that would provide Skylight with a “FYP” we created - a mix of content similar to content the user already liked, content people like them liked, some fresh stuff, and some more evergreen trending stuff. Not great, but not terrible, and built in a day. We set it aside and tended to the other fires that are typical with an early stage company.

A week later, we revisited, and agreed in principle to build out a rudimentary update to the feed that would attempt to predict watch time on the feed, then re-rank candidate videos for a viewer based on that. We got a crappy alpha out the door with an R^2 of 0.22, and it was clear it was starting to get a bit better. Another day, another quick back and forth, and we built an upgraded engine that blew past the initial individual-level recommendation engine - the FYP today is now sorting posts with a model that scores at about R^2 ≈0.56 - in its out-of-sample training dataset, it can predict watch time ±2 seconds for about 45% of all videos, and ±10 seconds for 80% of the cases. Most importantly, we found that re-sorting the feed with this model is hugely beneficial in providing a feed that is more watchable than the previous random assortment.

getFeedSkeleton -> getSortedSkeleton

The standard gauge gives us more than just the fix for Skylight. We all breathe air in the interoperable ATmosphere now. Last night, we realized that we could take the learnings from this single FYP feed, and apply it to any set of videos. We created an internal (and ideally, long term a fully public) POST getSortedSkeleton endpoint that consumes as input a typical GET getFeedSkeleton response, and returns that response sorted by the amount of predicted watch time for the provided user. What’s more, we aren’t bound by Skylight’s rail network. There’s no break gauge. The FYP works equivalently on Bluesky, and any video-only feed on Bluesky could use the propensity sorter to immediately re-sort for a viewer’s likelihood to watch.

We’re still building systems with old skeumorphic assumptions, because we’re still at the very beginning of ATProto. So, while the watch time maximization is a loan concept from the previous era of social media, it doesn’t need to be the end of the experiment. Indeed, on Skylight, you can access any video feed that comes from any particular algorithmic or curatorial process - ours is just one in a sea of open competition and low switching costs. Soon, we hope to get the sorter out in the hands of others. After, we hope to help people explore their own maximization functions, to help us all dig out from the externalities legacy platforms put upon the internet that we have to fix together to build credible, useful futures for the next 200 million people to join the ATmosphere.

We’re all realizing we can just do things - the reason we can just do things is because we’ve entered the standard gauge era. We’re building our company faster because we can build feeds across multiple platforms simultaneously, and Skylight is building their company faster because they get to focus on the parts that matter most, and lean on the things-doingness of the ATmosphere for the rest. It’s an exciting future, we’re looking forward to continuing to do things, together.