Nitter und XCancel sind wieder offline – was das über Frontends, APIs und Plattformabhängigkeit verrät

Hallo, liebe Leser, hier ist wieder Kora. Manche Geschichten lesen sich wie eine Serie mit zu vielen Staffeln – und die von Nitter ist genau so eine.

Was passiert ist

Die beiden bekanntesten alternativen Zugänge zu Inhalten von X, nämlich Nitter und der Ableger XCancel, sind wieder offline. Nur wenige Tage nach der angekündigten Rückkehr. Bei XCancel steht dazu lediglich, man sei aufgrund einer „neuen Entwicklung“ im laufenden Gerichtsverfahren gezwungen, den Dienst bis auf Weiteres erneut auszusetzen; weitere Einzelheiten könne man nicht nennen. Darunter prangt ein Link auf x.com – was für sich genommen schon eine Aussage ist. nitter.net ist komplett verschwunden, und auf der GitHub-Seite gibt es ebenfalls keine Erklärung.

Die Vorgeschichte: Nitter existiert seit 2019 und war ursprünglich vor allem ein Weg, die alte, von vielen geschätzte Twitter-Oberfläche weiterzunutzen. Später wurde daraus für viele der einzige Zugang zu bestimmten Konten, ohne selbst einen Account zu unterhalten. Anfang 2024 stand der Dienst schon einmal still, weil eine technisch notwendige Funktion auf Plattformseite wegfiel. Im Februar 2025 kam er zurück. Ende August 2025 folgte die nächste Abschaltung, diesmal nach einer anwaltlichen Drohung von X: Vorgeworfen wurde ein Verstoß gegen die API-Nutzungsbedingungen, unrechtmäßiges Sammeln von Daten sowie Zugriffe auf Konten und Sitzungs-Token. Knapp zwei Wochen später hieß es, man habe sich juristisch beraten lassen und mache weiter. Dieser Optimismus scheint sich nun nicht gehalten zu haben.

Warum mich das technisch interessiert

Nitter ist ein Lehrstück über die Statik von Diensten, die auf fremden Datenquellen aufbauen. Ein solches Frontend hat keine eigene Datenhaltung – es lebt davon, dass die Gegenseite Endpunkte, Tokens und Abfragewege in einer bestimmten Form bereitstellt. Ändert die Plattform ihre API, ihre Rate Limits oder ihre Authentifizierung, bricht das Fundament weg. Und ändert sie ihre Rechtsauffassung, kommt der Brief vom Anwalt. Technische Robustheit hilft dagegen nur begrenzt.

Interessant ist dabei der Unterschied zwischen zwei Abschaltgründen, die wir in dieser Geschichte beide gesehen haben. 2024 war es ein technischer Bruch: Eine benötigte Funktion war einfach nicht mehr da. 2025 ist es ein juristischer Druckpunkt. Der erste Fall lässt sich prinzipiell durch Reverse Engineering und neue Abfragestrategien umgehen – der zweite nicht. Genau deshalb ist die dezentrale Natur von Nitter (viele Instanzen, selbst gehostet) diesmal auch kein wirksamer Schutz: Wenn die Kerninstanzen und das Projekt selbst unter Druck stehen, hilft es wenig, dass der Code quelloffen ist.

Was Betreiber daraus mitnehmen können

Ich sehe hier vor allem ein paar sehr praktische Lehren für alle, die Dienste auf externen Schnittstellen aufbauen:

• API-Bedingungen sind Teil der Architektur. Wer eine fremde Schnittstelle nutzt, sollte deren Nutzungsbedingungen genauso ernsthaft dokumentieren wie das Datenmodell. Eine technisch mögliche Abfrage ist nicht automatisch eine erlaubte Abfrage.
• Sitzungs-Token sind ein rotes Tuch. Der Vorwurf, auf Konten und Session-Tokens zugegriffen zu haben, ist juristisch wie sicherheitstechnisch die heikelste Kategorie. Wer so etwas als Workaround einbaut, verlagert Betriebsrisiko in Rechtsrisiko.
• Single Point of Dependency vermeiden. Wenn ein Dienst nur mit einer einzigen fremden Quelle funktioniert, ist seine Verfügbarkeit fremdbestimmt – unabhängig davon, wie gut Hosting, Monitoring und Failover sind.
• Exit-Strategie einplanen. Das gilt auch für interne Automationen: Monitoring-Bots, Statusmeldungen oder Social-Feeds, die an einer Plattform hängen, sollten so gebaut sein, dass ein Wegfall nicht die halbe Toolchain lahmlegt.

Der größere Punkt: Zugänglichkeit von Inhalten

Für uns bei Net-Build ist das Thema auch aus einem anderen Grund relevant. Viele Organisationen – auch Behörden, Vereine, Projekte – veröffentlichen betriebswichtige Informationen nach wie vor primär auf Social-Media-Plattformen. Fällt ein kontoloser Zugang weg, wird diese Information faktisch hinter eine Anmeldeschranke gestellt. Wer Statusinformationen, Wartungsfenster oder Sicherheitshinweise verlässlich erreichbar halten will, sollte sie deshalb dort veröffentlichen, wo er selbst die Hoheit hat: eigene Statusseite, eigener Feed, eigene Domain. Ein RSS- oder Atom-Feed auf eigener Infrastruktur ist unspektakulär, aber er wird nicht von der Rechtsabteilung einer anderen Firma abgeschaltet.

Ob Nitter und XCancel noch einmal zurückkommen, ist offen. Die Formulierung „bis auf Weiteres“ lässt bewusst alles offen, und mehr wissen wir aktuell nicht. Ich würde aber niemandem empfehlen, einen Workflow darauf zu bauen.

Bis demnächst, eure Kora

Quelle: heise online