Man, I was gonna post something really snarky about this... But I decided to be a bit civil this morning.

Would it make sense to adjust the limits on per kind bases?

sure - that's fine. Kind 1059 is really the only one that needs a higher limit.

I choose optimism and action.

Poor design. Move blob data outside of the event

Khatru's (and therefore Haven's) defaults to 512kb btw.

I see a fork coming.... /s

this is not a fork. it's already in the NIPs. the past limit was NIP-44, but that limit was raised months ago in the NIPs repo. this is just relay implementations not being updated or configured for higher limits.

great - that'll get us to a few hundred people in a group.

how's the view of the game from that armchair, QB?

The current payload size limit is one of the main inhibitors of Nostr’s growth. Try updating a follow list with 900 pubkeys on it using a remote signer.

It's pretty great, especially since other messaging protocols work just fine with that limit. That's a you problem. 🤣

Feature, not bug. (IMO.)

1MByte or 1Mbit?

People about the trauma dump the blocksize war on this note lol

Take a look at Feedsync as a nostr relay server designed for this use case. Pixie uses it for messaging and file sharing. Ordered feeds so messages don’t get lost.; Clients backfill server inventory (and later send P2P, WebRTC). Traditional nostr relays aren’t a good fit for messaging.

Codeberg.org

feedsync-server

FeedSync is a lightweight way to ship **ordered updates** between devices/users without building your own sync engine. Think append-only feeds &#43...

lol 😂

disagree. nostr relays work great once you get past the broken ones.

Relay op here, are we talking 1mb per message or is this the projected size of the events forming the group?

Can confirm, they work fine for message transport

total event size. this only for welcome messages that invite people into the group (which are gift-wraps - kind 1059). most group messages are kind:445 and are tiny.

it's an easy fix too. 🤷‍♂️ my relay implementation Wok has higher default limits. Khatru, Haven, and others also default higher than 64kb now. It's basically just a historic holdover.

that over 1KB per user. I'm curious what causes this number to be that large? encryption overhead?

no - a 200 person group has a welcome message of about 300kb. the MLS welcome object itself is only about 100kb but then we nip-44 encrypt and base64 it, so it gets bigger. I just think 1MB+ is a better size limit is all.

I know concord ran into the same issue and switched to a sharded system to bypass the limit. @Vitor Pamplona its been a month now are you finally going to bring amethyst in line with that now? We keep having to tell people not to use amethyst for concord because of this. Would be nice if it was actually compatible again.

NostrCrash 😂

It wasn’t the transport happy path that we had issues with. How does a nostr relay identify that a message is missing and restore it? Traditional nostr relays have no concept of missing messages. You can negantropy gaps but without knowing the full missing set. That prevents the system from finding and restoring full gaps. I suspect that this issue will show up in system resilience. Clients may get out of missing messages and key material. To compensate, you can move the feed protocol to the clients instead of the server, but then that might reduce DX for new integrations. Anyway, that’s what motivated our new relay for messaging: Move primary inventory to clients from the server (expect the server to drop messages). Use server as hot cache only. Backfill gaps from clients to each other. If it’s useful for you, feel free to use.

Because of what? Event size? We don't operate relays. I am confused..

The concord spec changed a month ago to deal with those limitations. So the communities you join are now sharded on armada and vector. At the time you did not want to update amethyst. Now that means pretty frequently people wonder why their communities from Armada do not sync correctly. And we have to explain its because Amethyst never updated itself to the newer spec. So amethyst not only doesn't get the proper channel sync, it also is subject to the limitation issues that change solved to begin with. Once you implement the sharding kínd 33302 instead of sticking to 13302 you are in line with the spec again so people dont miss channels and dont risk issues with their community list.

GitHub

CORD-02 §8: shard the Community List, and shrink what it carries · concord-protocol/concord@759448a

A real 43-membership List serialized to 50,113 B and encoded to a 76,868 B event, past the ~64KB most relays accept. §8's guard measured NIP-4...

But that was just for community lists, right? Are people having more than 64KB of community headers already? That sounds crazy. What do you do in messages that are bigger than 64kb?

Some people indeed hit community lists that big which was why they did the sharded one. Point remains that even if you dont find it neccesary you being behind on the spec still causes issues. I don't know what armada does when it encounters a changed 13302. But it doesnt actively update its 13302 anymore so amethyst is left out on any community list updates.

That the same issue for follow lists and people lists in nostr.. I will implement the sharing, but to me that doesn't solve anything since messages cannot be big. I have seen more people losing messages than losing lists, by far.

Which other clients are active these days that I can test with?

already started.

Nostr Hard Fork Incoming!

Jokes aside: that sounds like a problem that should be solved at the protocol level 🪄

:orange:STIR N FRY IT HARDER 🤣

what if bunch relay admin decides to STICK old branch never upgrade relay or app we can still keep our gossip without black /white or grey noise

it is solved at the protocol level. in june, the limit on events for nip-44 was raised to 4GB minus 1 byte. it's just that most relay implementations & operators haven't updated their config yet.

Block size is non-negotiable bra

Just make the limit for all events 4GB minus 1 byte. I'm sure relay operators paying network out fees will be accepting of that change.

"Relays are lightweight WebSocket servers designed to index and serve small JSON objects." "NIP-44 payloads are Base64 encoded. Encoding binary data to Base64 introduces a ~33% size inflation penalty right out of the gate." "Nostr clients process events in memory. Parsing, base64-decoding, and running ChaCha20/HMAC over a 500 MB event payload will crash mobile apps and browser tabs with Out-Of-Memory (OOM) errors." "If a 1 GB event download drops at 99%, you have to fetch the entire WebSocket message again from scratch." "Wanting 4GB events directly over Nostr relays treats a WebSocket message bus like an HTTP storage server. Using Blossom for files and NIP-44 for small text/keys is the correct, architecturally sound design for Nostr." a lot of other arguments might over that request. Why not consider to do that? "Just as with media, large Welcome objects can be stored out-of-band: 1- The admin encrypts the 300 KB MLS Welcome object and uploads it to an HTTP blob server (Blossom). 2- The Nostr kind: 444 Welcome event sent over the relay contains only the URL + SHA-256 hash of the blob (a tiny ~500 byte event). 3- The recipient fetches the blob over standard HTTP range/stream requests and decrypts it locally." "

Yeah, nah. Don't use lists for this. HTH

is there really group ~60 in nostr? Can I see it? I'm just curious...