NIP-A3 fügt dem NIP-Repository payto: Zahlungsziele hinzu

Das Event

NIP-A3 definiert kind:10133 und markiert es als ersetzbar. Das ergibt sich aus NIP-01, wonach jedes Kind n mit 10000 <= n < 20000 ersetzbar ist: Für jede Kombination aus Pubkey und Kind muss ein Relay nur das jüngste Event speichern und darf ältere Fassungen verwerfen. Eine Nutzerin oder ein Nutzer hat somit jeweils nur eine Liste von Zahlungszielen, und eine neue Veröffentlichung löst die vorherige ab.

Das Feld content bleibt leer. Alles steckt in den Tags:

["payto", "<type>", "<authority>", "<optional_extra_1>", "<optional_extra_2>", ...]

Das erste Element ist die wörtliche Zeichenkette payto. Das zweite ist der Zahlungstyp, etwa bitcoin oder lightning. Das dritte ist die Autorität, eine Adresse oder ein Benutzername, dessen Format vom Zahlungssystem abhängt. Alles Weitere ist für künftige Funktionen aus RFC-8905 reserviert.

Die Regel zur Vorwärtskompatibilität steht ausdrücklich da: Clients müssen die Elemente 0 bis 2 verstehen und dürfen alle zusätzlichen Elemente ignorieren.

Validierung

type ist auf Kleinbuchstaben, Ziffern und Bindestriche beschränkt. Typen unterscheiden nicht zwischen Groß- und Kleinschreibung, und die Spezifikation verlangt eine Normalisierung auf Kleinbuchstaben. authority muss URL-sicher sein, Sonderzeichen sind zu kodieren. Darüber hinaus dürfen Clients für die von ihnen erkannten Typen eine zahlungssystemspezifische Prüfung vornehmen.

Auf der Schreibseite weist die Spezifikation Clients an, auch unbekannte Typen anzunehmen. Schritt 3 ihrer Implementierungsliste sagt, der Client dürfe bei einem nicht erkannten Typ warnen, das Absenden aber dennoch zulassen. Das Beispiel-Event der Spezifikation trägt neben bitcoin und nano ein Tag mit dem Typ unknowntype.

Darstellung

Für jedes payto-Tag sollte ein Client die URI payto://<type>/<authority> zusammensetzen und als Schaltfläche oder Link anzeigen. Genau diese URI-Form ist der Zweck des NIP. RFC-8905 standardisiert payto: bereits als URI-Schema für den Aufruf von Zahlungszielen, NIP-A3 erfindet also kein neues; es liefert die Bausteine, aus denen sich eines zusammensetzen lässt.

Erkannte Typen werden mit Symbol und Stilisierung dargestellt. NIP-A3 bringt eine Tabelle mit acht empfohlenen Typen mit, jeweils mit langem Namen, kurzem Namen, Zeichen und einem Verweis auf das Markenmaterial des jeweiligen Zahlungssystems. Die acht sind bitcoin, cashme für Cash App, ethereum, lightning, monero, nano, revolut und venmo.

Nicht erkannte Typen werden entweder ignoriert oder generisch dargestellt, nach Wahl des Clients. Führt ein Profil mehrere Ziele, darf ein Client das erste anzeigen, alle anzeigen oder eine Auswahlliste anbieten. Die Spezifikation legt sich nicht fest.

Verhältnis zu Zaps

Die Implementierungshinweise behandeln die Überschneidung mit NIP-57. Für Lightning-Zahlungen gibt es in nostr bereits einen Weg: das Feld lud16 in den Profil-Metadaten vom Kind 0, dekodiert als lnurl-Zahlungsanfrage. NIP-A3 sagt, Clients dürften ein payto-Tag vom Typ lightning als Alternative zu lud16 oder als Ergänzung verwenden, mit einer Lightning-Adresse oder einer LNURL im Autoritätsfeld.

Das ausgearbeitete Beispiel zeigt beides zusammen: ein Kind-0-Event mit lud16 und ein Kind-10133-Event mit einem lightning-Ziel derselben Adresse sowie einem bitcoin-Ziel. Keines ersetzt das andere. Nichts im Diff erklärt lud16 für veraltet oder ändert NIP-57.

Für Implementierende

Relays brauchen nichts Neues. Kind 10133 liegt in dem ersetzbaren Bereich, den sie ohnehin behandeln, und payto ist ein gewöhnliches Tag.

Für Clients ist die Leseseite klein: Kind 10133 für die auf dem Bildschirm sichtbaren Pubkeys abonnieren, die Tags auswerten, die URIs bauen, das Ergebnis anzeigen. Die Schreibseite braucht ein Formular mit einem Typfeld und einem Autoritätsfeld, die beiden obigen Validierungsregeln und eine ersetzbare Veröffentlichung.

NIP-A3 ist als optional markiert und trägt eine Zeile author:atxmj. Eine draft-Markierung hat es nicht. Nichts zwingt einen Client zur Umsetzung, was die NIP-README über die Liste insgesamt sagt.