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).
