Nostr Web Client

damus does all of these except 1 since that would possibly miss messages

Nice.

Point 1 can't really be addressed without addressing point 2 first because, as you say, you would miss messages. If you know that person P posts on relays (X, Y, Z), you can ask 2 relays (X, Z) for those notes and because they both should have them, it's usually good enough. If not, ask on 3 relays.

If you instead ask the user-configured relays for P's posts, then asking only 2 of those relays is probably going to miss tons of messages. But even if you ask all of the user-configured relays, you will both miss many messages and will also download a lot of duplicate data. The only way to get all the messages of all the people followed (and avoid excessive duplicate downloading) is to go out there to that unloved relay in Timbuktu that the user didn't configure (but that P has in his relay list) and fetch them from where P wrote them.

Of course, fetching from relays that the user didn't configure has implications.

Reply to this note

Please Login to reply.

Discussion

jb55 2y ago

theres another issue where many relays are overloaded and don't return things in time, so relying on a subset of relays can make loading slower. Perhaps you can collect response time stats and prioritize the fast ones? Fetching from all just seems simpler even though it can be bandwidth intensive.

⚡️🌱🌙 2y ago

So my client subscribes to all the pubkeys I follow, could it remember which 1 or 2 relays responded fastest for each pubkey and after the first poll only subscribe to the fast relays for each pubkey for remainder of the session?

Seems like it could save a lot of bandwidth and relay load.

Mike Dilger ☑️ 2y ago

Fetching of events not be a lot of bandwidth relatively speaking, it would have to be measured. I suspect web content referenced by events constitutes a lot more data than the event structures themselves.