atproto answers X's Nitter crackdown by sharing the database
X, formerly known as Twitter, has sent cease-and-desist letters to Nitter, a tool that let people read public tweets without logging in, demanding the project take its source code down. The essay treats that as the final step in a familiar sequence: Nitter first ran on X's own APIs, then switched to reading public web pages once that access closed, and now, with nothing left to close, X wants the code itself gone. The author, who says they work on atproto, sets this within a longer history: Twitter's API was famously open in 2007, and thousands of developers built free clients, tools and analytics on top of it, until the company progressively closed it down through rate limits, paid tiers, login requirements, technical blocks on workarounds, and finally letters from lawyers. Meta ran the identical playbook with Facebook and Instagram about a decade earlier, to the point that the author says it is now hard to remember either company ever had an API worth building on. The piece opens by invoking Tim Berners-Lee's 2007 essay 'The Giant Global Graph', quoting his line about personal relationships needing to transcend documents and sites so that other software could use that information. It credits Brewster Kahle, founder of the Internet Archive, with having made the same call, to lock the web open, for more than a decade.
The author's central claim is that even a permanent, free, generously rate-limited API would not solve this problem, because an API exposes only a fixed menu of questions. If a product needs a query nobody at the platform thought to expose, such as posts from the people a user's followers follow, ranked by how often those posts get quoted, no endpoint for it exists and none ever will, since nobody at that company is building for that product. Pagination compounds the problem: fetching the full follower list of a hypothetical two-million-follower account, at a typical rate of 100 followers per request, would take 20,000 separate round trips, which the author says rules out anything that needs to feel instant. Data also cannot be joined across services, since each platform is effectively a separate filing cabinet with its own gatekeeper, and it cannot be indexed, searched or ranked by an outside developer who never holds the underlying dataset.
The fix the author proposes, one they say atproto already implements, is to share the database directly rather than query it through an API. Applications run against personal data servers (PDS): each app keeps a locally replicated copy of the data it cares about instead of polling for it, so reads happen against a local index rather than a live remote call. Writes go the other way: an app sends a record to a user's PDS, which then replicates that write back out to every other app subscribed to it. The author calls this the 'write/ingest loop' and illustrates it with a short code example, a write call followed by a listener that ingests the resulting event, and notes that an app can also write optimistically to its own local copy before the network round trip confirms it, for a faster feel.
To show the model already works at scale, the author cites atproto's numbers as of the time of writing: 46.1 million accounts, 24.5 billion records in total, including 3.15 billion posts and 17.4 billion likes, 500 to 1,000 write events happening across the network every second, and more than 5,000 personal data servers in operation. Real applications already run on this architecture, among them Bluesky, Tangled and Leaflet. The author also points to a new Jetstream service, shown with a short code sample that subscribes to live follow, repost and reply events, as an easy way for a developer to start consuming that network's live firehose directly. The piece closes by directing anyone specifically interested in blogging on atproto to a dedicated site, standard.site, and restating its central pitch: instead of building a client that a platform can cut off and threaten with legal letters, developers should query and write to the shared, open dataset.
Key facts
- X sent cease-and-desist letters demanding Nitter, a tool that let people read public tweets without logging in, take its source code down, after first cutting Nitter's API access and then blocking the page scraping it fell back on.
- The author traces this to a repeating pattern: Twitter's 2007 API was open enough that thousands of developers built free tools on it, then it closed gradually through rate limits, paid tiers, login requirements, technical blocks and finally legal letters, and Meta ran the same sequence with Facebook and Instagram about a decade earlier.
- Even a permanent, free API would not be enough, the author argues, illustrating the cost of pagination with a hypothetical two-million-follower account that would take 20,000 API round trips to page through at 100 followers per request.
- The proposed fix is atproto's architecture: apps run against a network of personal data servers, or PDS, each app keeping a local replica of the shared dataset and writing back to the PDS in a 'write/ingest loop', instead of querying a platform's fixed API endpoints.
- The author cites atproto's current scale as evidence it works: 46.1 million accounts, 24.5 billion records including 3.15 billion posts and 17.4 billion likes, 500 to 1,000 write events per second, and more than 5,000 personal data servers, powering apps such as Bluesky, Tangled and Leaflet.
Why it matters
The cease-and-desist against Nitter is not an isolated dispute: the author uses it to argue that platform APIs follow a predictable arc, opened to attract free developer labor, then closed once that labor is no longer needed, with Twitter and Meta both cited as having run the same sequence. The piece adds a sharper legal point too: the author writes that X is treating a program that displays public posts as a circumvention device under computer-crime statutes, casting the cease-and-desist as the last stage of that arc, past pricing and rate limits and into criminal law. The essay's stakes go beyond one app: it argues that no amount of API generosity, even free and permanent, can fix the underlying design, because a fixed set of endpoints can never anticipate every product built on top of it. atproto's personal-data-server model is offered as a structural alternative already running at meaningful scale, not just a complaint about X.
Who it affects
This directly affects Nitter's maintainers and users, who lose a login-free way to read X, and any developer whose tool depends on undocumented or good-faith access to a platform's data. More broadly, the essay addresses the open social web community building on atproto, including apps it names as already running on the model, Bluesky, Tangled and Leaflet, plus the wider ActivityPub ecosystem it describes as resilient. It also implicitly concerns X and Meta, whose API histories are cited as the pattern being critiqued, and anyone relying on a platform API for a product, since the essay's argument is that the risk is structural rather than specific to Nitter.
How to use it
The essay names no product or price: atproto's network is described as free and open to read right now, from a laptop, without asking anyone's permission. It points developers to a concrete entry point, the Jetstream service, shown with a short code sample that subscribes to live follow, repost and reply events straight off the network. For anyone specifically interested in blogging on atproto, the author points to standard.site as a place to start. The underlying pattern for building on the network, write to a personal data server and let subscribed apps ingest the resulting event, is shown directly in the piece as a short code sketch, with an optional optimistic local write for apps that want to feel instant rather than wait on the network round trip.
How solid is it
This is an opinion essay, not a news report: the unnamed author states only that they work on atproto, so the case for personal data servers comes from someone advocating for the architecture, not a neutral outsider. The Twitter and Meta API history is presented as recalled background rather than sourced to specific decisions or dates, and the adoption numbers, 46.1 million accounts, 24.5 billion records and the rest, are self-reported as of an unspecified time of writing, with no link to a dashboard or third-party source. The piece also does not reconcile its own total: 3.15 billion posts and 17.4 billion likes leave about 3.95 billion of the 24.5 billion claimed records unaccounted for by type.
Risks and caveats
The essay gives no date, case name, court or jurisdiction for X's cease-and-desist letters to Nitter, and does not say how the dispute was resolved or what Nitter's current legal status is. The two-million-follower, 20,000-round-trip example used to illustrate API pagination costs is explicitly a hypothetical illustration, not a measured real account. And while the piece describes personal data servers and a write/ingest loop in enough detail to code against, it gives no timeline or specific mechanism for how account or identity migration between apps would actually work, beyond that general description.
“There are cries from the heart .. for my friendship, that relationship to another person, to transcend documents and sites. ..Then any other site or program can use that information.”
— Tim Berners-Lee, in his 2007 essay 'The Giant Global Graph'