Balance: Nutzerfreundlichkeit – Sicherheit – Datensouveränität
(Onboarding zu Nostr über Keycloak)

📖 Was bedeutet die Position im Dreieck?

Nutzerfreundlichkeit (oben)

Hoher Wert: Onboarding „ein Klick", kaum Schlüsselbegriffe, wenig Reibung. Niedriger Wert: mehr Erklärungen, Bestätigungen, zusätzliche Schritte (z.B. Seed-Backup, Passphrasen).

Sicherheit (links unten)

Hoher Wert: starke Trennung von Systemen, minimale Angriffsfläche, Härtung von Diensten, wenig Vollzugriffe. Niedriger Wert: mehr Komfort, aber größere Folgen bei Kompromittierung einzelner Komponenten.

Datensouveränität (rechts unten)

Hoher Wert: Nutzende behalten Kontrolle über ihre Nostr-Schlüssel und Relays, Transparenz, Export/Exit möglich. Niedriger Wert: mehr Bequemlichkeit, aber stärkere Bindung an zentrale Infrastruktur.

📚 Beispiele: Nostr-Onboarding über Keycloak

UX first (nsec in Keycloak)

Architektur: NSEC wird einmalig erzeugt und als verschlüsseltes Attribut in Keycloak gespeichert. Web-App holt den Schlüssel via Token und signiert Events server- oder clientseitig automatisch.
Effekt im Dreieck: Sehr hohe Nutzerfreundlichkeit („Einloggen & fertig"), aber starke Abhängigkeit von Keycloak als „single point of failure" und zentrale Stelle für Schlüsselkompromittierung. Datensouveränität ist begrenzt, Export/Relay-Wechsel eher ein Power-User-Feature.

Security first (Key beim User)

Architektur: NSEC liegt ausschließlich beim Nutzenden (z.B. Nostr-Signer-App, Browser-Extension). Keycloak macht nur OIDC-Login, Nostr erfolgt über NIP-46/Delegation oder lokale Signatur. Server sieht den NSEC nie.
Effekt im Dreieck: Sehr hohe Sicherheit und hohe Datensouveränität, weil der Schlüssel nicht in deiner Infrastruktur liegt. UX leidet: zusätzliche App/Extension, mehr Erklärungsbedarf, Onboarding-Schritte für „Signer verbinden".

Data first (Bunker + Schlüsselverschlüsselung)

Architektur: NSEC wird verschlüsselt (z.B. mit Nutzer-Passphrase oder Key aus Keycloak-Token) in einem dedizierten Bunker/Key-Service gespeichert. Signaturen laufen über den Bunker, der nur „entschlüsseln & signieren" kann, ohne den Klartext-Schlüssel breit verfügbar zu machen.
Effekt im Dreieck: Hohe Datensouveränität (klar definierter Schlüsselort, theoretisch portierbar), hohe Sicherheit (Schlüssel nur entschlüsselt im Bunker-Kontext), UX mittel: etwas mehr Erklärung („Was ist Bunker?"), aber ins UI gut integrierbar.

Compliance-Modus (Org-Bunker mit Policies)

Architektur: Bunker/Key-Service wird von der Organisation betrieben, mit Logging, Rollen, evtl. HSM/Hardware-Backends. Keycloak-Login erteilt nur zeitlich begrenzte Delegationen/Session-Keys für den Bunker. Richtlinien definieren, wer wann signieren darf (z.B. nur Dienstaccounts, nur bestimmte Kinds, nur bestimmte Relays).
Effekt im Dreieck: Sicherheit und Compliance sehr hoch, Datensouveränität eher organisationsbezogen als individuell. UX je nach UI: für Redakteur:innen kann es noch recht smooth sein, aber spontane Privatnutzung ist eingeschränkt.

Ausgewogen (Balanced)

Architektur: Kombination, z.B.: Keycloak für komfortablen Login, NSEC im Bunker mit guter UI, einfache Ex-/Import-Funktionen für Schlüssel, klare Info-Texte („Wo liegt mein Schlüssel?").
Effekt im Dreieck: Kein Extrem: genug Komfort für Alltag, genug Sicherheit/Datensouveränität für Bildungs-Infrastruktur, ohne Nutzer:innen mit Kryptodetails zu erschlagen.