mleku on Nostr: funny enough, the idea of adding a batch save event function to the realy eventstore ...
funny enough, the idea of adding a batch save event function to the realy eventstore interface was something i have thought about repeatedly when implementing import
i already have an import function that you pump with a .jsonl (line structured JSON) file, like the kind that many clients have for import or exporting events, but because of thet need for auth it currently is only exposed on localhost by default
i didn't know there was a batch event message type in the protocol... no, there isn't
if auth is required or not makes no material difference, the client can simply stream them out, the "ok" replies don't have to be received before another can be pushed, it would just be used by the client to know if an event failed to be saved by the relay for some reason... there also may be rate limiting issues in this, that may or may not be documented in the nip-11
if you control the relay, and it has an admin http listener like #realy does, you can just dump the events up to it that way, it has no rate limiting and doesn't require to receive acks at all, but it also doesn't tell you on the wire whether the events were accepted
there could be a bundling extension on the EVENT message type that lets you string multiple event objects comma separated in one go, or you can just write an uploader that works with the normal event/ok cycle to make sure it all goes up, it may be a little slower but probably won't be a big deal most of the time, i mean, 2 minutes versus 10 minutes is not gonna kill you probably, especially considering you can parallelise these uploads or do something else in the meantime
i already have an import function that you pump with a .jsonl (line structured JSON) file, like the kind that many clients have for import or exporting events, but because of thet need for auth it currently is only exposed on localhost by default
i didn't know there was a batch event message type in the protocol... no, there isn't
if auth is required or not makes no material difference, the client can simply stream them out, the "ok" replies don't have to be received before another can be pushed, it would just be used by the client to know if an event failed to be saved by the relay for some reason... there also may be rate limiting issues in this, that may or may not be documented in the nip-11
if you control the relay, and it has an admin http listener like #realy does, you can just dump the events up to it that way, it has no rate limiting and doesn't require to receive acks at all, but it also doesn't tell you on the wire whether the events were accepted
there could be a bundling extension on the EVENT message type that lets you string multiple event objects comma separated in one go, or you can just write an uploader that works with the normal event/ok cycle to make sure it all goes up, it may be a little slower but probably won't be a big deal most of the time, i mean, 2 minutes versus 10 minutes is not gonna kill you probably, especially considering you can parallelise these uploads or do something else in the meantime