Sports in the Atmosphere

Lessons from attempting to build an AT proto sports app and how to actually make it happen

Aug 4, 202617 min read5 reads

uthor's Note: I wish I had more time to organize and edit this, but in light of the Bluesky sports discussion Decoder interview with Toni Schneider yesterday, I am going to publish it now to try to keep the discussion going. Shout out to @michael.bsky.team for starting the discussion on Bluesky that lead to this and for suggesting I continue it in this format.

When I first became interested in creating an atproto app at the end of 2025, my first thought was something involving sports scores.

The synergy between live sporting events and microblogging has been apparent basically as soon as microblogging existed. This December 2009 Denver Post column included as one of the most influential sports technology of the 2000s:

But the biggest sports story of the 2000s was the marriage of technology and information — iPhones, iPods, the Internet, Twitter, high-definition television and high-tech stadium experiences changed the sports landscape for fans and athletes alike.

Almost exactly 10 years ago in July of 2016, Twitter made a serious play into live sports streaming to put next to the discussion. For whatever reason, that didn't end up working out.

However, there really hasn't been anything that has done much to improve the basic experience of microblogging as a second screen experience to bond with a community of fellow sports watchers during the games since probably the hashtag was introduced in 2009.

The Destination

I don't have a fully thought out vision for the killer product in part because it is mostly likely to be a range of products, features and experiences that collectively do it, but I am convinced that putting sports scores and data on atproto has a serious chance to unlock that next level of live sports event second screen experience.

For example, I was among the many millions of people who got caught up in Cape Verde's World Cup games against Spain in the group stage and Argentina in knockout rounds and really enjoyed reading all the posts from people doing the same thing. But I was missing out on the types of analysis and insights from knowledgeable people that I get when I watch an NBA game because of the people I follow for precisely that.

For an hour, I wanted to see posts from people who really knew this Cape Verde team. People who were posting analysis during World Cup qualifying games in 2025 or fans who had been cheering on the team through previous World Cup qualifiers when they failed to qualify.

Yes, that sort of thing could be done right now. There are probably feeds that existed that I should have been following in those moments.

But that’s the challenge of taking what is already a pretty good experience and taking it to another level for what can be an extremely short period of time where users' attention is already divided between the game on their TV and the social media experience on their phones.

Scores Apps

When I first started thinking about building an atproto scores app, I assumed it was pretty straightforward to try to build something and the limitation was going to be the learning curve of atproto and how much time I could spend on it.

That turned out to be quite wrong.

It is not that difficult to build something and in fact I have created more than one proof of concept attempt at this point.

The problem is that the game changing feature for a scores app would be hooking into all the Bluesky posts to organize them by game and no matter how you start, you end up realizing that the key to the whole thing is at least some basic support for features from the actual Bluesky app.

I first set out to do it without much of a plan other than to put game scores on atproto and connect them to posts. From there, when you start adding all the necessary features it would take to actually make it usable and it quickly progresses to virtually a full scale Bluesky clone.

Obviously, that is doable as there are multiple examples. However, those all offer different takes on existing Bluesky features and thus leverage all of the existing network effects. Adding an additional lexicon that don't exist in other apps can mean throwing away all those network effects and starting over from scratch. It can be done, but it's difficult and ultimately the goal would be for any new features to be adopted by all of the other microblogging clients in the ecosystem, including Bluesky itself.

I tried one that allowed for creating the post to game connections after the post already existed, but then you are really building a third screen experience. Let's generously call that not a very good user experience.

I tried to work around that problem by building a version that used hashtags and custom feeds which means that you don't ever have to leave the Bluesky app to connect a post to a game lexicon or to view posts about a game. It can be done except when you take a step back and think about what all that code is adding, it's actually nothing more than the existing hashtag functionality and is in fact inferior to the feed creation tech that already exists.

My best guess is that eventually an ecosystem of scores apps will exist on a spectrum from those that center regular posts and feeds in the user experience and are basically current microblogging clients with some sports score integrations added on to those that are built around games and scores first and then add the microblogging features on top. Creative app designers will likely find ways to create hybrid experiences that sit somewhere in between those.

Starting with the scores centered app before anyone has any way to connect posts to games means forgoing all the existing posts about sports until the new app gains some traction and there is no guarantee it ever will.

Building in essence a Bluesky clone with the sports features added on means doing a bunch of work to create a demo of a new feature in hopes that they adopt it and render your own app completely redundant. I decided there had to be a better way and hopefully writing all this is it.

With other types of data, like standard.site, if the data is being created by users in atproto, it makes sense to wait until something starts to develop from the community before integrating anything with Bluesky. Sports scores already exist off protocol, so the only atproto native features are about the connections themselves and makes the case for Bluesky to lead on this much stronger.

If I were going to make another attempt at this, I would not even bother to start with any sports data on atproto. No need to take the extra step to convert scores to atproto before aggregating them in your AppView. Users would sign in with atmosphere accounts only to select favorite leagues and teams to customize the appearance of games in the app.

