Add translations for newsletters #20, #23-#26 and 8 topic pages

content/de/topics/clink.md

@@ -0,0 +1,50 @@
+---
+title: "CLINK: Common Lightning Interface for Nostr Keys"
+date: 2026-06-17
+draft: false
+translationOf: /en/topics/clink.md
+translationDate: 2026-07-01
+categories:
+  - Payments
+  - Lightning
+---
+
+CLINK (Common Lightning Interface for Nostr Keys) ist ein vorgeschlagenes Zahlungsanforderungsformat, mit dem ein Absender jede Nostr-Schlüssel-Identität über eine einzige noffer-Schnittstelle bezahlen kann. Ein CLINK-noffer kodiert den öffentlichen Nostr-Schlüssel des Empfängers zusammen mit ausreichend Routing-Metadaten, damit die Wallet des Absenders eine Lightning-Zahlung, eine On-Chain-Zahlung oder ein zukünftiges Abrechnungsprimitiv konstruieren kann, das an den Empfänger aufgelöst wird. Der Empfänger veröffentlicht einen noffer pro Identität, und Absender bezahlen ihn, ohne zu wissen, ob die empfangende Wallet über Lightning, On-Chain oder eine andere Schiene abrechnet.
+
+## Wie es funktioniert
+
+Ein CLINK-noffer ist eine strukturierte Zahlungsanforderung, die die Wallet des Absenders in eine konkrete Zahlungsanweisung dekodiert. Der noffer enthält:
+
+- Den öffentlichen Nostr-Schlüssel des Empfängers als kanonische Identitätswurzel
+- Einen oder mehrere Zahlungsendpunkte (Lightning-Node-URI, Hinweis zur Ableitung einer On-Chain-Adresse, zukünftige Schienen)
+- Optionale Metadaten für die Zahlung (Memo, Betrag, Ablaufdatum)
+- Eine Signatur des Empfängers, die den noffer an seine Nostr-Identität bindet
+
+Eine sendende Wallet, die CLINK unterstützt, liest den noffer, wählt die Schiene, die sie bedienen kann (eine reine Lightning-Wallet bezahlt den Lightning-Endpunkt, eine Multi-Schienen-Wallet wählt den günstigsten Pfad), und übermittelt die Zahlung. Die Wallet des Empfängers bestätigt den Empfang, indem sie das entsprechende Abschluss-event veröffentlicht oder abruft, wobei der öffentliche Nostr-Schlüssel als dauerhafte Identität über alle Schienen hinweg fungiert.
+
+## Warum eine Nostr-Schlüssel-Schnittstelle
+
+LNURL und BOLT-12 existieren bereits als Lightning-Zahlungsanforderungsformate, und Bitcoin verfügt über ein bekanntes Adressformat für die On-Chain-Abwicklung. CLINK ersetzt keines von beiden. Es fügt eine an Nostr-Schlüsseln verankerte Schicht hinzu, damit ein Absender einen Empfänger über seine Nostr-Identität adressieren und die Wallet auflösen lassen kann, welche zugrunde liegende Schiene verwendet wird. Ein Nutzer, der den Lightning-Anbieter wechselt, eine neue Mint eröffnet oder seine On-Chain-Wallet migriert, veröffentlicht seinen noffer mit demselben Nostr-Schlüssel erneut, und Absender müssen ihre Adressbücher nicht aktualisieren.
+
+Für Zeus Pay (das für jedes Konto einen CLINK-noffer generiert) bedeutet dies, dass ein Absender jeden Zeus-Nutzer allein über den Nostr-Schlüssel bezahlen kann. Für den On-Chain-zap-Treiber von Amethyst bestätigt die CLINK-Verifikationszustandsmaschine, dass der signierte noffer on chain mit dem in der zap-Anfrage angegebenen Nostr pubkey übereinstimmt, und schließt so einen Fälschungspfad gegen unsignierte On-Chain-zaps.
+
+## Implementierungen
+
+- [Zeus v13.1.0-rc1](https://github.com/ZeusLN/zeus/releases/tag/v13.1.0-rc1) liefert Unterstützung für CLINK-noffer-Zahlungen, wobei Zeus Pay für jedes Konto einen CLINK-noffer generiert, sodass ein Absender jeden Zeus-Nutzer allein über den Nostr-Schlüssel bezahlen kann
+- [Amethyst v1.12.0](https://github.com/vitorpamplona/amethyst/releases/tag/v1.12.0) liefert einen CLINK-Treiber für die On-Chain-zap-Verifikation mit einer Verifikationszustandsmaschine und einem Reverify-Treiber ([PR #3039](https://github.com/vitorpamplona/amethyst/pull/3039), [PR #3177](https://github.com/vitorpamplona/amethyst/pull/3177), [PR #3182](https://github.com/vitorpamplona/amethyst/pull/3182))
+
+---
+
+**Primärquellen:**
+- [Zeus v13.1.0-rc1 Release Notes](https://github.com/ZeusLN/zeus/releases/tag/v13.1.0-rc1) - Auslieferung des CLINK-noffer
+- [Amethyst PR #3039](https://github.com/vitorpamplona/amethyst/pull/3039) - NIP-BC On-Chain-zaps-Verifikationszustandsmaschine und Reverify-Treiber
+- [Amethyst PR #3177](https://github.com/vitorpamplona/amethyst/pull/3177) - Implementierung von CLINK (Common Lightning Interface for Nostr Keys)
+- [Amethyst PR #3182](https://github.com/vitorpamplona/amethyst/pull/3182) - kotlinx-serialization-Unterstützung für CLINK-Protokoll-DTOs hinzugefügt
+
+**Erwähnt in:**
+- [Newsletter #27: Amethyst v1.12.0 liefert Cashu-Wallets, nutzaps, einen CLINK-Treiber und Tor-Selbstheilung](/de/newsletters/2026-06-17-newsletter/#amethyst-v1120-ships-cashu-wallets-nutzaps-a-clink-driver-and-tor-self-heal)
+- [Newsletter #27: Zeus v13.1.0-rc1 liefert CLINK-noffers und warteschlangenloses NWC](/de/newsletters/2026-06-17-newsletter/#zeus-v1310-rc1-ships-clink-noffers-and-queue-less-nwc)
+
+**Siehe auch:**
+- [NIP-57: Zaps](/de/topics/nip-57/)
+- [NIP-47: Nostr Wallet Connect](/de/topics/nip-47/)

content/de/topics/keycast.md

@@ -0,0 +1,53 @@
+---
+title: "Keycast: Team-Nostr-Remote-Signierung"
+date: 2026-05-21
+draft: false
+translationOf: /en/topics/keycast.md
+translationDate: 2026-07-01
+categories:
+  - Signing
+  - Security
+  - Teams
+---
+
+Keycast ist ein selbst gehosteter NIP-46-Remote-Signing-Server, der für Teams entwickelt wurde. Er speichert private Nostr-Schlüssel verschlüsselt in SQLite, generiert NIP-46-bunker-Verbindungszeichenketten und betreibt Signierer-Prozesse, die Remote-Signieranfragen gemäß konfigurierbarer Richtlinien pro Schlüssel genehmigen oder ablehnen. Das Projekt wird von der Marmot Protocol-Organisation gepflegt.
+
+## Wie es funktioniert
+
+Der Server besteht aus vier Hauptkomponenten: einer Axum-API, die die Team-Verwaltung und NIP-98-HTTP-Authentifizierung übernimmt, einem SvelteKit-Web-Frontend, das NIP-07 zur Authentifizierung verwendet, einem Signierer-Manager, der Autorisierungszeilen überwacht und einen `signer_daemon` pro Autorisierung startet, und einer SQLite-Datenbank mit Migrationen.
+
+Teammitglieder melden sich über ihre NIP-07-Browser-Erweiterung an. Die Web-App fordert ein NIP-98-HTTP-Auth-event an, das lokal von der Erweiterung signiert wird, und sendet dann diesen Auth-Header an die API. Die API verifiziert das event, extrahiert den pubkey und prüft die Team-Mitgliedschaft. Gespeicherte Schlüssel werden mit einer Root-`master.key`-Datei verschlüsselt, die separat vom Image eingebunden und niemals committet werden darf.
+
+Der Signierer-Daemon entschlüsselt beim Start den gespeicherten Schlüssel und den bunker-Schlüssel, verbindet sich mit konfigurierten relays und ruft `Authorization::validate_policy` auf, bevor er jede NIP-46-Signieranfrage genehmigt. Richtlinien legen fest, welche event-kinds eine bestimmte bunker-Verbindung signieren darf.
+
+## Sicherheitsaudit (Mai 2026)
+
+Ein im Mai 2026 abgeschlossenes Sicherheitsaudit befasste sich mit Problemen bei Authentifizierung, Berechtigungen, Datenintegrität und Abhängigkeiten. Wichtige Änderungen:
+
+- Die NIP-98-Authentifizierung erfordert nun genau einen `u`-tag und einen `method`-tag, weist veraltete oder zukünftige Zeitstempel zurück und validiert `payload`-Hashes des Anfragekörpers
+- `ALLOWED_PUBKEYS` wird exakt geparst und serverseitig durchgesetzt; das Frontend stellt `/api/config?pubkey=<hex>` bereit, damit der Browser den Allowlist-Status prüfen kann, ohne die vollständige Serverliste zu erhalten
+- Leere Richtlinien lehnen sign/encrypt/decrypt-Anfragen standardmäßig ab; die Richtlinienerstellung weist unbekannte oder fehlerhafte Berechtigungskonfigurationen zurück
+- SQLite-Verbindungen aktivieren die Durchsetzung von Fremdschlüsseln; die Team-Löschung verliert keine Berechtigungs-Join-Daten mehr vor der Bereinigung
+- Der serverseitige Routenschutz deckt nun auch verschachtelte App-Routen wie `/teams/:id` ab
+- Web-Antworten setzen CSP-, Frame-, Content-Type-, Referrer-, Permissions- und HSTS-Header
+- Eine SQL-Migration normalisiert alte allowed-kinds-Berechtigungs-JSON beim Start von `{"sign":[...]}` zu `{"allowed_kinds":[...]}`
+
+Das Audit vermerkt verbleibende Punkte in [AUDIT.md](https://github.com/marmot-protocol/keycast/blob/master/AUDIT.md), die vor dem Vertrauen der Bereitstellung mit echten Team-Schlüsseln bearbeitet werden sollten.
+
+## Bereitstellung
+
+Die Docker-Compose-Bereitstellung bindet `master.key` in API- und Signierer-Container ein, führt Container mit einer Nicht-Root-UID/GID und einem schreibgeschützten Root-Dateisystem aus und verwendet Caddy-Labels, um `/api/*` an die API und alles andere an die Web-App zu leiten. Das veröffentlichte Image unter `ghcr.io/marmot-protocol/keycast` ist mit `master`, `latest` und `sha-<commit>` getaggt.
+
+---
+
+**Primärquellen:**
+- [Keycast-Repository](https://github.com/marmot-protocol/keycast)
+- [AUDIT.md](https://github.com/marmot-protocol/keycast/blob/master/AUDIT.md) - Ergebnisse des Sicherheitsaudits vom Mai 2026
+
+**Erwähnt in:**
+- [Newsletter #23: Keycast-Sicherheitsaudit abgeschlossen](/de/newsletters/2026-05-21-newsletter/#keycast-security-audit-complete)
+
+**Siehe auch:**
+- [NIP-46: Nostr Remote Signing](/de/topics/nip-46/)
+- [NIP-07: Browser Extension Signer](/de/topics/nip-07/)
+- [Marmot Protocol](/de/topics/marmot/)

content/de/topics/nip-101e.md

@@ -0,0 +1,46 @@
+---
+title: "NIP-101e: Fitness-Workouts"
+date: 2026-06-17
+draft: false
+translationOf: /en/topics/nip-101e.md
+translationDate: 2026-07-01
+categories:
+  - Fitness
+  - Discovery
+---
+
+NIP-101e definiert ein Workout-event-Format, damit Fitness-Tracking-Anwendungen Trainingseinheiten auf Nostr veröffentlichen, teilen und entdecken können. Die Spezifikation verwendet kind 1301-events, die Sitzungsmetriken (Distanz, Dauer, Höhenmeter, Herzfrequenz, Kalorien, Trittfrequenz beim Radfahren, Quell-App) in strukturierten tags tragen, sodass ein Client das Workout als strukturierte Karte mit in den korrekten Einheiten dargestellten Metriken rendern kann.
+
+## Wie es funktioniert
+
+Ein NIP-101e-Workout ist ein kind 1301-event mit strukturierten tags für jede Metrik, die die Quellanwendung erfasst hat. Häufige tags sind:
+
+- `type` für die Workout-Disziplin (Laufen, Radfahren, Schwimmen, Krafttraining usw.)
+- `distance` mit Wert und Einheit
+- `duration` in Sekunden
+- `elevation_gain` mit Wert und Einheit
+- `start`- und `end`-Zeitstempel
+- `heart_rate` (Durchschnitt und Maximum)
+- `calories` für den Energieverbrauch
+- `source`, der die veröffentlichende Anwendung benennt
+- `t`-Themen-tags für die Hashtag-Entdeckung
+
+Das `content`-Feld enthält eine optionale, vom Nutzer verfasste Notiz (das Äquivalent der Bildunterschrift, die ein Nutzer an einen Strava-Upload anhängen würde). Clients, die kind 1301 erkennen, rendern die strukturierten Metriken als Workout-Karte; Clients, die dies nicht tun, greifen darauf zurück, das `content`-Feld als reguläre Notiz anzuzeigen.
+
+## Discovery- und Feed-Semantik
+
+NIP-101e-events sind normale Feed-events, sodass ein von einem Nutzer veröffentlichtes Workout in den Timelines seiner Follower wie jeder andere Beitrag erscheint. Clients mit dedizierten Workout-Ansichten können kind 1301 mit Autor- oder Hashtag-Filtern abonnieren, um Trainingslog-Oberflächen, Ranglisten oder Feeds für Community-Herausforderungen aufzubauen. Der Autor-pubkey ist die kanonische Identität für das Workout, sodass eine Drittanwendung, die die Workouts eines anderen Nutzers liest, dieselben Vertrauensannahmen erbt wie jeder andere Nostr-Feed.
+
+## Implementierungen
+
+- [Amethyst v1.12.0](https://github.com/vitorpamplona/amethyst/releases/tag/v1.12.0) liefert kind 1301-Workout-Rendering mit einer Hero-Metrik, einem Statistik-Raster, einer radsportspezifischen Geschwindigkeitsanzeige und Quell-Badges ([PR #3184](https://github.com/vitorpamplona/amethyst/pull/3184), refaktoriert in [PR #3226](https://github.com/vitorpamplona/amethyst/pull/3226))
+
+---
+
+**Primärquellen:**
+- [NIP-101e-Spezifikation](https://github.com/nostr-protocol/nips/blob/master/101e.md)
+- [Amethyst PR #3184](https://github.com/vitorpamplona/amethyst/pull/3184) - NIP-101e-Fitness-Workout-Unterstützung hinzugefügt (Kind 1301)
+- [Amethyst PR #3226](https://github.com/vitorpamplona/amethyst/pull/3226) - Workout-Anzeige mit Hero-Metrik und Statistik-Raster neu gestaltet
+
+**Erwähnt in:**
+- [Newsletter #27: Amethyst v1.12.0 liefert Cashu-Wallets, nutzaps, einen CLINK-Treiber und Tor-Selbstheilung](/de/newsletters/2026-06-17-newsletter/#amethyst-v1120-ships-cashu-wallets-nutzaps-a-clink-driver-and-tor-self-heal)

content/de/topics/nip-37.md

@@ -0,0 +1,66 @@
+---
+title: "NIP-37: Entwurfs-Wraps"
+date: 2026-07-01
+draft: false
+translationOf: /en/topics/nip-37.md
+translationDate: 2026-07-01
+categories:
+  - NIP
+  - Drafts
+  - Privacy
+---
+
+NIP-37 definiert ein verschlüsseltes Speicher-event für unsignierte Entwurfs-events beliebiger Art. Ein Nutzer, der einen Langform-Artikel verfasst, ein bevorstehendes Kalender-event erstellt oder eine Nachricht schreibt, die er später senden möchte, kann den Entwurf auf relays unter einem kind `31234`-event speichern, verschlüsselt mit seinem eigenen Schlüssel über [NIP-44](/de/topics/nip-44/). Der Entwurf ist von jedem Client wiederherstellbar, der den Schlüssel des Nutzers besitzt, und dasselbe NIP definiert ein separates `kind:10013`-Listen-event, das die relays benennt, auf denen der Nutzer seine privaten Entwürfe speichern möchte.
+
+## Wie es funktioniert
+
+Ein Entwurfs-Wrap ist ein parametrisiertes ersetzbares event der Art `31234`. Das unsignierte Entwurfs-event wird als JSON serialisiert, mit NIP-44 auf den eigenen öffentlichen Schlüssel des Signierers verschlüsselt und in `.content` platziert. Ein `k`-tag deklariert die Art des Entwurfs, damit ein Client Entwürfe nach event-Typ gruppieren kann. Ein `d`-tag trägt den Entwurfsbezeichner, sodass der Wrap ersetzt werden kann, während sich der Entwurf entwickelt, und ein NIP-40-`expiration`-tag wird empfohlen, damit alte Entwürfe automatisch ablaufen.
+
+```json
+{
+  "kind": 31234,
+  "tags": [
+    ["d", "<identifier>"],
+    ["k", "<kind of the draft event>"],
+    ["expiration", "<unix-timestamp>"]
+  ],
+  "content": "<nip44Encrypt(JSON.stringify(draft_event))>"
+}
+```
+
+Ein leeres `.content`-Feld signalisiert, dass der Entwurf gelöscht wurde.
+
+## Checkpoints
+
+Kind `1234` definiert Checkpoints, die zu einem übergeordneten `kind:31234`-event gehören. Checkpoints tragen einen `a`-tag, der zurück auf den übergeordneten Entwurf verweist, und ermöglichen es einem Client, den Revisionsverlauf neben dem neuesten Entwurf zu speichern.
+
+```json
+{
+  "kind": 1234,
+  "tags": [
+    ["a", "31234:<pubkey>:<identifier>"]
+  ],
+  "content": "<nip44Encrypt(JSON.stringify(draft_event))>"
+}
+```
+
+## Relay-Liste für private Inhalte (kind 10013)
+
+Kind `10013` ist ein ersetzbares event, dessen tags die relays auflisten, auf denen der Nutzer private Inhalte speichern möchte, einschließlich Entwurfs-Wraps. Clients, die kind `31234` veröffentlichen, SOLLTEN auf relays veröffentlichen, die im kind `10013`-event des Nutzers aufgeführt sind. Dies trennt die für öffentliche Beiträge verwendete relay-Menge (NIP-65) von der für die private Inhaltsspeicherung verwendeten relay-Menge, sodass ein Nutzer private Entwürfe an eine kleine Menge vertrauenswürdiger relays binden kann, ohne diese Menge in seiner öffentlichen Outbox offenzulegen.
+
+## Implementierungen
+
+- [Notedeck](https://github.com/damus-io/notedeck) - speichert private Sync-relays als kind-10013-Liste (hinzugefügt 2026-06)
+
+---
+
+**Primärquellen:**
+- [NIP-37-Spezifikation](https://github.com/nostr-protocol/nips/blob/master/37.md)
+- [Notedeck-commit, der private Sync-relays als kind-10013 speichert](https://github.com/damus-io/notedeck) - Das Damus-Team übernimmt die Spezifikation für die Verwaltung der Desktop-Sync-relays
+
+**Erwähnt in:**
+- [Newsletter #29: Notedeck](/de/newsletters/2026-07-01-newsletter/#notedeck-implements-nip-37-private-sync-relays-nip-52-calendar-and-nip-22-comments)
+
+**Siehe auch:**
+- [NIP-44: Versionierte Verschlüsselung](/de/topics/nip-44/)
+- [NIP-65: Relay-Listen-Metadaten](/de/topics/nip-65/)