NIP-19 gains a limit

Why a length limit

NIP-19's TLV entities are open-ended by design. An nprofile or nevent can carry an arbitrary number of TLV items, including multiple relay hints, so nothing in the earlier spec said how large one of these strings could get before a decoder should stop trying to parse it. The spec already told decoders to ignore unrecognized TLV types rather than error out. Combined with no upper bound on length, a decoder had to be prepared to walk an arbitrarily long string just to find out it should ignore most of it.

Setting a recommended ceiling gives implementers a concrete number to check before doing any parsing work. A decoder that sees a string longer than 5000 characters can reject it immediately, rather than spend time and memory walking through TLV records that may go on indefinitely. That is a standard defensive pattern for any format that accepts variable-length, attacker-influenceable input: bound the input size before doing anything expensive with it.

What it does not change

The limit is a SHOULD, not a MUST, and it does not touch the encoding itself. npub, nsec, note, nprofile, nevent, and naddr all keep the same bech32 structure and the same TLV layout for the entities that use it. Nothing about how existing short entities, like a bare npub, are produced or decoded changes, since those already sit well under the new ceiling in normal use. The line only affects the small number of cases where an entity, typically an nprofile or nevent packed with several relay hints, would otherwise have no defined upper bound.

The bigger picture

NIP-19 strings are meant to be pasted into chat, embedded in links, and encoded into QR codes, contexts where an unbounded string is a practical liability, not just a parsing inconvenience. A QR code has physical size limits, and a client rendering an arbitrarily long string is doing unbounded work in response to unauthenticated user input. A 5000 character recommendation gives every implementation the same number to design around, rather than leaving each client to guess where a safe cutoff is.

This is a one-line change to a NIP that already carries several such notes. NIP-19 also tells decoders to ignore TLV types they do not recognize, and it restricts npub and nsec to display and copy-paste use, keeping them out of NIP-01 events and NIP-05 responses. Each of these notes trims a place where an implementation could otherwise be surprised by input it was not built to expect. A size limit is the same idea applied to the string as a whole rather than to one part of its contents.

None of this changes what a valid, ordinary npub, nprofile, nevent, or naddr looks like. A typical key or event reference, even one carrying a couple of relay hints, runs to a few hundred characters at most. The 5000 character line is a backstop for the cases outside that range, not a change to how these entities are normally built or read.