Nostr

Öffentliche und geheime Schlüssel bilden Identität und Zugriff zugleich. Behandelt werden npub, nsec, sichere Sicherungen, Hardware- und Software-Signer sowie das Verhalten bei verlorenen oder offengelegten Schlüsseln.

Ein Client wird eingerichtet, ein Profil angelegt und mit mehreren Relays verbunden. Die Lernenden veröffentlichen eine Notiz, folgen Kontakten und prüfen, wie sich Relay-Auswahl und lokale Einstellungen auswirken.

Von den ersten Protokollentwürfen bis zu mobilen Clients, Zaps, spezialisierten Relays und getrennten Signern: Die Entwicklung erklärt, warum Nostr bewusst klein begann und durch NIPs erweitert wird.

Ein Nostr-Ereignis enthält ID, öffentlichen Schlüssel, Zeitstempel, Art, Tags, Inhalt und Signatur. Die Lernenden lesen Ereignisse als JSON, berechnen ihre IDs und prüfen ihre Gültigkeit.

Reguläre, ersetzbare, parametrisiert ersetzbare und flüchtige Ereignisse haben unterschiedliche Speicher- und Konfliktregeln. Auch Löschanfragen, Ablaufzeiten und die Grenzen einer nachträglichen Löschung werden behandelt.

Clients und Relays kommunizieren über WebSockets mit EVENT-, REQ-, CLOSE-, EOSE-, OK- und NOTICE-Nachrichten. Filter nach Autoren, Kinds, Tags und Zeiträumen werden direkt gegen ein Test-Relay ausprobiert.

Nostr Implementation Possibilities definieren interoperable Erweiterungen des Kernprotokolls. Das Kapitel zeigt Status, Abhängigkeiten und Aushandlung von NIPs sowie den Weg von einer Idee zu einer belastbaren Spezifikation.

NIP-19 kodiert Schlüssel, Ereignisse, Profile und adressierbare Inhalte als npub, nprofile, note, nevent und naddr. Die Lernenden wählen passende Kennungen und vermeiden den gefährlichen Umgang mit nsec-Verweisen.

Schnorr-Signaturen auf secp256k1 schützen Urheberschaft und Unverändertheit eines Ereignisses. Hashing, kanonische Serialisierung, Signaturprüfung, Zufallswerte und typische Implementierungsfehler werden praktisch nachvollzogen.

Profilmetadaten, Kontaktlisten und Follow-Beziehungen bilden den sozialen Graphen. Behandelt werden Profilauflösung, Aktualisierung ersetzbarer Ereignisse und die Zusammenführung widersprüchlicher Daten verschiedener Relays.

Kurznachrichten, Antworten, Erwähnungen, Reposts und Reaktionen werden mit ihren Ereignissen und Tags modelliert. Thread-Markierungen, Zitatverweise und die neueren Kommentarstrukturen werden an echten Gesprächsverläufen verglichen.

NIP-51 beschreibt stummgeschaltete Nutzer, Lesezeichen, öffentliche und private Listen sowie weitere kuratierte Sammlungen. Die Lernenden bauen Listenfunktionen und entscheiden, welche Inhalte öffentlich, verschlüsselt oder nur lokal liegen sollen.

Relay-Listen und Inbox-/Outbox-Modelle helfen Clients, Ereignisse dort zu lesen und zu veröffentlichen, wo die jeweiligen Kontakte sie erwarten. Das Kapitel behandelt NIP-65, Fallbacks, Relay-Hinweise und robuste Routing-Strategien.

Mehrere Relays können dieselben, verspätete oder widersprüchliche Ereignisse liefern. Deduplizierung, Zeitabweichungen, Offline-Betrieb und die Auswahl gültiger Versionen ersetzbarer Ereignisse werden als Clientlogik umgesetzt.

NIP-05 verbindet einen öffentlichen Schlüssel mit einer menschenlesbaren Internetadresse, ohne daraus eine zentrale Kontoverwaltung zu machen. DNS, HTTPS-Antworten, Relay-Hinweise, Caching und irreführende Verifizierungsanzeigen werden behandelt.

Kommandozeilenwerkzeuge, WebSocket-Clients, lokale Relays, SDKs und Ereignisprüfer bilden eine reproduzierbare Entwicklungsumgebung. Die Lernenden senden, abonnieren, protokollieren und untersuchen Ereignisse ohne vollständige App.

Ein Client verwaltet Schlüsselzugriff, Relay-Verbindungen, Abonnements, lokalen Zustand und Benutzeroberfläche. Das Kapitel führt vom Verbindungsaufbau über Publishing und Feed-Erzeugung bis zu Fehlerbehandlung und Offline-Zwischenspeicherung.

