The Problem No Academic Lab Could Solve
Social media algorithms shape what people see, which shapes what they believe about politics, about each other, about the world. Researchers had shown those effects in controlled settings. But Facebook controlled its algorithm. Twitter controlled its algorithm. Neither company had much incentive to let academics randomly assign users to different ranking policies during a national election.
So when Mark Torres and his collaborators wanted to test causal effects of algorithm design to actually change what people saw in real feeds and measure what happened they needed a platform where researchers could implement and serve those policies to real users themselves.
The answer was Bluesky.
Eight Weeks, Live Feeds, Real Users
For eight weeks around the 2024 US presidential election, Torres led the full technical build for what became one of the first large-scale field experiments where academic researchers, not a platform company, controlled the ranking algorithm on a live social network. The work was published in Nature.
"For eight weeks around the 2024 US presidential election, we built and tested different ways of organizing people's social media feeds on Bluesky and studied how that changed what they saw and how they felt about politics," Torres wrote in his detailed account of the project. "It turns out, a lot of how you see the world is narrowly defined by what social media companies choose and don't choose to put in your feeds."
The experiment gave users custom feeds experienced in the normal Bluesky app. Researchers got something rarer: logged exposure to algorithmically curated political content during a national election, with full experimental control over every detail of what was shown to users. No platform intermediary. No API restrictions that could be changed on a developer's whim. Just the research infrastructure connecting academic intent to platform-native delivery.
What "Infrastructure" Actually Means Here
The word "infrastructure" can make this sound abstract. What Torres actually built was a stack of interconnected systems, each requiring different technical decisions.
First, there were the data pipelines that turned Bluesky's public event stream into a queryable post corpus. Then the classifiers that labeled content for toxicity, politics, and constructiveness. The recommendation algorithms that created curated feeds based on different interventions. The API layer that exposed those feeds to any user on Bluesky. And the serving layer that let users experience custom feeds without leaving the app.
"Once you commit to live intervention, you cannot stop at 'train a model,'" Torres explained. "You need a continuous view of platform activity, a way to label and store posts at scale, a ranking engine that can encode experimental conditions, and a serving layer users can actually access."
The Data Ingestion Layer
Torres evaluated three approaches for pulling content from Bluesky: the Bluesky API, web scraping, and PDS backfills. He ultimately built around Bluesky's public event stream a real-time feed of posts, likes, follows, and other activity because it gave researchers continuous visibility into platform activity without requiring them to maintain a synchronized copy of the entire network.
He also connected to Bluesky Jetstream, a WebSocket-based service that pushes real-time events to subscribers. This let the research team capture content as it was posted more than polling retrospectively.
Each approach came with tradeoffs. The event stream meant accepting inevitable downtime periods when the service was unavailable. Pre-planning what data to capture mattered, because retrofitting new data requirements onto an existing pipeline mid-study wasn't feasible. And when Bluesky itself experienced spikes or crashes, the app behavior became coupled to those external factors something the team had to monitor and account for in their analysis.
The Intelligence Layer
Raw posts aren't enough for recommendation research. Torres built classifiers that labeled content across dimensions that mattered for the study. The technical documentation from his work describes integrations with Google's Perspective API for toxicity scoring, LLM-based classification for political content identification, and vector-based embeddings for semantic similarity and clustering.
These classifiers transformed a firehose of posts into a structured, labeled dataset that could be queried, filtered, and fed into the recommendation algorithms. The ML models were trained, retrained when they became outdated, and monitored through training logs from the console.
"I trained every ML model, retraining them when they became outdated, and watched the training logs from the console," Torres noted in his reflection on the project. "I woke up at 1am to the app crashing and thousands of unhappy users not being able to log in."
The Serving Layer
The recommendation algorithms were the point of the whole system. Different experimental conditions encoded different theories about what made a "good" feed feeds optimized for constructiveness alongside novelty alongside exposure to opposing viewpoints, and combinations thereof.
These algorithms needed a serving layer that could receive requests from Bluesky's app, apply the experimental condition to the user's context, and return a ranked list of posts in real time. Torres developed the APIs used by Bluesky to connect users to the research feeds.
The result was seamless from the user perspective: they opened Bluesky, saw their feed, and had no idea they were seeing a researcher-designed ranking. From the infrastructure perspective, every impression, every scroll, every click was logged for analysis.
The Academic Stack as Upstream Counterpart
Torres's work represents one side of a publishing infrastructure question: how do you take research findings and deliver them through platforms where audiences actually spend time? The Academic Stack platform documents the other side the upstream infrastructure that helps journals get published in the first place.
Academic Stack describes itself as "a complete Cloud-native SaaS publishing platform designed to help you launch and operate academic journals without the need for manual server installation or maintenance." The platform handles the full workflow from submission and peer review through DOI assignment and indexing.
"You bring the academic vision. We provide the publishing infrastructure," the platform's documentation states. "We wanted to make journal publishing more accessible. Enable anyone with academic resources to start a journal at low cost without compromising professionalism."
The connection to Torres's work isn't metaphorical. When academic research is designed, peer-reviewed, published, and assigned a DOI, it enters a distribution system. Torres's infrastructure is what happens when that research needs to reach people not through citations but through feeds when the question isn't "where is this published?" but "who actually sees it?"
The Two-Year Build in Human Terms
Torres has shared candid reflections on what it meant to build this system alone. "This is the story of what that project, over the course of two years, taught me about building software and about becoming someone who could build," he wrote.
He started the project as someone who could write code but had never built a full application by himself. Along the way, he built every line of code, implemented every piece of logic, owned the data and ML pipelines, trained the recommendation algorithms, developed the APIs, and "glued together all the pieces of software that made such an ambitious study possible."
The codebase reached 50,000 lines. "A testament to how much improvement is about putting in the reps, fixing mistakes, and persevering through the doldrums more than aphorisms, YouTube tutorials, and motivational speeches," as Torres put it.
He documented several lessons from the build. "Making 'good enough' tradeoffs" perfectionism that delays a shipping system helps no one. "Building yourself alongside using existing tools" the decision of when to write custom code alongside integrate existing libraries has no universal answer. "Your job is to fix problems" not to write elegant code, not to hit arbitrary milestones, but to solve the specific problems that prevent the system from working.
And one lesson that resonates for anyone building syndication infrastructure: "Having live users is where requirements become real." Nothing reveals the gaps in an architecture like watching real people try to use it.
What Syndication Looks Like in 2026
The pattern Torres built taking structured, labeled content and serving it through platform-native interfaces maps onto a broader shift in how published content generates value.
According to analysis from MGID's examination of syndicated content economics in 2026, "the way content generates money has changed drastically. Audiences spend more time inside feeds, subscription platforms and AI-driven environments. Revenue is increasingly tied to engagement within those spaces, even when no click back to a homepage happens."
Prior to this shift, the revenue model was straightforward: audience, click, pageview, ad impression, revenue. "The website was the central hub in that revenue model. Traffic flowed inward, ads were served on owned pages, and income depended heavily on whether a user completed that journey. A missed click usually meant missed revenue."
Today, the analysis notes, "monetization happens across multiple environments simultaneously: engagement-weighted feeds, revenue-sharing ecosystems, subscription bundles, licensing agreements and marketplaces, AI participation and usage-based models." Content can generate income without requiring a homepage visit.
Torres's infrastructure represents an extreme version of this pattern: research content that never existed on a website at all, flowing through a social platform's feed, experienced by users who didn't seek it out, generating data for academic analysis. The syndication wasn't about driving traffic back to a publication. It was about placing the research directly into the context where people form political beliefs.
Why This Matters for WebDiffusion Readers
The syndication question that Torres's work illuminates isn't primarily about technology it's about the relationship between where content lives and who it reaches. Academic journals have sophisticated infrastructure for peer review and archiving. Bluesky has sophisticated infrastructure for real-time social feeds. What Torres built was the glue between them: a pipeline that took research-grade rigor and delivered it through platform-native formats.
For readers researching content distribution, the lesson isn't about building recommendation algorithms or running field experiments. It's about the gap between publishing and reaching. Torres's work succeeded because he treated the serving layer as part of the research design, not an afterthought. The classifiers, the pipelines, the API, the recommendation engine these were all research infrastructure, not just engineering logistics.
Anyone working on syndication strategy faces a version of the same question: where does your content actually reach people, and what does it take to make that reach meaningful? Torres's two-year build suggests the answer involves more infrastructure than most assume.
Where to Read Further
Torres has published two detailed accounts of the project. The infrastructure design deep dive covers the architecture decisions, data ingestion approaches, ML integrations, and serving layer in 18 minutes of reading. The personal reflections on the two-year build cover the process of learning to build, making tradeoffs, and what it means to ship a live system with real users.
For the publishing infrastructure question on the other side of the syndication equation, the Academic Stack documentation provides a structured view of how journals handle submission workflows, peer review, DOI assignment, and indexing the systems that turn academic ideas into citable, distributable objects.
The broader context on how syndicated content is valued in 2026 appears in MGID's analysis of how native advertising and distributed revenue models are reshaping publisher economics.