Herkos

Ihr eigenes Postfach-Relay

Zuletzt aktualisiert: 3. Oktober 2026

Herkos-Post reist in versiegelten Umschlägen (NIP-59 Gift Wraps) und wartet auf den Relays in Ihrer DM-Relay-Liste, bis Ihre App sie abholt. Die meisten öffentlichen Relays geben diese Umschläge jedem, der danach fragt. Öffnen kann sie niemand, aber jeder kann zählen, wer Post bekommt und wann, und das Relay kann sie löschen, wann immer es will.

Ein eigenes Relay, das fragt, wer liest (NIP-42), gibt Ihre Umschläge Ihnen und niemandem sonst und bewahrt sie so lange auf, wie Sie es bestimmen. Diese Seite erklärt, wie Sie eines in drei Schritten einrichten, dazu eine nächtliche Sicherung. Das dauert etwa fünfzehn Minuten, wenn Sie bereits einen Server haben.

Welches Relay Sie verwenden sollten

Wir haben am 24. September 2026 beide Kandidaten betrieben und geprüft, was sie mit Post tatsächlich tun, nicht, was sie versprechen.

nogringo/nostr-relay HAVEN 1.2.2
Wer Ihre Umschläge lesen kann Nur Sie, nach Identifizierung /chat: jeder in Ihrem Web of Trust, nach Identifizierung. /inbox: jeder, ohne Identifizierung
Wer Ihnen Post zustellen kann Jeder Absender, der sich identifiziert Nur Ihr Web of Trust
Empfangene Post löschen Ja Nein
Schnelle Neusynchronisierung (NIP-77) Ja Nein
Lizenz MIT MIT

Verwenden Sie nogringo/nostr-relay als Postfach. Es ist dasjenige, das tut, was Post braucht: Jeder kann Ihnen schreiben, und nur Sie können lesen. HAVEN ist ein gutes Werkzeug für anderes (ein persönlicher Postausgang, Medien, private Notizen), aber als Postfach würde es Post von jedem abweisen, dem Sie nicht folgen, einschließlich der Bridge, die gewöhnliche E-Mail überbringt.

Was Sie brauchen

Schritt 1: das Relay starten

git clone https://github.com/nogringo/nostr-relay
cd nostr-relay
cp .env.example .env

Bearbeiten Sie .env: Geben Sie dem Relay einen Namen (RELAY_NAME) und setzen Sie RELAY_URLS auf seine öffentliche Adresse, wss://relay.example.com.

Öffnen Sie dann docker-compose.yml und ändern Sie die Port-Zeile in "127.0.0.1:3334:3334". Das Relay vertraut der Adresse, die der Proxy an es weiterreicht, wenn es prüft, wer sich identifiziert; es darf also nur über den Proxy erreichbar sein. Starten Sie es:

docker compose up -d

Schritt 2: HTTPS davorschalten

Mit Caddy lautet die gesamte Konfiguration (/etc/caddy/Caddyfile):

relay.example.com {
    reverse_proxy 127.0.0.1:3334
}

Laden Sie Caddy neu (sudo systemctl reload caddy). Wenn Sie nun https://relay.example.com im Browser öffnen, sollte eine Antwort kommen.

Schritt 3: Herkos Bescheid geben

  1. Öffnen Sie in Herkos Einstellungen → Netzwerk & Server → Dein eigenes Relay und tippen Sie auf Relay prüfen. Geben Sie wss://relay.example.com ein.
  2. Herkos verbindet sich und testet es: Es fragt nach der Post einer anderen Person und hinterlegt einen Testumschlag von einem Fremden (den es danach löscht). Sie sollten Nur du kannst deine Post hier lesen und Nimmt Post von jedem Absender an sehen.
  3. Tippen Sie auf Als erstes DM-Relay festlegen und oben auf Speichern.

Behalten Sie außerdem ein öffentliches Relay in der Liste, an zweiter Stelle: Wenn Ihr Server ausfällt, hat die Post trotzdem einen Ort, an dem sie warten kann. relay.damus.io ist eine gute zweite Wahl, weil es ebenfalls fragt, wer liest.

Schritt 4: jede Nacht sichern

Herkos behält eine eigene Kopie der Post, die es abgeholt hat, aber ein Umschlag, der eingetroffen ist, während Ihre App geschlossen war, existiert nur auf Ihrem Server, bis Sie Herkos öffnen. Eine nächtliche Kopie schließt diese Lücke und erlaubt Ihnen, den Server neu aufzubauen, wenn die Festplatte ausfällt oder der Anbieter Ihr Konto schließt.

