A 615-point Hacker News thread, with 499 comments when MrKeyoor's brief captured it, turned a broken Nitter instance into an unusually loud warning for open-source maintainers: keeping code public does not keep the service it powers alive. X Corp. sent cease-and-desist letters on August 24 demanding the permanent takedown of Nitter instances and the project's repository, according to Nitter's maintainer. The repository was archived the next day, but its AGPL-licensed source remains visible and forkable.
That split matters more than the shutdown notice alone. Nitter was a privacy-focused front end for reading public posts on X without loading X's JavaScript, ads or tracking code. Anyone can still inspect the roughly seven-year-old project, clone it or fork its current state. Making a fork useful is another matter because every working instance must still obtain data from a platform whose owner controls the interfaces, rate limits and legal pressure around them.
The Hacker News discussion is evidence of developer attention, not proof of what the letters allege or whether their demands would prevail in court. Neither the letters nor a detailed legal response has been published. What is confirmed is narrower: the maintainer says letters arrived, public instances went down, development stopped for now and legal advice is being sought.
An outage became a legal shutdown
The sequence began as a technical failure. A user opened GitHub issue 1442 after public instances returned the same Instance has been rate limited. error. About 30 minutes later, project owner Zedeus said the team had received cease-and-desist letters and that all Nitter instances should be expected to remain down for the foreseeable future. The issue was subsequently locked.
Nitter's own shutdown notice gives the date and scope. It says X demanded permanent removal of the instances and the code repository, while nitter.net is offline and development has stopped as the maintainer seeks legal advice. The GitHub repository is now read-only, and its README carries the same legal note. Its final recorded change on August 25 was simply titled "Add legal note."
Those facts leave important gaps. The public record does not show the letters' text, the legal jurisdiction asserted in each one, the recipients beyond the maintainers and instance operators who have acknowledged receiving them, or the precise claims X made. Calling this a copyright case, a contract case or a definitive ruling on scraping would go beyond the evidence. A cease-and-desist letter is a demand from a party, not a court judgment.
The distinction also explains why the repository has not vanished. Archiving a GitHub project makes it read-only under the owner's account; it does not erase its commit history or existing forks. At the time of reporting, the Nitter repository had about 13,500 stars and remained available under the GNU Affero General Public License v3. X asked for the repository to be taken down, according to Nitter, but that part of the demand had not been carried out.
Source code was only half of Nitter
Nitter's README describes a compact proxy rather than a standalone social network. The server fetched posts through X's unofficial interfaces, then rendered its own pages. A visitor's browser talked to the Nitter server, not directly to X. That design removed client-side JavaScript and ads, concealed the visitor's IP address from X, supported RSS feeds and offered responsive pages.
The project was written in Nim and used Redis or Valkey for caching. It could be compiled from source or run from a container. The installation documentation remains detailed enough for an operator to build the binary, mount a configuration file and place the service behind Nginx or Apache. That surviving documentation may make the archive look operational. It is better read as a record of the software's local requirements.
A running binary still needs upstream data. Nitter's README explicitly says it used X's unofficial API and required no developer account. Recent commits show that sessions and changes to X's endpoints were active maintenance concerns right up to the shutdown. One August 22 commit changed how cookie sessions fetched user posts and replies; another skipped a continuous-integration test because of a Cloudflare block. The code was being adjusted around an upstream system that could change without notice.
That is why a fork does not solve the current problem by itself. A developer can preserve and modify the AGPL code, but cannot fork X's servers, authentication checks or rate-limit policy. A small private deployment may behave differently from a public instance, yet scattered comments claiming that self-hosted copies still work are community reports, not a tested path or a guarantee of continued access. Publishing a hostname can also turn a private experiment into a visible operator with its own exposure.
X's terms put the access method in the crosshairs
X has not published a statement tied specifically to Nitter's shutdown. Its current Terms of Service, effective April 10, 2026 for users outside the European Union, EFTA and the United Kingdom, state that crawling or scraping the service without prior written consent is prohibited. They also bar access through interfaces other than those X publishes and attempts to work around technical limits. The separate version for the EU, EFTA and UK contains comparable restrictions.
The terms go further than account suspension. They say a person who violates the agreement, or knowingly facilitates violations, may face liquidated damages after requesting, viewing or accessing more than one million posts in a 24-hour period. The stated rate is $15,000 per million posts in the non-European terms and EUR15,000 per million in the European version. Whether those clauses apply to a particular Nitter operator, and whether a court would enforce them, depends on facts and law that the unpublished letters do not reveal.
Still, the written policy clarifies the pressure point. Nitter's privacy benefits came from putting a server between the reader and X. The same server concentrated automated requests and redistributed the results through a different interface. X could attack that arrangement technically by changing endpoints or blocking sessions, and it could contact identifiable maintainers and public-instance operators. The August 25 outage showed both forms of control at once: rate-limit errors appeared across instances, then the maintainer disclosed the legal demands.
For projects built on undocumented endpoints, open source protects the implementation from disappearing with one vendor account. It does not grant durable access to the upstream service. The repository can outlive its official deployment while losing the external dependency that makes it useful. Nitter's archive is a particularly clear example because its core promise, browsing X through a lighter and more private interface, cannot be fulfilled from cached source code alone.
What breaks beyond a web front end
Nitter was useful as infrastructure as well as a website. Its RSS feeds let readers and feed tools follow accounts without opening X. People used alternate-instance links when an X page required login or loaded poorly. Other sites could point readers to a clean rendering of a post without asking them to accept X's client code. The official shutdown notice thanks users, hosts, package maintainers and contributors, which indicates how many roles had grown around the project.
Anyone who depended on those outputs should now treat public Nitter URLs as unavailable rather than rotate blindly through mirrors. A replacement based on the same access technique inherits the same upstream and legal constraints. For an application that must consume X data, the published X interfaces are the route X authorizes, though their costs and capabilities may not match what Nitter supplied. For archival or RSS workflows, developers need to identify which jobs require live X data and which can continue from material they already hold under applicable rules.
Package maintainers face a separate choice. The source archive is still present, so distributions do not have to pretend the software never existed. They should, however, distinguish a buildable package from a service that can currently retrieve data. Leaving an old package marked as healthy would hide the dependency failure from users. Removing it immediately could also discard useful source history while the maintainer is still getting advice.
The next concrete signals will come from the maintainer's legal review, any public response from X, and the repository state. Watch whether the archive is removed, reopened or transferred; whether major forks begin shipping changes; and whether any public instance returns with a documented access method. Until one of those facts changes, Nitter's code survives, but its official development and public service remain stopped.