Contexte juridique

Le 24 août 2026, X Corp. a envoyé des lettres de cessation et d'abstention exigeant la suppression définitive des instances Nitter et du dépôt du projet. L'équipe a consulté des avocats et, selon les conseils reçus, a décidé de maintenir le code source et les services en ligne. Cette décision repose sur la licence AGPLv3 du projet, qui impose la diffusion du code mais ne protège pas contre les revendications de propriété intellectuelle liées à l'API non officielle de Twitter.

Architecture et compilation

Nitter est écrit en Nim, un langage compilé qui génère des exécutables natifs. La chaîne de construction nécessite libpcre pour les expressions régulières, libsass pour la conversion SCSS, et Redis (ou son fork Valkey) pour le cache. Le processus de compilation se résume à :

# useradd -m nitter
# su nitter
$ git clone https://github.com/zedeus/nitter
$ cd nitter
$ nimble -l build -d:danger --mm:refc
$ nimble -l scss
$ nimble -l md

Le binaire final pèse environ 60 KB, contre 784 KB pour la page d’accueil de twitter.com, ce qui explique le gain de légèreté mentionné par les développeurs.

Déploiement et performances

Le projet propose plusieurs modes d’exécution : service systemd, conteneur Docker multi‑arch (amd64 et arm64) et docker‑compose avec Redis séparé. Un exemple de service systemd est fourni :

[Unit]
Description=Nitter (An alternative Twitter front-end)
After=syslog.target
After=network.target
[Service]
Type=simple
User=nitter
Group=nitter
WorkingDirectory=/home/nitter/nitter
ExecStart=/home/nitter/nitter/nitter
Restart=always
RestartSec=15
[Install]
WantedBy=multi-user.target

En pratique, les pages générées sont 15 fois plus légères que celles de Twitter et les timelines se chargent 2 à 4 fois plus rapidement, du fait que toutes les requêtes passent par le backend et que le client ne contacte jamais directement les serveurs de X Corp.

Risques et perspectives

Le fonctionnement repose sur l’API non officielle de Twitter ; toute modification de cette API peut interrompre le service sans préavis. Le recours à Valkey, recommandé depuis 2024, évite les restrictions de licence de Redis mais introduit une dépendance supplémentaire. L’ajout prévu d’un système de comptes permettra de suivre des utilisateurs sans compte Twitter, mais augmentera la surface d’attaque et nécessitera une gestion sécurisée des cookies et des clés HMAC. Enfin, la persistance du projet face aux actions légales dépendra de la capacité à démontrer que le code reste conforme à l’AGPLv3 et que les instances respectent les exigences de non‑commercialisation imposées par les contributeurs.