Nostr Web Client

The problem I ran into has to deal with the maximum size of an encrypted message as defined in the NIP-44 spec: "The largest value a 16-bit unsigned integer can hold is 65,535. This directly dictates the maximum size of the plaintext that can be indicated in the length field."

I have a large follow count, around 3000npubs, and I am unable to make edits to my follow list when signed in via nsec.app on any client. Since the entire purpose of Plebs vs. Zombies is to edit large follow lists, this causes a bit of a problem.

Because of this, I'm forced to remove the NIP-46 feature for the time being, as it is basically incompatible with my app. If anyone can propose a solution to fix it, I'm open to revisiting it later.

Thanks for encouraging me to try this, I definitely learned some things!

Anthony Accioly 3mo ago

Thanks for your efforts, Daniel. I didn’t know about the 64 KB limitation myself.

nostr:nprofile1qqsyvrp9u6p0mfur9dfdru3d853tx9mdjuhkphxuxgfwmryja7zsvhqpzamhxue69uhhv6t5daezumn0wd68yvfwvdhk6tcpz9mhxue69uhkummnw3ezuamfdejj7qgswaehxw309ahx7um5wghx6mmd9u2mk7fe, nostr:nprofile1qqs8evfumcr8pevs7qkta84qlnc7qhkmchxg5syhx8a9gdjyqxqu78gppemhxue69uhkummn9ekx7mp0dpmzxy, apologies for bothering you. Is the 65,535-byte plaintext padding limitation described here a hard limit for what can be encrypted with NIP-44, or should NIP-44 be breaking down plaintext into 64 KB blocks and only applying padding to the last one?

"Validate plaintext length. Minimum is 1 byte, maximum is 65535 bytes"

https://github.com/nostr-protocol/nips/blob/e35a1bebbc7a5e10970d2dbc9d07a88ee876bfbf/44.md?plain=1#L87

If it’s the former, we shouldn’t be using NIP-44 encryption for the lists/sets in NIP-51. If it’s the latter, then this looks like a bug.

Reply to this note

Please Login to reply.

Discussion

Anthony Accioly 3mo ago

Also CC nostr:nprofile1qqst6jhruelzn9jdf9qhyfsac3fetjyld0fwwary9cmxzfchrhacragpz4mhxue69uhhyetvv9ujuerpd46hxtnfduhsz9thwden5te0dfjkcmreve5hx6pwd3skuep0qy88wumn8ghj7mn0wvhxcmmv9uy25sd9 due to nsec.app / Bunklay ( nostr:nprofile1qqswum4p82uluhz2dr40nvdrflspffntgqghc58w9fs57nx6jkdkuaqpz4mhxue69uhhyetvv9ujuerpd46hxtnfduhszythwden5te0dehhxarj9ekxzmny9uq3zamnwvaz7tmwdaehgu3wwa5kuef0nwfqpd, have you tested signing with any combos of Signer / Relay other than Amber + nsec.app).

Vitor Pamplona 3mo ago

Keep in mind most relays have a max limit for 65000 bytes too. That's where the number comes from. Anything over that amount, encrypted or not, doesn't get saved in any relay.

Large follow lists will never work on nostr. It's better to have a new event kind for each follow.

Anthony Accioly 3mo ago

Sir, "Most relays" ≠ "all relays". 64KB Max for a JSON payload is too small for 2025 standards. Plenty of folks have large lists on Nostr (and not only follow lists). "This isn’t a bug, it’s a feature" isn’t a great answer to this one if we want Nostr to grow. I had over 3k connections myself on most social media networks other than Nostr and Fedi, and I'm no social butterfly. We need a proper encryption scheme for payloads over 64 KB, assuming NIP-44 can’t already handle this.

Vitor Pamplona 3mo ago

65000 was strfrys default for many years. Now it is 135k, which is still small. Because it is the most popular impl, it's everywhere. Either way, each relay has a number. Nostr will likely never store large Jsons. That's why people made blossom for.

Henky!! 3mo ago

I tried setting up strfry this week and it was still 64kb.

Vitor Pamplona 3mo ago

Maybe the PR was merged but no new release yet? Idk..

Anthony Accioly 3mo ago

Sir, I respectfully but strongly disagree here. Contrary to popular belief, strfry, and even strfry + nostream, as great as they are, still ≠ “all relays on Nostr.” I get that Nostr is an event-driven protocol and we want to keep events small, but honestly, 65 KB and even 135 KB are BS limits in terms of social media scalability. That would require us to reinvent not only NIP-51 but a bunch of other kinds as well.

