It's basically the backbone of nostr that you are currently using and seeing right now, A bunch of servers that retrieve and store a data in the form of "event"s where an event could be a note, interaction (like, repost), zaps, etc.

given that you are storing a event in more than one server, each server uses different kind of implementation, some are probably limited probably due to how it was designed to work. because of that, client must be aware that each servers might have incomplete implementations of it and must try to solve that problem on their own side instead of fixing it upstream, which could take longer given that not every admin would like to update the software right away, especially on a busy server.

I would suggest having your client to send CLOSE to relay after you received `<limit>` amount of events accordingly to your REQ instead of blindly trusting relay, which i found quite often

Seeing how developers treat it, It seems they prefer to have the subscription closed by the relay right after receiving a selected amount of events,

but then one might treat a limit as an offset and that's where both things conflict with each other. Given that i treat it as a offset but still sent EOSE anyway, Some developers find it a bit conflicting with their implementations.

ambatukam