Handle lack of EOSE #33

New issue

Closed

opened 2022-11-27 13:04:00 +13:00 by mikedilger · 4 comments

mikedilger commented

2022-11-27 13:04:00 +13:00

(Migrated from github.com)

We should still update last_fetched even if we don't get an EOSE.

ok300 commented

2022-12-10 12:51:44 +13:00

(Migrated from github.com)

FYI: lack of EOSE typically means the relay hasn't finished sending the initial batch of messages. Sometimes it can take a few minutes if the filters are too generic, or if the relay is overloaded.

I'm building a similar app and I'm taking the opposite approach: only save the timestamp on EOSE. I then use this timestamp as since filter on next restart, such that I only do a "full sync" once per relay when the app is first intalled. Any subsequent app starts deal with deltas or incremental syncs.

FYI: lack of EOSE typically means the relay hasn't finished sending the initial batch of messages. Sometimes it can take a few minutes if the filters are too generic, or if the relay is overloaded. I'm building a similar app and I'm taking the opposite approach: only save the timestamp on EOSE. I then use this timestamp as `since` filter on next restart, such that I only do a "full sync" once per relay when the app is first intalled. Any subsequent app starts deal with deltas or incremental syncs.

mikedilger commented

2022-12-10 18:10:49 +13:00

(Migrated from github.com)

But nip-15 is optional. So there could be a relay that will never send an EOSE. I want to be robust enough to handle that even if I don't use any such relay. Maybe by setting a last fetched at least at the time of the last event I received.

ok300 commented

2022-12-10 18:37:44 +13:00

(Migrated from github.com)

Good point.

mikedilger commented

2023-02-09 09:15:06 +13:00

(Migrated from github.com)

This is handled by setting eose immediately on every relay that does not support NIP-11. So I'm closing this (though I should probably fix misparsed NIP-11s)