Pourquoi auto-héberger un relais
La première publication Nostr que fait la plupart des gens est signée par leur clé et envoyée à travers un relais que quelqu’un d’autre opère. C’est correct. Le réseau est conçu pour ça — vous pouvez changer de relais librement, et des relais publics comme relay.damus.io, nos.lol et relay.primal.net transportent joyeusement la majorité du trafic Nostr mondial.
Mais il y a une raison pour laquelle les Bitcoiners finissent par aboutir ici. Un relais que vous opérez est un relais sur lequel personne ne peut appuyer pour vous faire taire. C’est l’équivalent, côté identité, de faire tourner votre propre nœud Bitcoin : vous arrêtez de faire confiance et vous commencez à vérifier. Concrètement :
- Résilience. Si tous les grands relais publics retiraient votre
npubdemain, votre relais auto-hébergé aurait toujours chaque événement que vous avez signé. Vous donnez l’URL à quiconque veut vous suivre et vous continuez à publier. - Résistance à la censure. C’est vous qui fixez la politique de modération. « Ma maison, mes règles » est l’état par défaut d’Internet quand vous hébergez votre propre serveur.
- Curation de fil. Un relais personnel vous permet de pré-filtrer le flot — fils uniquement accessibles aux
npubde confiance, listes blanches de sujets, ou copies d’archives des auteurs qui vous tiennent à cœur pour que leurs notes survivent même si les relais d’origine les oublient. - Esthétique du Bitcoiner. Le point entier de l’auto-custodie, c’est que c’est vous l’autorité finale. Vos notes méritent le même traitement que vos sats.
Options logicielles pour relais
Trois implémentations dominent en production. Choisissez en fonction de votre matériel et de votre zone de confort.
strfry — par Doug Hoyte (github.com/hoytech/strfry). C++, adossé à LMDB, très rapide, très compact sur disque. strfry, c’est ce que vous faites tourner quand vous voulez que le relais soit la partie ennuyeuse et rapide de votre pile. C’est le choix le plus courant sur les relais publics payants et dans l’app store d’Umbrel. Ce guide utilise strfry pour la marche à suivre principale.
nostr-rs-relay — par Greg Heartsfield (github.com/scsibug/nostr-rs-relay). Rust, adossé à SQLite, délicieusement simple à déployer. Si votre boîte cible est un Raspberry Pi ou un petit VPS et que vous voulez un binaire unique à déposer et oublier, c’est le chemin le plus propre. Bien maintenu, bien documenté, un favori de la communauté d’auto-hébergement.
nostream — TypeScript, adossé à Postgres, crochets de modération et de paywall plus riches. Empreinte plus lourde. À considérer si vous prévoyez de faire tourner un relais payant avec de l’outillage d’administration dès le jour un.
Les trois implémentent les NIPs de base. Les trois sont open source sous GPL ou MIT. Aucun ne s’en va nulle part.
Où le faire tourner
Vous avez trois options honnêtes, par ordre croissant de souveraineté et d’effort.
App store Umbrel ou Start9 (mode facile). Si vous faites déjà tourner un Umbrel Home ou un serveur Start9 à côté de votre nœud Bitcoin, un relais Nostr est à un clic dans l’une ou l’autre des app stores. strfry est la valeur par défaut sur Umbrel ; les deux plateformes gèrent pour vous le routage Tor/Clearnet, le TLS et les sauvegardes. Si c’est votre premier truc auto-hébergé, commencez ici et revenez à la version bare-metal quand les détails vous intéresseront.
VPS nu (juste milieu recommandé). Un VPS à 5–10 $ chez Hetzner, OVH ou Netcup vous donne une IPv4 statique, un uptime prévisible, et aucun casse-tête de NAT/FAI. C’est ce que couvre le reste de ce guide. Debian 12 ou Ubuntu 24.04 est la ligne de base la plus simple.
Raspberry Pi 5 à la maison. Fonctionne. Nécessite d’ouvrir un port ou de faire tourner derrière Cloudflare Tunnel / Tailscale Funnel. Les FAI résidentiels étranglent ou bloquent parfois le trafic WebSocket entrant — testez avant de vous engager.
Les trois se marient bien avec la stack de minage souverain au sens large — la même boîte qui fait tourner votre nœud et votre moniteur de miners peut absolument faire tourner un relais.
Marche à suivre sur VPS nu : strfry sur Debian 12
1. Préparer le serveur
Allumez un VPS Debian 12 frais. SSH en root (ou utilisateur sudo).
apt update && apt upgrade -y
apt install -y git build-essential cmake libssl-dev zlib1g-dev \
liblmdb-dev libflatbuffers-dev libsecp256k1-dev libzstd-dev \
caddy ufw
ufw allow 22/tcp
ufw allow 80/tcp
ufw allow 443/tcp
ufw --force enableVoilà toute la liste des dépendances. strfry est un petit projet ; les temps de compilation se mesurent en minutes, pas en heures.
2. Compiler strfry
useradd --system --create-home --shell /bin/bash strfry
sudo -u strfry -i
git clone https://github.com/hoytech/strfry.git
cd strfry
git submodule update --init
make setup-golpe
make -j$(nproc)Vous avez maintenant un binaire strfry à la racine du dépôt. Copiez strfry.conf du dépôt comme configuration de départ et éditez db, bind, nofiles et le bloc info (nom du relais, description, contact de l’opérateur, npub de l’opérateur).
3. Unité systemd
En root, déposez ceci dans /etc/systemd/system/strfry.service :
[Unit]
Description=strfry relay
After=network.target
[Service]
User=strfry
WorkingDirectory=/home/strfry/strfry
ExecStart=/home/strfry/strfry/strfry relay
Restart=on-failure
LimitNOFILE=65536
[Install]
WantedBy=multi-user.targetActiver et démarrer :
systemctl daemon-reload
systemctl enable --now strfry
systemctl status strfrystrfry écoute maintenant sur 127.0.0.1:7777 (ou ce que vous avez mis dans bind).
4. Reverse proxy Caddy pour WSS + TLS
strfry parle le WebSocket brut. Le monde extérieur veut du wss:// avec un vrai certificat. Caddy s’occupe des deux avec une configuration de trois lignes. Éditez /etc/caddy/Caddyfile :
relay.example.com {
reverse_proxy 127.0.0.1:7777
encode zstd gzip
}Rechargez Caddy (systemctl reload caddy). Caddy ira chercher automatiquement un certificat Let’s Encrypt à la première requête. Terminé. wss://relay.example.com est en ligne.
Si vous préférez nginx, le fragment de reverse-proxy fait cinq lignes avec proxy_http_version 1.1, les en-têtes Upgrade et Connection — n’importe quel tutoriel de relais Nostr a le bloc exact.
5. Vérifier
curl -sI https://relay.example.com/ -H 'Accept: application/nostr+json'
wscat -c wss://relay.example.comLa première devrait renvoyer un document NIP-11 application/nostr+json. La seconde vous donne un WebSocket ouvert dans lequel vous pouvez coller une trame REQ. Si les deux passent, le relais est opérationnel.
NIP-11 — dites au monde qui vous êtes
Le NIP-11 est la carte d’identité du relais. Quand un client frappe à votre relais avec Accept: application/nostr+json, il reçoit un document JSON qui décrit l’opérateur, les NIPs supportés, la version du logiciel, et les politiques. La configuration de strfry contient déjà ce bloc. Remplissez :
name— ce que les clients afficherontdescription— une phrase, en français clairpubkey— lenpubhex de l’opérateurcontact— courriel ou URL Nostrsupported_nips— laissez la liste par défaut de strfrysoftwareetversion
Les clients se servent de ça pour router, pour étiqueter les relais payants, et pour décider s’ils tentent un NIP donné sur un relais donné. C’est le fichier le plus lu sur votre serveur. Ne le sautez pas.
Modération : listes blanches, listes noires, spam, NIP-42
Un relais public sans modération devient un puits à spam en une semaine. strfry livre un système de plugin de politique d’écriture exactement pour ça. Les deux patrons qui couvrent 95 pour cent des cas :
Relais personnel (liste blanche). N’acceptez que les événements dont l’auteur pubkey figure dans une liste codée en dur — typiquement juste vous et une poignée d’amis. La meilleure résistance à la censure pour vos propres écrits. Inutile comme relais généraliste, ce qui est très bien.
Relais communautaire (liste noire + WoT). Accepter de tout le monde sauf les spammers connus, et optionnellement exiger un chemin dans la toile de confiance depuis un ensemble de graines de confiance. L’écosystème de plugins de strfry offre des scripts prêts à l’emploi pour les deux.
Authentification NIP-42. Exige des clients qu’ils prouvent la possession d’une clé privée avant de lire ou d’écrire. Utile pour les relais payants, pour les relais communautaires privés, et pour empêcher le scraping. strfry le supporte nativement — activez le drapeau dans la config.
Commencez restrictif. Assouplissez plus tard. Il est beaucoup plus facile d’ouvrir un relais que de récurer une épidémie de spam dans LMDB.
Sauvegardes
Un relais strfry a deux choses qui méritent d’être sauvegardées :
- Le magasin d’événements LMDB au chemin configuré dans
db. Snapshot nocturne —strfry exportvide tous les événements en JSONL, qui se restaurent sur n’importe quelle instance strfry, n’importe où. - Le fichier de configuration (
strfry.conf) et tous les plugins de modération.
C’est tout. Pas de serveur de base de données, pas de table d’utilisateurs, pas d’autres secrets que des clés d’API optionnelles pour relais payants. Un tar du dossier de données est une sauvegarde complète et portable. Gardez une copie hors site. Restic vers Backblaze B2 ou un second VPS est la réponse standard du pleb.
Pointer votre npub vers lui
Ouvrez les réglages de relais de votre client Nostr. Ajoutez wss://relay.example.com. Mettez-le en lecture + écriture. Publiez une note. Observez le log du relais :
journalctl -u strfry -fVous devriez voir l’événement arriver, être validé, et être stocké. À cet instant précis, vous écrivez vers un relais dont l’uptime, la politique et le sort sont entièrement les vôtres. Chaque client Nostr subséquent que vous utilisez peut pointer vers la même URL. Vos notes vivent là tant que vous vivez.
Si vous voulez la ceinture et les bretelles, publiez vers votre relais auto-hébergé en plus de trois ou quatre grands relais publics. De cette façon, vos notes se propagent, mais même si tous les relais publics disparaissent, votre archive, elle, ne disparaît pas.
Économie du relais payant (optionnel, futur)
Les relais publics gratuits sont un bien commun, et les biens communs ont un problème d’économie. Les relais payants — avec un petit tarif forfaitaire ou un prix en sats par événement — règlent le spam en alignant les incitations, et ils permettent à un opérateur de relais de couvrir les coûts d’hébergement plus une marge.
L’implémentation est simple. Le NIP-11 annonce le tarif, les clients invitent l’utilisateur à payer, le paiement est une facture Lightning (souvent via LNURL-pay), et le relais de l’opérateur enregistre quels pubkey sont à jour. strfry et nostream supportent ce patron aujourd’hui.
Vous n’avez pas besoin d’activer ça dès le jour un. Mais si vous finissez par faire tourner un relais pour une communauté, l’adhésion payante est la façon honnête de garder les lumières allumées sans mendier des dons. C’est de la plomberie valeur-pour-valeur, la même philosophie derrière les Zaps.
Où ça s’inscrit dans le Sovereign Stack
Un relais Nostr auto-hébergé est le troisième pied du Sovereign Stack du pleb, à côté d’un nœud Bitcoin et d’un canal Lightning. Identité, monnaie, règlement — les trois tournant sur des boîtes que vous contrôlez. Si vous n’avez pas encore lu le guide d’initiation à Nostr, commencez là. Si c’est fait, continuez — le Manifeste du Sovereign Stack du pleb expose pourquoi ça compte, et le hub Souveraineté rassemble chaque pilier à mesure que nous le publions.
Un relais est un petit programme qui fait un petit travail. C’est précisément pour ça qu’en faire tourner un est une si grosse affaire.
