Add translations for Newsletter #31 and topic pages

content/de/topics/concord-protocol.md

@@ -0,0 +1,61 @@
+---
+title: "Concord-Protokoll"
+date: 2026-07-15
+translationOf: /en/topics/concord-protocol.md
+translationDate: 2026-07-15
+draft: false
+categories:
+  - Protocol
+  - Messaging
+---
+
+Concord ist ein offenes, MIT-lizenziertes Protokoll für Ende-zu-Ende-verschlüsselte Communities und Kanäle auf Nostr, definiert durch die [CORD-01- bis CORD-07-Spezifikationen](https://github.com/concord-protocol/concord). [Vector](https://github.com/VectorPrivacy/Vector) hat es ab v0.4.0 als Standard-Transport für seine Group-Chats-Funktion übernommen und nennt es in den eigenen Release Notes „our custom messaging protocol", doch die Spezifikation selbst wird getrennt von Vector veröffentlicht und hat bereits unabhängige Implementierungen.
+
+## Funktionsweise
+
+Concord zerlegt das, was ein Discord-artiger Community-Server normalerweise tut, in Teile, die niemandem vertrauen müssen: Relays speichern ausschließlich verschlüsselte Blobs, die an rotierende Labels adressiert sind; den Schlüssel eines Raums zu besitzen macht jemanden zum Mitglied; und die Autorität über Rollen, Kicks und Bans ist ein signiertes Roster, das in der Identität des Eigentümers verwurzelt ist und das jeder Client lokal verifiziert, anstatt einem Server zu vertrauen. Jedes dauerhafte Event nutzt denselben dreischichtigen Umschlag: einen kind-1059-Wrap, signiert mit dem abgeleiteten Stream-Key der Ebene, der einen Seal enthält, signiert mit dem echten Schlüssel des Autors, der wiederum einen unsignierten Rumor enthält, der das funktionale Event trägt. Ein Chat-Nachrichten-Rumor ist ein einfaches kind-9-Event:
+
+```json
+{
+  "kind": 9,
+  "pubkey": "<author>",
+  "content": "Hey chat!",
+  "tags": [
+    ["channel", "<channel_id>"],
+    ["epoch", "0"]
+  ]
+}
+```
+
+Control-, Chat- und Guestbook-Verkehr erhalten jeweils ihre eigene [NIP-59](/de/topics/nip-59/) Gift-Wrapped-Ebene, sodass ein Relay, das alle drei hält, eine Control-Nachricht nicht von einer Chat-Nachricht oder einem Gästebuch-Eintrag unterscheiden kann, ohne den Raumschlüssel zu besitzen. Die Spezifikation ist in sieben CORD-Dokumente aufgeteilt: Private Streams (01), Communities und Mitgliedschaft (02), Kanäle (03), Rollen (04), Einladungen (05), Rekeying und Re-Founding zum Ausschluss entfernter Mitglieder (06) sowie Audio/Video über einen Blind-Token-Broker (07). Die Mitgliedschaft selbst hat keine serverseitige Liste: Wer die Ebene entschlüsseln kann, ist Mitglied, und jemanden wirklich zu entfernen bedeutet, die Community auf einen neuen Schlüssel-Epoch zu rollen und diesen nur den Verbliebenen zu übergeben, anstatt eine Zeile aus einer Tabelle zu löschen.
+
+## Unterschiede zu Marmot
+
+Concord und [Marmot](/de/topics/marmot/) lösen verschlüsseltes Gruppen-Messaging auf Nostr mit unterschiedlicher Kryptographie für unterschiedliche Gruppenformen, und der Vergleich des Concord-Projekts ist explizit bezüglich der Aufteilung: Marmot legt [MLS](/de/topics/mls/) über Nostr für Forward Secrecy und Post-Compromise Security, unter Verwendung von Pro-Gerät-Key-Packages und geordneten Commits, die die gesamte Gruppe im Gleichschritt voranbringen. Das bietet starke Garantien, zu Kosten, die mit Mitgliedschaftsänderungen skalieren, gut geeignet für kleine, hochsensible Gruppen, in denen Beitritte und Abgänge selten sind. Concord gibt stattdessen jedem Mitglied denselben Raumschlüssel und führt ein Rekeying des gesamten Raums bei Entfernung durch, anstatt pro Commit zu ratcheten, und tauscht damit einige der kryptographischen Garantien von MLS gegen ein Modell, das günstig bleibt, wenn eine Community auf Hunderte oder Tausende von gelegentlichen Mitgliedern mit hoher Fluktuation wächst, genau die Form, die Discord-artige Communities tatsächlich annehmen.
+
+## Warum Vector gewechselt hat
+
+Vectors eigene [v0.4.0 Release Notes](https://github.com/VectorPrivacy/Vector/releases/tag/v0.4.0) beschreiben Concord nur als „our custom messaging protocol" für Group Chats, ohne die Begründung direkt zu nennen. Die Passung zur veröffentlichten Begründung von Concord ist dennoch klar: Group Chats in einem Client wie Vector sind genau der Fall mit großer, offener, häufig wechselnder Mitgliedschaft, in dem der Pro-Gerät-MLS-State von Marmot zum teureren Weg wird, und Concords asynchrones, jederzeit beitretbares Design ist genau für diesen Fall gebaut. [Vector v0.4.0](https://github.com/VectorPrivacy/Vector/releases/tag/v0.4.0) hat Marmot für Group Chats zugunsten von Concord abgelöst, und bestehende Marmot-Gruppenverläufe wurden beim Wechsel nicht übernommen. [v0.4.1](https://github.com/VectorPrivacy/Vector/releases/tag/v0.4.1) lieferte vier Tage später „Concord v2" mit Datenschutz- und Stabilitätsverbesserungen. Innerhalb derselben Woche [mergte Amethyst seine eigene Clean-Room-, drahtkompatible Concord-Implementierung](https://github.com/vitorpamplona/amethyst/pull/3566), und Soapbox' Discord-artiger Client [Armada](https://gitlab.com/soapbox-pub/armada) baut sein Communities-Feature bereits auf derselben Spezifikation als Referenzimplementierung auf. Drei unabhängige Clients, die innerhalb von Tagen auf eine offene Spezifikation konvergieren, sind ein schneller Weg zu echter Client-übergreifender Interoperabilität, lohnenswert zu verfolgen im Vergleich dazu, wie viel vom Rest der Nostr-Gruppen-Chat-Clients auf Marmot bleibt.
+
+## Implementierungen
+
+- [Vector](https://github.com/VectorPrivacy/Vector) - Single-Binary, datenschutzorientierter Nostr-Messenger; erster ausgelieferter Concord-Client, in v0.4.0
+- [Armada](https://gitlab.com/soapbox-pub/armada) (Soapbox) - Discord-artiger Community-Client; Referenzimplementierung, Backend im separaten `armada-relay`-Repository
+- [Amethyst](https://github.com/vitorpamplona/amethyst) - funktionsreicher Android- und Multiplattform-Nostr-Client; Clean-Room-Reimplementierung, drahtkompatibel mit Armada ([PR #3566](https://github.com/vitorpamplona/amethyst/pull/3566))
+
+---
+
+**Primärquellen:**
+- [Concord-Protokoll-Spezifikationen (CORD-01 bis CORD-07)](https://github.com/concord-protocol/concord)
+- [Vector v0.4.0 Release Notes](https://github.com/VectorPrivacy/Vector/releases/tag/v0.4.0)
+- [Vector v0.4.1 Release Notes](https://github.com/VectorPrivacy/Vector/releases/tag/v0.4.1)
+- [Amethyst PR #3566](https://github.com/vitorpamplona/amethyst/pull/3566)
+
+**Erwähnt in:**
+- [Newsletter #31: Vector v0.4.0 moves Group Chats from Marmot to Concord, and Amethyst ships its own Concord client days later](/de/newsletters/2026-07-15-newsletter/#vector-v040-moves-group-chats-from-marmot-to-concord-and-amethyst-ships-its-own-concord-client-days-later)
+- [Newsletter #31: Amethyst ships a clean-room Concord implementation for end-to-end encrypted communities](/de/newsletters/2026-07-15-newsletter/#amethyst-ships-a-clean-room-concord-implementation-for-end-to-end-encrypted-communities)
+
+**Siehe auch:**
+- [Marmot-Protokoll](/de/topics/marmot/)
+- [MLS (Message Layer Security)](/de/topics/mls/)
+- [NIP-46: Nostr Connect](/de/topics/nip-46/)

content/de/topics/gamma-markets.md

@@ -0,0 +1,69 @@
+---
+title: "Gamma Markets"
+date: 2026-07-15
+translationOf: /en/topics/gamma-markets.md
+translationDate: 2026-07-15
+draft: false
+categories:
+  - Commerce
+  - Marketplace
+  - Protocol
+---
+
+Gamma Markets ist ein Satz von E-Commerce-Konventionen, die direkt auf [NIP-99](/de/topics/nip-99/) Classified Listings aufbauen. Sie wurden gemeinschaftlich von einer Arbeitsgruppe von Nostr-Marktplatz-Entwicklern entwickelt: den Teams hinter Shopstr, Cypher, Plebeian Market und Conduit Market. Gamma Markets füllt die Versand-, Bestellablauf-, Sammlungs- und Bewertungskonventionen, die NIP-99 selbst nicht definiert.
+
+## Funktionsweise
+
+Gamma Markets fügt fünf Event-Kinds rund um das bestehende kind-`30402`-Listing-Event von NIP-99 hinzu, ohne dessen Form zu ändern:
+
+- **Kind 30405** - Produktsammlungen, die mehrere Listings über `a`-Tags gruppieren
+- **Kind 30406** - Versandoptionen mit länderspezifischer Preisgestaltung und optionalen gewichts- oder entfernungsbasierten Kostenregeln
+- **Kind 16** - Bestellnachrichten: Erstellung (Typ 1), Zahlungsanforderungen (Typ 2), Statusaktualisierungen (Typ 3) und Versandaktualisierungen (Typ 4)
+- **Kind 14** - Allgemeine Kommunikation zwischen Käufer und Händler
+- **Kind 17** - Zahlungsbelege
+- **Kind 31555** - Produktbewertungen, adressiert an einen bestimmten Verkäufer-pubkey und Listing-`d`-Tag
+
+Die Zahlungspräferenzen eines Händlers werden über ein `payment_preference`-Tag in den kind-`0`-Profilmetadaten deklariert, und Clients entdecken kompatible Apps über [NIP-89](/de/topics/nip-89/)-Anwendungsempfehlungen. Die Bestellkommunikation baut auf [NIP-17](/de/topics/nip-17/) Private Messages auf, ohne ein eigenes Verschlüsselungsschema.
+
+Die zentrale Designentscheidung der Spezifikation ist, dass nichts kaskadiert: Ein Listing, das zu einer Sammlung gehört oder eine Versandoption nutzt, referenziert diese explizit über ein `a`-Tag, anstatt die Einstellungen des übergeordneten Elements automatisch zu erben. Das ist eine bewusste Abkehr vom älteren [NIP-15](/de/topics/nip-15/)-Stall-Modell, bei dem ein Produkt stillschweigend die Währung und Versandtabelle seines Stalls erbte.
+
+### Beispiel: Bestellerstellung (kind 16, Typ 1)
+
+```json
+{
+  "kind": 16,
+  "content": "Please leave the package with the doorman.",
+  "tags": [
+    ["p", "<merchant-pubkey>"],
+    ["subject", "New order"],
+    ["type", "1"],
+    ["order", "order-8f21"],
+    ["amount", "115000"],
+    ["item", "30402:<merchant-pubkey>:keyboard-mx-blue-01", "1"],
+    ["shipping", "30406:<merchant-pubkey>:standard-regional"]
+  ]
+}
+```
+
+## Warum es wichtig ist
+
+NIP-99 allein standardisiert nur das Listing selbst, eine signierte, adressierbare Kleinanzeige. Vor Gamma Markets erfand jeder Client, der echten E-Commerce auf NIP-99 aufbaute, seine eigenen privaten Konventionen für Versand, Checkout und Bewertungen, was bedeutete, dass zwei NIP-99-konforme Clients jeweils ein Listing korrekt darstellen konnten, aber keinen gemeinsamen Weg hatten, eine Bestellung zwischen ihnen abzuschließen. Gamma Markets schließt diese Lücke, ohne das NIP-99-Listing-Format selbst zu verändern, sodass bestehende NIP-99-Listings ohne Änderung gültig bleiben.
+
+## Implementierungen
+
+- [Shopstr](https://github.com/shopstr-eng/shopstr) - Nostr-Marktplatz, eines der vier Projekte, die die Spezifikation verfasst haben
+- [Conduit Mono](https://github.com/Conduit-BTC/conduit-mono) - Marktplatz-Protokoll, das seinen eigenen Bestellstatus- und Checkout-Ablauf im selben Designraum aufbaut
+
+---
+
+**Primärquellen:**
+- [Gamma Markets Spezifikations-Repository](https://github.com/GammaMarkets/market-spec)
+- [NIP-99 E-Commerce-Anwendungsfall-Erweiterung, PR #1784](https://github.com/nostr-protocol/nips/pull/1784) - gemergter Link vom kanonischen NIP-99-Dokument zur Gamma-Markets-Spezifikation
+
+**Erwähnt in:**
+- [Newsletter #31: NIP Deep Dive: NIP-99 und die Gamma-Markets-Commerce-Erweiterung](/de/newsletters/2026-07-15-newsletter/#nip-deep-dive-nip-99-and-the-gamma-markets-commerce-extension)
+
+**Siehe auch:**
+- [NIP-99: Classified Listings](/de/topics/nip-99/)
+- [NIP-15: Nostr Marketplace](/de/topics/nip-15/)
+- [NIP-17: Private Direct Messages](/de/topics/nip-17/)

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

@@ -0,0 +1,46 @@
+---
+title: "NIP-4E: Entkopplung von Verschlüsselung und Identität"
+date: 2026-07-15
+translationOf: /en/topics/nip-4e.md
+translationDate: 2026-07-15
+draft: false
+categories:
+  - NIP
+  - Protocol
+  - Encryption
+---
+
+NIP-4E ist ein offener Entwurf, vorgeschlagen von fiatjaf, zum Teilen privater Daten zwischen den eigenen Geräten eines Nutzers, ohne dass jedes Gerät den Haupt-Nostr-Identitätsschlüssel des Nutzers besitzen muss. Es ist nicht gemergt und bleibt ein `draft`/`optional`-Vorschlag.
+
+## Das adressierte Problem
+
+Viele bestehende NIPs, darunter NIP-51-Listen und NIP-60-Cashu-Wallets, verschlüsseln Daten vom Nutzer an sich selbst unter Verwendung des Identitätsschlüssels, damit sie später auf jedem Gerät wieder gelesen werden können. Das funktioniert nicht mehr, wenn der Identitätsschlüssel nicht direkt zugänglich ist, beispielsweise wenn ein Remote Signer durch FROST-Threshold-Shares, MuSig2 oder ein gehostetes Secure Enclave geschützt ist, da Ver- und Entschlüsselung dann jedes Mal einen Roundtrip zu diesem Signer erfordern. Offline-Verschlüsselung wird ebenfalls unmöglich, wenn der Signaturschlüssel in einem Remote Bunker liegt.
+
+## Funktionsweise
+
+NIP-4E trennt einen gerätespezifischen „Client Key" von einem gemeinsamen „Encryption Key", der nicht der Identitätsschlüssel des Nutzers ist:
+
+1. Der erste Client, den ein Nutzer einrichtet, generiert ein zufälliges Verschlüsselungs-Schlüsselpaar und kündigt dessen öffentliche Hälfte in einem `kind:10044`-Event an, das mit dem Identitätsschlüssel des Nutzers signiert ist.
+2. Jeder andere Client, der Daten für diesen Nutzer ver- oder entschlüsseln möchte, berechnet sein Diffie-Hellman-Shared-Secret gegen den angekündigten Verschlüsselungsschlüssel statt gegen den Identitätsschlüssel.
+3. Wenn ein zweites Gerät einen neuen Client installiert, generiert dieser Client seinen eigenen lokalen „Client Key" und veröffentlicht eine `kind:4454`-Ankündigung (ebenfalls mit dem Identitätsschlüssel des Nutzers signiert), die den ersten Client bittet, den Verschlüsselungsschlüssel zu teilen.
+4. Der ursprüngliche Client erkennt die neue `kind:4454`-Ankündigung, verschlüsselt den gemeinsamen Verschlüsselungsschlüssel an den Schlüssel des neuen Clients mittels [NIP-44](/de/topics/nip-44/) und veröffentlicht ihn, damit der neue Client ihn entschlüsseln und fortan verwenden kann.
+
+Das Ergebnis ist, dass Ver- und Entschlüsselung niemals den Identitätsschlüssel-Signer abfragen müssen, sobald ein Client den gemeinsamen Verschlüsselungsschlüssel lokal besitzt, und ein Remote-Signer-Setup (FROST, MuSig2, gehostetes Enclave) für die Identität verwendet werden kann, während gewöhnliche Verschlüsselung schnell bleibt und offline funktioniert.
+
+## Warum es wichtig ist
+
+NIP-4E wird als Grundlage für andere Vorschläge zitiert, die einen laufwerk- oder kontoweiten symmetrischen Schlüssel benötigen, ohne bei jedem Ver-/Entschlüsselungsaufruf auf einen Remote Signer angewiesen zu sein, darunter ein Vorschlag für ein privates verschlüsseltes Laufwerk ([PR #2412](https://github.com/nostr-protocol/nips/pull/2412)) und eine engere NIP-17-spezifische Version derselben Idee ([PR #2361](https://github.com/nostr-protocol/nips/pull/2361)). Beide bleiben neben NIP-4E selbst offen, was dies zu einem aktiven, noch nicht abgeschlossenen Bereich des Protokolls macht, nicht zu einem fertigen Baustein.
+
+---
+
+**Primärquellen:**
+- [NIP-4E-Entwurf, PR #1647](https://github.com/nostr-protocol/nips/pull/1647)
+
+**Erwähnt in:**
+- [Newsletter #31: Open: private encrypted drive extends NIP-4E](/de/newsletters/2026-07-15-newsletter/#open-private-encrypted-drive-extends-nip-4e)
+
+**Siehe auch:**
+- [NIP-44: Encrypted Payloads](/de/topics/nip-44/)
+- [NIP-17: Private Direct Messages](/de/topics/nip-17/)
+- [NIP-46: Nostr Connect](/de/topics/nip-46/)
+- [FROST](/de/topics/frost/)

content/de/topics/proofmode.md

@@ -0,0 +1,36 @@
+---
+title: "ProofMode"
+date: 2026-07-15
+translationOf: /en/topics/proofmode.md
+translationDate: 2026-07-15
+draft: false
+categories:
+  - Media
+  - Provenance
+---
+
+[ProofMode](https://proofmode.org/) ist ein Open-Source-Toolkit für Medien-Provenienz, entwickelt von Guardian Project, WITNESS und Okthanks, das verifizierbare Authentizitäts- und Chain-of-Custody-Daten an Fotos und Videos im Moment der Aufnahme anfügt. Es ist nicht Nostr-spezifisch; Nostr-Clients, die ProofMode-Daten mitführen, integrieren einen bestehenden externen Standard und keine neue Protokollschicht.
+
+## Funktionsweise
+
+Die Capture-Komponente von ProofMode bettet Provenienz-Metadaten direkt in Mediendateien während der Aufnahme ein und unterstützt dieselben interoperablen Standards, die von der Content Authenticity Initiative (CAI), Content Credentials (CR) und C2PA verwendet werden. Eine separate Verify-Komponente prüft Audio-, Bild- und Videodateien auf Anzeichen von KI-Generierung oder nachträglicher Bearbeitung in diesen Metadaten, und eine Preserve-Komponente übernimmt die redundante, dezentralisierte Web-Speicherung der zugrunde liegenden Nachweisdaten für die Langzeitarchivierung. Ein Develop SDK ermöglicht es Apps, Aufnahme und Verifikation zu integrieren, ohne das Provenienzformat selbst aufzubauen.
+
+## Warum es wichtig ist
+
+Für einen Nostr-Video- oder -Bild-Client bedeutet das Mitführen von ProofMode-Daten, dass ein Betrachter eine externe, plattformübergreifende Möglichkeit hat zu prüfen, ob ein Medienstück wie behauptet aufgenommen wurde und seitdem nicht stillschweigend verändert wurde, ohne sich auf den veröffentlichenden Client oder Relay als Vertrauensquelle zu verlassen. Diese Unterscheidung ist am wichtigsten für eine heruntergeladene oder neu kodierte Kopie eines Clips: Provenienzdaten, die den Download und etwaiges Wasserzeichen überleben, das ein Client anwendet, machen die Attestierung auch noch überprüfbar, nachdem die Datei die App verlassen hat, die sie erzeugt hat.
+
+## Implementierungen
+
+- [Divine](https://github.com/divinevideo/divine-mobile) - Kurzvideo-Nostr-Client; führt ProofMode-Provenienzdaten durch wasserzeichenmarkierte Clip-Downloads
+
+---
+
+**Primärquellen:**
+- [ProofMode](https://proofmode.org/)
+
+**Erwähnt in:**
+- [Newsletter #17](/de/newsletters/2026-04-29-newsletter/)
+- [Newsletter #31: Divine Mobile 1.0.16 ships a deeper video editor, at-rest encryption, and ProofMode provenance](/de/newsletters/2026-07-15-newsletter/#divine-mobile-1016-ships-a-deeper-video-editor-at-rest-encryption-and-proofmode-provenance)
+
+**Siehe auch:**
+- [Blossom](/de/topics/blossom/)