For example, 135 KB for a long-term content blog post is really not great. One way or another, I don’t see why a relay limitation should dictate the encryption mechanism. And as far as I can tell, there isn’t a strong reason preventing NIP-44 from working with bigger payloads, is there? (Not a rhetorical question, I genuinely don’t know if this is a limitation relating to padding of the very last block or if there’s something in NIP-44 that prevents it from operating in block cipher mode).

Vitor Pamplona 3mo ago

But what are you going to do about it? You will have to individually convince every relay operator to accept it. Many think large Jsons are just spamming the network (similar to how knots people feel).

I tried to convince them for 2 years. Nothing changed.

Anthony Accioly 3mo ago

Relay dev and small scale operator here Sir. I'll keep doing my thing and other relay devs can keep doing theirs. My only ask here is to make sure that NIP-44 can work in block mode for the folks that actually don't want to be constraint by unwritten limitations.

Vitor Pamplona 3mo ago

Fiatjaf has a change to nip44 to do this, but nobody has coded it yet. https://github.com/nostr-protocol/nips/pull/1907

Anthony Accioly 3mo ago

If it's on Khatru then it has already been adopted by several relays :).

Anthony Accioly 3mo ago

nostr:nprofile1qqsrhuxx8l9ex335q7he0f09aej04zpazpl0ne2cgukyawd24mayt8gprfmhxue69uhhq7tjv9kkjepwve5kzar2v9nzucm0d5hszxmhwden5te0wfjkccte9emk2um5v4exucn5vvhxxmmd9us2xuyp, is this on go-nostr and Khatru "v1" or only on nostrlib for now?

Anthony Accioly 3mo ago

Unfortunately not on go-nostr yet. https://github.com/nbd-wtf/go-nostr/blob/master/nip44/nip44.go#L68-L70, but assuming that folks don't backport this, it is just a mater of time until Khatru relays migrate to nostrlib. So, what, at least 10% of relays out there will work fine.

semisol 3mo ago

relays don't care about it

Anthony Accioly 3mo ago

Ah, true, brainfart on my side. Nostrlib basically merged client and relay side libraries anyway. But yes, so as long as clients adopt this and relays don't limit events to 65 KB everything should work.

semisol 3mo ago

One of the goals of NFDB is to accomodate large events and follow lists. 65 KB is nothing.

Vitor Pamplona 3mo ago

So, can I now store media in it? Nip 95 is still a thing on Amethyst.

semisol 3mo ago

No, it is not allowed by ToS and any media containing events will be rejected.

Vitor Pamplona 3mo ago

But you do take large encrypted blobs?

semisol 3mo ago

Depends on the kind, if you are a paying user or not, what service, and certain filters.

AUTH will soon be required for writes of non-paying events for a bunch of services to prevent spam & a user-trust filter based on pubkey.

Danny, the cyber guy 3mo ago

Please don't store 64KB of JSON. Your CPU will hate you.

We really should move to binary formats for everything. I already do it for nostr:nprofile1qqszzzhxu56wgr756qg30c5c2wgfkjy0chyvlrf2qtt2d4s9y2c88tcpz4mhxue69uhhyetvv9ujuerpd46hxtnfduhszxthwden5te0wajkccm0d4jjumn0wd68ytnhd9hx2tcppemhxue69uhkummn9ekx7mp0jtyu5f it's not that hard.

Anthony Accioly 3mo ago

I don't disagree here. And we can have multiple on-wire formats (storage format is an implementation detail). Still, not something that will be widely adopted in the short-term (which doesn't mean we shouldn't adopt it at all).

کیهان 3mo ago

Bunklay won't apply any limitations on event size. Only time window and kind number. This limitations should come from client libraries implementing NIP-44 probably.

semisol 3mo ago

NIP-04 weaknesses have also been greatly exaggerated and feel like an intentional attempt to force through their own encryption scheme.

It was sold on the premise that "NIP-04 could leak your private keys" while that would require an uncountable rounds of user interaction, a key-recovery attack on AES and getting the user to sign events with *modified versions of their nsecs*.

Vitor Pamplona 3mo ago

Every cryptographer that I showed the nip04 spec thought it was a joke, because it was so bad in so many angles.

semisol 3mo ago

It is a joke, the primary concern being that an AES key should only be reused for so long.

But the rush to replace it, while the author is fearmongering people with attacks that are infeasible, with issues like message size in the spec and unnecessary complexity like MACs *when the data is already signed* is simply nonsense.

Vitor Pamplona 3mo ago

Rush? It took two full years to to the change. And nostr:nprofile1qqs8evfumcr8pevs7qkta84qlnc7qhkmchxg5syhx8a9gdjyqxqu78gppemhxue69uhkummn9ekx7mp0dpmzxy was the only one to actually provide any alternative. No one else did anything.