Instead of worrying about getting people to connect posts to games, work at trying to automate the creation of feeds for each game utilizing data like the current team rosters that pulled in as many existing posts about the game. The majority of posts about sports are likely going to be through the official Bluesky app for the foreseeable future, so any experience worth using is going to have to pull in those posts. Worry about finding a user base interested in a sports score centric Bluesky second screen experience first. All of the actual atproto scores features are a curiosity for atproto developers until there is a critical mass of users posting from an app that is looking to implement them.

Sports Data is an Awkward Fit for AT Proto

The discussion of how to actually put sports data on atproto ended up being largely a tangent to the rest of this post, so I stuck that discussion in a subleaf.

The challenges can all be overcome, but atproto is designed to handle the challenges of user created data on the open web, not data that already exists in other places like sports scores.

Atproto data handling is designing around the ideas that:

Data is created by an unknown and growing number of users
Everything is constantly changing through an ever increasing number of apps

The most important example of how different of environments that creates are dealing with the various data aggregates. In atproto the obvious one is totaling up likes on Bluesky posts. Likes are stored in each user's PDS and then the AppViews have to aggregate them.

There is no source of truth for aggregate data in atproto and it's delegated to the AppViews because for total likes on a popular Bluesky post, it's a genuinely difficult question to answer. The answer depends on whether any additional users anywhere on any app have added a like to the post or removed one since the last attempt to add up all the likes.

Technically, no AppView is going to be able to have an up to date accurate count at any given moment in time due to the lag time it takes to receive and process updates. We are talking about potentially only fractions of a second and for posts that receive enough likes to be changing that often the precision to know at what moment in time the total being displayed was calculated just isn't that important.

However, the total itself is just a simple arithmetic problem to add up the number of valid likes. Repeatedly calculating the total is not an issue because it's so trivial and by necessity must be constantly recalculated even if it is stored from some period of time because it can change at any moment.

Conversely, sports data is typically coming from a single source, the official stat keeper, and once a game is final (and the necessary time frame for which the league or event allows for stat corrections has passed) there is really no need to ever recalculate any aggregate totals ever.

The number of points Michael Jordan scored in the Flu Game is always going to be 38 and Messi's goal total at the 2026 World Cup isn't changing after the final whistle blew in the final. It's not necessarily a problem to constantly recalculate these totals from the original sources, but there is also no reason to do so.

Phrasing it that way is also a bit awkward in the context of sports data because it invites the question as to what exactly is the original source of something like Jordan scoring 38 points in Game 5 of the 1997 NBA Finals? Were the Bulls 90 points that game the sum of each players' points or do the points actually belong to the team? In a sports sense, these sorts of questions are nonsensical - the points belong to both Jordan and the Bulls simultaneously and equally.

But if you are going to put sports data on atproto, in a computer science sense, it matters and you have to pick.

The true lowest level data generated by sports is typically play by plays. There exists even more granular player tracking data, but we will be incredibly lucky to get to the point where that is a problem that needs solving.

Going through the play by play from Game 5 of the 1997 NBA Finals and adding up every basket scored by Michael Jordan can yield his 38 points, 7 rebounds, 5 assists and 3 steals from that night.

Screenshot of the play by play of the beginning of the Michael Jordan Flu Game from basketball-reference.com

But trying to do it that way encounters some problems:

Not every game has play by play data and even within leagues or levels of play it can be inconsistent. The 1996-97 season is the first one that the NBA had it. Plenty of leagues where many people care about the scores, such as high school sports, still don't today.
Play by plays are compiled by stat keepers during the games and it's not necessarily the case that every post game stat correction results in a corresponding correction to the play by play data.
Not every stat is necessarily in the play by play data. For sports with live substitutions like hockey and lacrosse, play by plays may not include substitution data and so a player that gets into a game, but doesn't record a stat of any kind that does show up in the play by play will have a game played.

These are certainly solvable problems and all three of these are solved by going one step up in granularity and making game box scores the base unit of accounting.

You could start with the point total of each player, then treat the team total for each game, which team won the game, season long team records and everything else as aggregates of those.

However, it's worth stepping back a moment and asking why put sports data on atproto in the first place?

Until someone builds atproto native stat keeping software, getting sports data into atproto will involve taking data that is created and stored somewhere else, converting it to an atprotonic format to get it on the protocol to transmit it, and then in converting it back to something resembling the original format in an AppView to actually be able to do anything with it.

A final step that isn't necessary in many other cases will be checking important aggregates, like the final score of each game, to make sure no mistakes in the play by play or other chosen base unit of data spill over to impact anything else. Unlike ever changing like counts, there is a correct answer that will be noticed if it's wrong.

For some purposes, such as building a sports analytics model, that middle step is unnecessary and may be skipped if it doesn't serve another purpose.

That's not to say that there is no reason to any sports data on atproto. Only that starting out to build a universal way to put all sports data on atproto as an objective in itself is the wrong approach. Rather, it's likely that there will be multiple overlapping sets of lexicons because the most important aspect is the way that users will connect into the sports data.