Das Relay hält alles in einer einzigen LMDB-Datenbank im Docker-Volume nostr-relay_relay-db (der Name beginnt mit dem Ordner, in den Sie geklont haben; prüfen Sie ihn mit docker volume ls). Eine LMDB-Datei, die kopiert wird, während das Relay hineinschreibt, lässt sich womöglich nicht öffnen; deshalb hält das Skript das Relay für die wenigen Sekunden an, die eine lokale Kopie dauert, startet es wieder und lädt erst danach die Kopie hoch. Solange es angehalten ist, wartet die Post auf dem öffentlichen Relay, das Sie an zweiter Stelle in Ihrer Liste behalten haben.

Die Kopie verlässt den Server mit restic, das sie verschlüsselt, bevor sie hinausgeht. Nutzen Sie einen Ort bei einem anderen Anbieter als dem des Servers: ein SFTP-Konto (eine Storage Box, ein Computer zu Hause) oder einen S3-kompatiblen Bucket.

  1. Installieren Sie die Werkzeuge und legen Sie das Repository an. Bewahren Sie das Passwort zusätzlich in Ihrem Passwortmanager auf: Ohne es lassen sich die Kopien nicht lesen, und wenn es nur auf dem Server liegt, stirbt es mit dem Server. Für SFTP braucht root außerdem einen SSH-Schlüssel, den der Sicherungsrechner akzeptiert (sudo ssh-keygen -t ed25519, dann /root/.ssh/id_ed25519.pub dort hinzufügen).

    sudo apt install restic rsync
    sudo sh -c 'openssl rand -base64 32 > /root/.restic-password'
    sudo sh -c 'cat > /root/.restic-env' <<'END'
    export RESTIC_REPOSITORY=sftp:backup@backup.example.com:/relay
    export RESTIC_PASSWORD_FILE=/root/.restic-password
    END
    sudo chmod 600 /root/.restic-password /root/.restic-env
    sudo sh -c '. /root/.restic-env && restic init'
    
  2. Speichern Sie dies als /usr/local/bin/backup-relay und machen Sie es ausführbar (sudo chmod 700 /usr/local/bin/backup-relay). Ändern Sie RELAY_DIR, wenn Sie nicht nach /root/nostr-relay geklont haben. Es behält die letzten 14 Tage, 8 Wochen und 12 Monate: ein Jahr zurück, bei einer Größe nahe der der Datenbank.

    #!/bin/sh
    set -eu
    . /root/.restic-env
    RELAY_DIR=/root/nostr-relay
    COPY=/var/backups/relay-db
    VOLUME=$(docker volume inspect --format '{{ .Mountpoint }}' nostr-relay_relay-db)
    mkdir -p "$COPY"
    cd "$RELAY_DIR"
    docker compose stop relay
    trap 'docker compose start relay' EXIT
    rsync -a --delete "$VOLUME/" "$COPY/"
    docker compose start relay
    trap - EXIT
    restic backup "$COPY" --tag relay
    restic forget --tag relay --keep-daily 14 --keep-weekly 8 --keep-monthly 12 --prune
    
  3. Führen Sie es einmal von Hand aus (sudo /usr/local/bin/backup-relay) und planen Sie es dann mit sudo crontab -e. Die zweite Zeile liest jeden Monat ein Zehntel der gespeicherten Daten zurück, jedes Mal ein anderes Zehntel, um zu beweisen, dass sich die Kopien noch öffnen lassen. Schauen Sie ab und zu in /var/log/backup-relay.log: Eine Zeile mit Fatal bedeutet, dass die Kopie dieser Nacht fehlgeschlagen ist.

    15 4 * * * /usr/local/bin/backup-relay >> /var/log/backup-relay.log 2>&1
    45 5 1 * * . /root/.restic-env && restic check --read-data-subset=10% >> /var/log/backup-relay.log 2>&1
    

Wiederherstellen (ein neuer Server oder nach einem Festplattenausfall): Richten Sie das Relay erneut ein (Schritte 1 bis 3) und wiederholen Sie die Punkte 1 und 2 dieses Schritts mit demselben Repository, schreiben Sie aber das gespeicherte Passwort in /root/.restic-password, statt ein neues zu erzeugen, und lassen Sie restic init weg. Kopieren Sie dann die neueste Sicherung in das Volume des Relays:

sudo sh -c '. /root/.restic-env && restic restore latest --tag relay --target /'
cd /root/nostr-relay && sudo docker compose stop relay
sudo rsync -a --delete /var/backups/relay-db/ "$(sudo docker volume inspect --format '{{ .Mountpoint }}' nostr-relay_relay-db)/"
sudo docker compose start relay

Führen Sie diese Wiederherstellung einmal im Jahr auf einem Ersatzrechner durch und prüfen Sie, dass das Relay mit Ihrer Post darin startet: Es ist der einzige Test, der die ganze Kette beweist, das Passwort eingeschlossen.

Gut zu wissen