Ein Relay nimmt Ereignisse an, prüft Signaturen und Richtlinien, speichert Daten und beantwortet gefilterte Abfragen. Die Lernenden implementieren einen kleinen Relay-Kern mit WebSocket-Sitzungen und klaren Ablehnungsgründen.

Ereignisse müssen nach IDs, Autoren, Kinds, Zeit und Tags effizient auffindbar sein. Indexdesign, Volltextsuche, Aufbewahrungsregeln, Löschung lokaler Kopien und die Grenzen relationaler sowie logbasierter Speicher werden verglichen.

Ein produktives Relay braucht TLS, Limits, Protokollierung, Metriken, Sicherungen und Verfahren gegen Missbrauch. Behandelt werden NIP-11-Relayinformationen, Verwaltungs-APIs, bezahlter Zugang, Wartung und Wiederherstellung.

NIP-42 lässt ein Relay den Besitz eines Schlüssels prüfen, ohne den geheimen Schlüssel zu erhalten. Challenge-Ablauf, Sitzungsbindung, Autorisierungsregeln und Schutz vor Replay-Angriffen werden implementiert.

NIP-98 signiert HTTP-Anfragen für Dienste außerhalb des WebSocket-Protokolls. Methode, URL, Payload-Hash, Zeitfenster und Replay-Schutz werden an einer geschützten API umgesetzt.

NIP-44 definiert moderne, versionierte Nutzlastverschlüsselung für zwei Schlüsselparteien. Schlüsselableitung, Nonces, Padding, Authentifizierung und der sichere Umgang mit Entschlüsselungsfehlern stehen im Mittelpunkt.

NIP-17 und NIP-59 kombinieren verschlüsselte Inhalte, Seals und Gift Wraps, um private Nachrichten besser vor Metadatenlecks zu schützen. Das Kapitel vergleicht diesen Ablauf mit älteren NIP-04-Nachrichten und behandelt Empfang, Relay-Zustellung und Migration.

NIP-07 trennt Webanwendungen vom direkten Zugriff auf geheime Schlüssel. Berechtigungen, Ereignisvorschau, Herkunftsprüfung und sichere Bedienoberflächen für Browser-Erweiterungen und lokale Signer werden behandelt.

NIP-46 ermöglicht Remote Signing über Nostr Connect und sogenannte Bunker. Verbindungs-URIs, Berechtigungen, verschlüsselte Befehle, Sitzungswiderruf und der Betrieb eines getrennten Signierdienstes werden praktisch umgesetzt.

NIP-23 nutzt adressierbare Ereignisse für Artikel, Entwürfe und Aktualisierungen. Markdown, stabile Adressen, Versionen, Metadaten, Veröffentlichung und Kommentarverknüpfung werden in einem kleinen Publikationsablauf eingesetzt.

NIP-94 beschreibt Dateimetadaten, während Upload-Dienste wie NIP-96-Server und Blossom große Dateien außerhalb von Relays speichern. Prüfsummen, Varianten, Moderation, Löschung, Verfügbarkeit und sichere Medienanzeige werden behandelt.

NIP-57 verbindet Lightning-Zahlungen mit Nostr-Ereignissen. Zap Requests, LNURL, Belege, Prüfung, anonyme Zaps und die Darstellung bestätigter Zahlungen werden Ende zu Ende nachvollzogen.

NIP-47 erlaubt einer Nostr-Anwendung, eine getrennte Lightning-Wallet kontrolliert anzusprechen. Berechtigungen, verschlüsselte Anfragen, Zahlungsantworten, Budgets, Ablaufzeiten und Widerruf werden mit einem Test-Wallet umgesetzt.

NIP-60 modelliert Cashu-Wallets, während NIP-61 Nutzap-Zahlungen über Nostr transportiert. Token-Sicherheit, Mint-Vertrauen, Double-Spend-Prüfung, Backups und die Unterschiede zu Lightning-Zaps werden klar abgegrenzt.

NIP-29 beschreibt Gruppen, deren Mitgliedschaft und Moderation durch ein bestimmtes Relay verwaltet werden. Rollen, Einladungen, Gruppenmetadaten, Zugriffskontrolle und die Folgen eines Relay-Wechsels werden praktisch untersucht.

NIP-72 ermöglicht moderierte Communities mit vorgeschlagenen und freigegebenen Beiträgen. Das Kapitel behandelt Community-Definitionen, Moderationsereignisse, Clientdarstellung und das Verhalten bei uneinigen Moderatoren.