For many potential atproto sports apps, it's the leagues, teams and games that matter and so those are the entities that need lexicons.

In an app to allow users to catch up on game scores, users could select which leagues and teams are their favorites, so those games would be shown first. A March Madness style bracket contest app that has users pick game results is similarly game-centric.

Conversely, a fantasy sports app is very player-centric and then the unit of fantasy matchups, ie weeks in the NFL, so those would need atproto lexicons to facilitate the connections to users in each fantasy league. Some of the actual teams and games data, such as team scores for each game, is only there to be displayed.

Deciding on which lexicons contain the base data and what data is an aggregate computed by the AppViews doesn't need to be universal for all atproto sports apps the same way it might in other ecosystems because ultimately all of them are copying all the data over from another source anyways.

The goal of an atproto sports app ecosystem would be that there is an agreed upon community lexicon for different types of apps. March Madness bracket contests would all run on the same lexicons so that everyone can fill out a bracket and enter any bracket pool from their app of choice. There would be a different one for fantasy sports leagues (perhaps some shared across sports and some unique to each sport?), so that every participant can manage their team from their app of choice rather than being required to use whichever on the league manager uses to set up the league.

It should be noted that even if games and teams are on atproto, sending the live score updates out over atproto isn't actually a necessary part of that process as long as the game lexicon contains enough information to uniquely identify it. In an ideal world, the leagues themselves directly put the scores on protocol from their in arena or stadium score keeping setup.

If you are already running a server process that pulls in the scores or other data from an external source and an AppView, it will always be faster and more efficient to just write them directly to the AppView.

By its nature, atproto is designed to allow anyone to write data, so any app is likely to have out of the box support for 3rd party data sources even if they don't provide any tools to help create them. This has fun potential applications where someone could distribute their beer league softball scores over the same app next to NFL and World Cup scores. Or some that update even faster or are more complete than official ones provided by leagues themselves.

But this does create potential problems. Multiple sets of data for the most popular leagues including some that may be spam. The ability for users to search and select different data providers may require moderation tools as well.

Other Apps Are Underpants Gnomes Cuckoos

To use @ricardo.bsky.social's terminology, there are plenty of cuckoos that put sports data on atproto and could be successful standalone apps, but do in a way that doesn't actually take a step towards an elevated live sports discussion. They're sort of phase 1 in a South Park Underpants Gnomes plan to get there.

Maybe there is a creative approach to make it happen that I'm not thinking about, but unlike other areas where starting to get people to add their data onto atproto takes a step, getting sports scores onto atproto isn't the hard part.

March Madness Bracket Pool

Pretty straightforward. Works exactly like all of the existing bracket pool websites except that the picks are stored on atproto and so you can create one account and one bracket (or more) and enter it in every pool that someone you know tries to start.

The value add of atproto here seems more obvious and it fits in so well with the ability to have various existing communities use the same accounts and existing social connections.

It gets games and scores onto atproto and has people connecting user data to them, but it's also a good thought experiment to illustrate why that doesn't get you to the live sports discussion. It could be used as a marketing tool to drive user acquisition, but you still need to build out a sports Bluesky clone to enable the discussion.

Anyways, unless you are using it as marketing for another app, it's a pretty clear Underpants Gnomes Cuckoo.

Same logic applies to all sorts of similar pick'em games you can do from World Cup bracket pools (polla mundiales for those of you who hablo the Español) that are extremely popular in Latin America (and maybe other parts of the world?) to all the various takes on NFL eliminator.

Fantasy Sports

Analysis is very similar to bracket and pick'em games, so I'm not going to repeat it all here. In terms of getting to the live sports second screen experience, it's another Underpants Gnomes Cuckoo.

However, one major component of modern fantasy sports websites is that they need to have player rankings, projections and analysis every week. If you put it all on atproto, users could not only have their choice of apps to use to run their team, they could independently choose their own player rankings and projections to use for the draft or each week.

Atproto would lend itself very well to creating a whole fantasy sports ecosystem of different apps for league managers, power users who play in a dozen leagues simultaneously and casual users who don't follow the sport all that closely with further options to configure different rankings and analysis from various sources (including paid ones) in the apps.

There are some things to figure out how it all fits with atproto because I am not sure you actually want to have a 12 team league where all the data is hosted on 12 different PDSs and your buddy tries to migrate his in the middle of the season and something goes wrong. Some degree of centralization or centralized redundancy might be appealing here.

Gambling

I don't particularly care for sports gambling myself, so I haven't put much time into thinking about this, but there is so much sports gambling these days that probably something on atproto can be done.

Blockchain Reboots

There have been plenty of sports related blockchain projects that were launched in the last decade or so, mostly around various ideas for collectibles. The most successful one was probably NBA Top Shot. There are also some ticketing efforts to make collectible digital ticket stubs that have some real traction that could be done on atproto.

Did you enjoy this article?

Recommend it — Standard Reader surfaces well-loved writing to more readers across the network.

Patrick's Leaflet @pmcewen.com