NIP-39 definiert, wie Nutzer externe Identitätsansprüche mit i-Tags an ihre Nostr-Profile anhängen. Diese Tags verknüpfen einen Nostr-pubkey mit Accounts auf externen Plattformen wie GitHub, Twitter, Mastodon oder Telegram.

Wie es funktioniert

Nutzer veröffentlichen Identitätsansprüche in kind 10011 Events als i-Tags. Jedes Tag enthält einen Wert im Format platform:identity plus einen Proof-Pointer, mit dem ein Client den Anspruch verifizieren kann:

{
  "kind": 10011,
  "tags": [
    ["i", "github:username", "gist-id"],
    ["i", "twitter:handle", "tweet-id"]
  ]
}

Clients rekonstruieren die Proof-URL aus Plattform und Proof-Wert und prüfen dann, ob der externe Post das npub des Nutzers enthält. Dadurch bleibt der Anspruch client-übertragbar, ohne einen zentralen Verifizierer zu brauchen.

Proof-Modell

Der wichtige Punkt ist, dass NIP-39 gleichzeitig die Kontrolle über zwei Identitäten belegt: den Nostr-Key und den externen Account. Wenn eine Seite dieses Belegs wegfällt, wird die Verifizierung schwächer. Ein gelöschter gist oder Tweet macht das historische Event nicht ungültig, entfernt aber den Live-Proof, auf den die meisten Clients angewiesen sind.

Ein weiterer wichtiger Implementierungspunkt ist die Fetch-Strategie. Da diese Ansprüche jetzt außerhalb von kind 0 leben, können Clients selbst entscheiden, ob sie sie nur in der Profildetailansicht, nur für gefolgte Nutzer oder gar nicht anfordern. Das vermeidet zusätzliches Gewicht auf dem ohnehin stark genutzten kind-0-Pfad.

Aktueller Status

Nach der aktuellen Spezifikation liegen Identitätsansprüche in dedizierten kind 10011 Events statt in kind-0-Metadaten. Diese Trennung entstand aus dem breiteren Versuch, kind-0-Profilabrufe schlanker zu machen.

Primärquellen:

Erwähnt in:

Siehe auch: