NIP-02 gibt Petnames auflösbare Pfade

Jede Pfadkomponente folgt der Liste einer Person

Der zusammengeführte NIP-02-Text definiert die Auflösung Schritt für Schritt. Ordnet die Liste des Benutzers erin einem Schlüssel zu und Erins Liste charlie einem anderen, kann ein Client ~/erin/charlie auflösen: zuerst erin lokal suchen, Erins neuestes kind-3-Event laden und darin charlie nachschlagen.

Der frühere Text zeigte abgeleitete Namen wie frank.david.erin, legte aber weder eine Pfadgrammatik noch einen Suchablauf fest. Die neue Fassung folgt der tatsächlichen Richtung: an einer Wurzel beginnen, den ersten Namen finden und für den nächsten die Liste dieses Profils verwenden.

Die Form ~ verwendet den angemeldeten Benutzer als relative Wurzel. NIP-02 nennt auch zwei absolute Wurzeln, wenn niemand angemeldet oder der aktuelle Kontext nicht passend ist:

~npub1.../erin/charlie
[email protected]/erin/charlie

Die Beispiele zeigen, wessen Namenskontext den Pfad eröffnet. Sie schaffen kein globales Register. Jede weitere Komponente hängt vom Petname in der Liste des vorherigen Profils ab.

Ein lesbarer Pfad ist kein Vertrauensbeweis

Petname-Pfade können sozialen Kontext zeigen, ohne einer einzigen Stelle die Vergabe aller Namen zu überlassen. In einer Web-of-Trust-Oberfläche kann ~/erin/charlie aussagekräftiger sein als ein nackter Schlüssel, weil der Pfad erklärt, wie der Benutzer Charlie über Erin erreicht.

Das ist kein kryptografischer Identitätsbeweis. Ein kind-3-Event ist signiert, sodass ein Client den Herausgeber jeder Zuordnung prüfen kann. Dieser Autor kann dennoch einen irreführenden Petname wählen, ihn ändern oder auf einen anderen Schlüssel zeigen lassen. NIP-02 sagt außerdem, dass eine neue Follow-Liste die vorige ersetzt. Der Resolver benötigt daher bei jedem Schritt das neueste gültige Event.

Auch Verfügbarkeit begrenzt die Auflösung. Ein langer Pfad kann mehrere bei Relays gespeicherte Follow-Listen erfordern. Ein fehlendes oder veraltetes Event stoppt die Suche, selbst wenn die Schlüssel gültig bleiben. Clients sollten den aufgelösten Schlüssel, die Wurzel und einen fehlgeschlagenen Schritt anzeigen, statt den lesbaren Pfad als unbestreitbaren Kontonamen darzustellen.

Parsing-Details bleiben offen

Der Merge ändert eine Datei, fügt zehn Zeilen hinzu und entfernt zwanzig. Relative und absolute Beispiele sind definiert, aber keine Escape-Regeln für Petnames mit /, Leerzeichen oder anderen Sonderzeichen. Diese Fälle wurden nach dem Merge in Kommentaren angesprochen. Der aktuelle NIP beantwortet sie noch nicht.

Der Pull Request belegt auch keine veröffentlichte Implementierung. Die Änderung erläutert die Spezifikation, beweist aber nicht, dass ein bestimmter Client die neue Notation bereits eingeben, anzeigen oder auflösen kann. Interoperabilität erfordert gemeinsame Parsing-Regeln und eine verständliche Anzeige unvollständiger Pfade.

Die Grenze ist damit klar: NIP-02 beschreibt eine Kette lokal zugewiesener Namen. Es macht daraus keine global eindeutigen Kennungen, ersetzt nicht die Prüfung öffentlicher Schlüssel und liefert keinen Vertrauenswert.