Sending a single [BATCH, ...a million events] message would be no different than sending a million [EVENT] message. No optimizations possible. You would at best save 7 bytes.
Hello #nostrdev s, I think nostr network should has methods for recovering events.
For now, the only way to send event to relay is ["EVENT", {eventdata}]. But this method only can send one event. If i want to backup and recover. I need to send many events to relay, so i need to send many times EVENT message whick usually notice me that i need to slow down. Is there a method for client to send many event to relay by one times?
nostr:npub1gcxzte5zlkncx26j68ez60fzkvtkm9e0vrwdcvsjakxf9mu9qewqlfnj5z nostr:npub1acg6thl5psv62405rljzkj8spesceyfz2c32udakc2ak0dmvfeyse9p35c nostr:npub180cvv07tjdrrgpa0j7j7tmnyl2yr6yr7l8j4s3evf6u64th6gkwsyjh6w6
Discussion
With that said, some relays support Negentropy and that could be a better way to sync big amounts of events: https://github.com/hoytech/negentropy
These two methods are not different from network. The BATCH way can help relays handle events batchly. With the BATCH method, a relay handle hundreds events only need two sql:
select * from event where id in (?, ?, ?, ?).
and the batch insert sql:
insert into event (xxx, xxx) values (?, ?), (?, ?), (?, ?), (?, ?).
If send the event one by one, the relay at lease send hundreds insert sql.
Usually, the batch insert sql is faster the one by one insert sql.
You can fix that on the relay side by just having a small debounced call that accumulates a bunch of received [EVENT, {...}] into a single SQL statement.
This is nicer and much easier than trying to get everybody to implement a new verb.
The debounced way is also ok. But the NIP would be better to state that relay can implement this method and this method is optional.
But the batch way is also optional and need to stated. And it is a way easier to implement.
These two method also can handle hundreds events. I can't find that whick one is better.