But don't you could fetch the update without CLOSE-ing and REQ again?
You could keep the REQ on actually
Discussion
Not enough space generally. Many relays are still forcing max of 10 filters and 10 subscriptions. That's not enough for all the types of events we are constantly watching. So we have to constantly rotate to fit everything in.
The problem with this design are, simply sending CLOSE was not enough at certain conditions especially when user has slow network connection / has bad latency to some relays. It will still receive events even after sending CLOSE (well, TCP nature). So sending CLOSE after seconds of REQ will just cause another garbage traffic flood & wasting user bandwidth.
Oh yeah, on top of that many relays never actually close anything and keep sending stuff even for past filters. Many implementations kill the entire connection to get rid of old subs. Welcome to nostr :)
But like I said, the processing of reqs and returning events is quite fast, like 30 micro seconds or so. I don't think that is much of a slow down, even in feature phones.
The Compose UI itself is slower than processing.
The UI is slow. Yes.
But the network too X)
The relay side may already know that the client sended CLOSE and has stopped transmitting, But client is still receiving all of the packets. So still painful
I think you may need to keep the current values into cache database until user may reopen it again, Unless the focused stats was the current stat (the current post should receive live stats, the replies should not).
So it's basically like sending CTRL+C in SSH after you are doing a big `cat`.