feat: raise note content limit from 300 to 4000 characters#252
Open
leon-wbr wants to merge 1 commit into
Open
Conversation
The 300 char cap was a Nostroots invention, not a protocol constraint: NIP-01 defines no content limit, and relay.trustroots.org's NIP-11 document advertises no max_content_length (its only ceiling is max_message_length, 131072 bytes for the entire JSON message). It was truncating legitimate notes. Keep a bound so nr-server retains an upper limit on what it will accept and repost, and surface the remaining count in AddNoteForm so the cap is visible instead of failing silently at publish time. DEPLOY ORDER: nr-server validates against this same schema, so it must be redeployed before clients ship, or long notes will validate in-app and then be dropped server-side and never reposted as kind 30398. Closes #249
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Closes #249
CONTENT_MAXIMUM_LENGTHlives innr-common/constants.tsand is enforced bycontentSchema, which nr-server also uses to decide whether to repost a kind 30397 as a verified kind 30398.If clients ship this before nr-server is redeployed, a long note will validate happily in the app, publish to the relay, and then be silently dropped server-side — never reposted, so it never appears on the Trustroots layer. The user watches their note vanish with no error.
Deploy nr-server first, then the clients.
Why 4000, and why a limit at all
There is no protocol limit to honour here — I checked:
relay.trustroots.org's own NIP-11 document advertises nomax_content_length. Its only ceiling ismax_message_length= 131072 bytes, for the entire JSON message.So the 300 was a Nostroots invention, not a protocol constraint, and it was truncating legitimate notes (see the squat/bridge listing in the issue).
I kept a bound rather than removing it outright, purely so nr-server retains an upper limit on what it will accept and repost — an unbounded content field on the relay is an abuse vector. 4000 is ~2% of the relay's real ceiling and generous for the use case in the issue.
Removing the bound entirely is also defensible — that's literally what the issue title asks for. I didn't do it unilaterally because it's a judgement call about relay abuse. Happy to change it.
Also
AddNoteFormhad nomaxLengthand no counter, so exceeding the cap failed silently at publish time. It now caps the input and shows a remaining-character count as you approach the limit.Tests
nr-common:deno task test— 9 passing, 4 new (content at/above/below the bound, and well past the old 300).nr-app:pnpm test— 85 passing.