Thatās how weekend projects evolve š . Another āungratefulā DevOps-y task would be setting up something like Renovate to keep dependencies up to date, maybe adding linting and scanning as well. One commit at a time, of course :).
Given the attention your app has received, some folks may volunteer to give you a hand. This is how Nostr wins ;)
NEED BRAAIIIINNNNSSSSS!!!! š§āāš§
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!
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"
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.
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).
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.
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.
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.
I tried setting up strfry this week and it was still 64kb.
Maybe the PR was merged but no new release yet? Idk..
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).
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.
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.
Fiatjaf has a change to nip44 to do this, but nobody has coded it yet. https://github.com/nostr-protocol/nips/pull/1907
If it's on Khatru then it has already been adopted by several relays :).
nostr:nprofile1qqsrhuxx8l9ex335q7he0f09aej04zpazpl0ne2cgukyawd24mayt8gprfmhxue69uhhq7tjv9kkjepwve5kzar2v9nzucm0d5hszxmhwden5te0wfjkccte9emk2um5v4exucn5vvhxxmmd9us2xuyp, is this on go-nostr and Khatru "v1" or only on nostrlib for now?
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.
One of the goals of NFDB is to accomodate large events and follow lists. 65 KB is nothing.
So, can I now store media in it? Nip 95 is still a thing on Amethyst.
No, it is not allowed by ToS and any media containing events will be rejected.
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.
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).
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.
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*.
Every cryptographer that I showed the nip04 spec thought it was a joke, because it was so bad in so many angles.
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.
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.
