Vitor Pamplona on Nostr: The incoming order in multi-filter subs also varies a lot. Some relays send all ...
The incoming order in multi-filter subs also varies a lot. Some relays send all matching events for the first filter before starting the second. Others do all at the same time. Others break them in chuncks. So the order of arrival cannot be relied on.
You can save the last EOSE, but you will need to update it when live events show up in the same subscription after the EOSE is received.
However, events in the past show up all the time. I initially thought this was a problem for GiftWraps alone, but no. Every event kind has this problem. Because `since` is based on the `created_at` and not in the relay's receiving date, when using `since`/`until` you are bound to miss events were broadcasted late, like 1hr or 1 day later. This is particularly problematic when users are not using large relays. Their messages might arrive later just because somebody else replied there and re-broadcasted the original not to the rest of the relays.
Either way, EOSE/since/until will be broken until something like negentropy or https://github.com/nostr-protocol/nips/pull/826 becomes widespread.
You can save the last EOSE, but you will need to update it when live events show up in the same subscription after the EOSE is received.
However, events in the past show up all the time. I initially thought this was a problem for GiftWraps alone, but no. Every event kind has this problem. Because `since` is based on the `created_at` and not in the relay's receiving date, when using `since`/`until` you are bound to miss events were broadcasted late, like 1hr or 1 day later. This is particularly problematic when users are not using large relays. Their messages might arrive later just because somebody else replied there and re-broadcasted the original not to the rest of the relays.
Either way, EOSE/since/until will be broken until something like negentropy or https://github.com/nostr-protocol/nips/pull/826 becomes widespread.