NIP-53 modelliert geplante und laufende Audio-, Video- oder Chat-Sitzungen. Statuswechsel, Teilnehmer, Streaming-Endpunkte, Live-Chats und die Trennung zwischen Medienübertragung und Nostr-Signalisierung werden umgesetzt.

NIP-78 bietet adressierbare Ereignisse für anwendungsspezifische Daten. Namensräume, Synchronisierung, Verschlüsselung, Versionswechsel und die Entscheidung zwischen lokalem Speicher und Relays stehen im Mittelpunkt.

NIP-89 beschreibt Anwendungen und Handler für bestimmte Ereignisarten. Clients können dadurch passende Werkzeuge finden, Links öffnen und Fähigkeiten ankündigen, ohne eine zentrale App-Liste vorauszusetzen.

NIP-90 organisiert kostenpflichtige oder verteilte Rechenaufträge als Data Vending Machines. Jobanfragen, Ergebnisse, Statusmeldungen, Verschlüsselung, Zahlung, Auswahl von Anbietern und Prüfung der Resultate werden behandelt.

NIP-34 bildet Repositorys, Patches, Issues und Statusmeldungen als Nostr-Ereignisse ab. Die Lernenden veröffentlichen einen Patch, verfolgen eine Diskussion und untersuchen, welche Aufgaben weiterhin Git-Server oder Objektspeicher benötigen.

Moderation ist in Nostr eine Kombination aus persönlichen Listen, Clientregeln, Relayrichtlinien und gemeinschaftlicher Kuratierung. Meldeereignisse, Delegation, transparente Entscheidungen und die Grenzen globaler Sperren werden anhand konkreter Fälle behandelt.

Offene Veröffentlichung erleichtert Spam, Scraping und massenhafte Scheinidentitäten. Rate Limits, NIP-13-Proof-of-Work, Zahlungen, Einladungen und andere Zugangskosten werden nach Wirksamkeit und Nebenwirkungen bewertet.

Web-of-Trust-Verfahren nutzen soziale Nähe, Empfehlungen und lokale Vertrauenssignale zur Sortierung unbekannter Inhalte. Das Kapitel behandelt Graphberechnung, Manipulationsrisiken, Kaltstartprobleme und nachvollziehbare Ranking-Entscheidungen.

Öffentliche Schlüssel sind pseudonym, aber Ereignisse, Zeitpunkte, Relay-Verbindungen und soziale Beziehungen können Personen verraten. Bedrohungsmodelle, getrennte Identitäten, Metadatenminimierung, Netzwerkbeobachtung und realistische Grenzen privater Nutzung werden behandelt.

Schlüsselraub, bösartige Signieranfragen, unsichere Links, Relay-Manipulation und Abhängigkeitsangriffe gehören zu den wichtigsten Risiken. Die Lernenden erstellen ein Sicherheitsmodell, härten Client und Relay und planen Reaktion sowie Wiederherstellung nach Vorfällen.

Negentropy gleicht große Ereignismengen ab, ohne vollständige Listen von IDs auszutauschen. Bereichsbasierte Mengenabgleiche, Protokollsitzungen, Fehlerfälle und Einsatzmöglichkeiten für Backups oder Relay-Synchronisierung werden praktisch untersucht.

Große Feeds belasten Verbindungen, Datenbanken und Endgeräte. Subscription-Sharing, Pagination, Caching, Backpressure, Relay-Sharding, Messgrößen und Lasttests helfen, Systeme ohne Aufgabe der Interoperabilität zu skalieren.

Testvektoren, lokale Relay-Netze, simulierte Verbindungsabbrüche und Vergleiche mit mehreren Implementierungen decken Protokollfehler früh auf. Dazu kommen Fuzzing, Signaturtests, NIP-Konformität und systematische Fehlersuche in WebSocket-Protokollen.

Ein vollständiges Projekt beginnt mit einem Nutzerproblem und endet mit einer betriebenen, interoperablen Nostr-Anwendung. Die Lernenden wählen NIPs, entwerfen Ereignisse, bauen Client und Dienst, testen gegen mehrere Relays, sichern Schlüsselwege ab und überwachen den Betrieb.

Nostr bietet Wege in Client- und Relay-Entwicklung, Protokollarbeit, Design, Sicherheit, Infrastruktur, Forschung und Community-Betrieb. Das Kapitel zeigt geeignete Beitragswege, aussagekräftige Projektartefakte, offene NIP-Diskussionen und Methoden, um ohne allgemein vorgeschriebene Zertifizierung fachlich aktuell zu bleiben.