The Great Western Railway was established in the UK in 1835. A fundamentally networked technology, rail started as contingent, bespoke 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, for instance. 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 useful for daily life and economic prosperity, the networks grew like bacteria on an agar plate until they met the boundaries of their neighbor rail 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 had grown to sufficient scale so as to butt up against one another, institutions, bureaucracies, and cultures also had grown around them. What had once been contingent decisions about the gauge width instead became "competitive moats" that locked customers in with their lack of interoperability. The cost 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. And so, you'd accept the inevitability of the break gauge.

As the value of the network scaled exponentially, the friction induced by this corporate intransigence became more stark. "Wars" broke out in the US and the UK, and on the path to broad adoption of the standard gauge, many 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 is the standard gauge moment for human-to-human communication online. We can see analogues of the break gauges, and the value of moving beyond them, 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 valuable time, they've grown to justify a lack of interoperability as their "competitive moat" - a tool to lock us in, to force us onto 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 need for themselves and their communities, 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 unburdened by 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.

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's future, 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 for us to just 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. But because we are interoperable, the work was already done. We had records of all the videos they were already showing their users - they are a commons on ATProto. We were already encoding all those videos, because we have a ton of other reasons to do it for our other users on Bluesky. 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, then re-rank candidate videos for a viewer. We got an alpha out the door with an R^2 of 0.22, and it was clear it was starting to get a bit better, but had a bit more to go. More firefighting elsewhere for the rest of that day though.

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 sampled 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.

The standard gauge gives us more than just a hotfix for Skylight, though. 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. The standard gauge provides a much broader network for the value of our labor to spread across.

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 (somewhat fraught, somewhat problematic, somewhat dirty) 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 getSortedSkeleton out in the hands of the community. 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.