NIP-19 erhält eine Grenze

Warum eine Längenbegrenzung

Die TLV-Entitäten von NIP-19 sind konzeptionell offen. Ein nprofile oder nevent kann eine beliebige Anzahl von TLV-Elementen enthalten, einschließlich mehrerer Relay-Hinweise, sodass die frühere Spezifikation nichts darüber aussagte, wie groß ein solcher String werden konnte, bevor ein Decoder das Parsen abbrechen sollte. Die Spezifikation wies Decoder bereits an, nicht erkannte TLV-Typen zu ignorieren, statt einen Fehler auszulösen. In Kombination mit einer fehlenden Obergrenze für die Länge musste ein Decoder darauf vorbereitet sein, einen beliebig langen String zu durchlaufen, nur um festzustellen, dass er den größten Teil davon ignorieren sollte.

Eine empfohlene Obergrenze gibt Implementierern eine konkrete Zahl, die sie vor jeglicher Parsing-Arbeit prüfen können. Ein Decoder, der einen String mit mehr als 5000 Zeichen sieht, kann ihn sofort ablehnen, statt Zeit und Speicher damit zu verbringen, TLV-Datensätze zu durchlaufen, die theoretisch endlos weitergehen könnten. Das ist ein Standard-Abwehrmuster für jedes Format, das Eingaben variabler Länge akzeptiert, die von einem Angreifer beeinflusst werden können: die Eingabegröße begrenzen, bevor man etwas Aufwändiges damit tut.

Was sich nicht ändert

Die Grenze ist ein SOLLTE, kein MUSS, und rührt nicht an der Kodierung selbst. npub, nsec, note, nprofile, nevent und naddr behalten dieselbe bech32-Struktur und dasselbe TLV-Layout für die Entitäten, die es verwenden. An der Erzeugung oder Dekodierung bestehender kurzer Entitäten wie eines einfachen npub ändert sich nichts, da diese im normalen Gebrauch ohnehin weit unter der neuen Obergrenze liegen. Die Zeile betrifft nur die wenigen Fälle, in denen eine Entität, typischerweise ein mit mehreren Relay-Hinweisen bepackter nprofile oder nevent, sonst keine definierte Obergrenze hätte.

Das größere Bild

NIP-19-Strings sind dafür gedacht, in Chats eingefügt, in Links eingebettet und als QR-Codes kodiert zu werden, Kontexte, in denen ein unbegrenzter String ein praktisches Problem darstellt, nicht nur eine Unannehmlichkeit beim Parsen. Ein QR-Code hat physische Größengrenzen, und ein Client, der einen beliebig langen String rendert, verrichtet unbegrenzte Arbeit als Reaktion auf nicht authentifizierte Benutzereingaben. Eine Empfehlung von 5000 Zeichen gibt jeder Implementierung dieselbe Zahl, um die herum sie entwerfen kann, statt jeden Client raten zu lassen, wo eine sichere Grenze liegt.

Es handelt sich um eine einzeilige Änderung an einem NIP, das bereits mehrere solcher Hinweise enthält. NIP-19 weist Decoder außerdem an, nicht erkannte TLV-Typen zu ignorieren, und beschränkt die Verwendung von npub und nsec auf Anzeige und Kopieren, sodass sie aus NIP-01-Events und NIP-05-Antworten herausgehalten werden. Jeder dieser Hinweise beseitigt eine Stelle, an der eine Implementierung sonst von einer Eingabe überrascht werden könnte, auf die sie nicht vorbereitet war. Eine Größenbegrenzung ist dieselbe Idee, angewendet auf den gesamten String statt auf einen einzelnen Teil seines Inhalts.

Nichts davon ändert, wie ein typischer, gültiger npub, nprofile, nevent oder naddr aussieht. Ein gewöhnlicher Schlüssel oder Event-Verweis, selbst mit ein paar Relay-Hinweisen, kommt höchstens auf einige hundert Zeichen. Die 5000-Zeichen-Zeile ist eine Absicherung für die Fälle außerhalb dieses Bereichs, keine Änderung daran, wie diese Entitäten normalerweise aufgebaut oder gelesen werden.