Question for relay devs: I want to subscribe to all events that augment the events I'm currently displaying (zap receipts, reactions, and deletions). I'm considering making subscriptions with a long set of IDs in an "#e" filter. So my questions are:

1) How long can that get before relays complain the list is too long?

2) If I add a bunch of IDs to an existing subscription, does it start over, or does it remember that it already gave results for the previous ids? (I presume it would start over, which won't be useful for me)

3) If I then instead open new subscriptions every time I need to watch another batch of events, how many of those can I have before the relay gets mad at me? Because I'd be making new subscriptions every 10 seconds or so for a very long time without closing the old subscriptions.

4) Would it be more efficient for me to be watching all the events my user might see on screen all the time, or should I dump and restart subscriptions whenever the user changes to a different feed? That second method would be watching much fewer events, but would rewrite subscriptions frequently thus pulling redundant data.

I know I can look at the NIPs and program to that, but I thought I'd get to the best plan of attack faster by just asking.

nostr:npub1xhfxu35se0s63x90v8xr29txr66l5a3m277skshy2zvu3ve0658sla4xw3

nostr:npub1qqqqqqyz0la2jjl752yv8h7wgs3v098mh9nztd4nr6gynaef6uqqt0n47m

nostr:npub1yxprsscnjw2e6myxz73mmzvnqw5kvzd5ffjya9ecjypc5l0gvgksh8qud4

Reply to this note

Please Login to reply.

Discussion

Ok I'm going to do the following. I hope it is okay:

1) One subscription for the main feed, which is usually several hundred notes long. Every time a new note comes in, but no more often than some minimum time, I will rewrite it adding the new IDs, and including a since=now so as not to replay everything again.

2) One subscription for alternative feeds such as viewing a person's post history, viewing a particular thread, or viewing your inbox. This will be rewritten as the notes flow in for that feed just like for the main feed, but the filter will not have any "since=now" limitation, practically guaranteeing many repeats. This subscription will be unsubscribed as soon as they browse back out of that alternative feed.

Both subscriptions will be limited to reaction/zap/delete event kinds.

Amethyst does it similarly but subscribes to visible events only. As the user scrolls and stops, the app waits 100ms from the last scroll change, and refreshes all filters.

That seems very reasonable, and even though you would be rewriting the filter frequently, the subscription is always very short. Maybe I'll do that instead. Thanks.

relays hate it but it's better than hitting the limit in filter size

This is the best approach IMO.