[Request]: Live updates for focused content

[TriVoxel]

Describe the request

When the Home feed is loaded, sometimes posts will get likes, comments, and reposts after they've already been loaded. It can be a little jarring when you like or repost something and suddenly the number jumps way up.

I'm wondering if it is possible that, while the content is in view, the post statistics are checked every 2 seconds or something. If the number changes, perhaps you could animate the number going up/down? Maybe even make the icon animate slightly with a pulse or bounce, or something unique for each counter?

Design-wise, I think it would make sense only to do this if the post is at least 80% visible, or maybe only the statistics that are in view for performance reasons. Coming back to the animation example, perhaps you could do something fun use a shake animation for the replies counter, a pulsing, scaling animation for the heart, and a 360 degree spinning animation for the repost icon.

Could be fun! Would at least be nice if the numbers updated live and were animated to hide the fact that they are updated periodically.

Implementation Details

• This follows the GNOME HIG.

[GeopJr]

Is it possible? Kind-of.
Should we do it? Probably not :/

---

This is somewhat a personal opinion, though I'm obviously open to hearing other sides on this. I try to avoid spamming the servers whatsoever. I think requesting X posts every Y seconds forever might be too spammy (and will likely land us on rate limits). Considering the majority of fedi is paid out of pocket, I really don't want to contribute to admins having to pay higher bills or their server being sluggish...

---

I can real-time check the rate limit. GETting https://tech.lgbt/api/v1/statuses/108977373960559539, it gives me the following response headers:

x-ratelimit-limit: 300
x-ratelimit-remaining: 283
x-ratelimit-reset: 2025-03-06T15:45:00.479512Z

That is a global rate limit and every time you interact with the API it decreases by one. The limit resets every 5 minutes.

Now let's say we have 10 posts in view that we constantly update every 2 seconds (that's assuming requests are perfectly timed and tuba wont do ANY requests as you scroll unless youve stopped etc). That's 10 requests per 2 seconds and would take only 60 seconds to reach the 300 rate limit.

[nekohayo]

Related, for details view outside of the timeline view (i.e. for individual posts): #174, #178.

[TriVoxel]

Is it possible to only pre-load the message content? Then, only load the stats just before the post enters the view? That may be a good compromise.

[nekohayo]

Now let's say we have 10 posts in view that we constantly update every 2 seconds (that's assuming requests are perfectly timed and tuba wont do ANY requests as you scroll unless youve stopped etc). That's 10 requests per 2 seconds and would take only 60 seconds to reach the 300 rate limit.

Thinking about this for timelines but also for threads/details views for the other linked issues above, just doing some hypothetical calculations...

Even on a 1080px-high screen, at normal font sizes + normal line height + link preview cards disabled, and looking at a timeline of relatively short text-only toots, it seems very rare that the window's height can fit more than 4-5 toots in the view, so maybe the 10 toots figure is an over-estimation?

Then, 2 seconds seems quite short to me anyway; what if it used a 20-30 seconds self-cancellable timeout method (i.e. it resets the timers whenever you scroll, so that it doesn't start updating until you've basically been idling for a while on the same spot)?

If my calculation method is correct (?), this could be the "worst case scenario" number of requests consumed:

That's even unlikely to happen in a timeline because the posts would probably get pushed out of the way by new posts, so in practice their stats are unlikely to even be refreshed at all.

If you also make Tuba throttle its refreshes when the window is not focused (but still visible / not obscured), down to once per 90 seconds, you get this theoretical maximum:

And, if not actually visible—while minimized, on another workspace, or obscured by another window (like in WebKitGTK; this Mutter ticket also has information)—it could even entirely suspend its statistics refreshes until the window is actually visible again at least, then it would refresh if the timer had reached 0, before resetting the timer. That way, in the background you would use virtually 0 requests for the timeline, most of the time. Kinda like what Fragment does too?

[GeopJr]

Is it possible to only pre-load the message content? Then, only load the stats just before the post enters the view? That may be a good compromise.

Nope. A status (post) object is complete - it has not only the post contents but also its stats and even the full account info of the author.

What was suggested once similar to this was refreshing the timeline as a whole in the background and update the posts silently (for the sake of this comment, timeline = bulk posts) but that has its own limits (you can only request a max of 200(?) or so timeline limit at a time and it's quite stressful for the server considering the amount of data it has to gather and transfer).

Thinking about this for timelines but also for threads/details views for the other linked issues above, just doing some hypothetical calculations...

That does sound more reasonable and I'm willing to experiment with it, however we should keep in mind that we have to absolutely stay as far away from the rate limits as possible. 300 is global and once you reach it, you cannot interact with the API at all.

I had this happen on the 0.9 Tuba announcement; I reached it because I was checking out how it would look like by posting it under mentioned-only, and when I had to actually post it, I couldn't post the whole thing so the thread was half-missing for 5 minutes.

[GeopJr]

Technically we could also check the rate limit and only do refreshes if there's more than 100 left.

[nekohayo]

If you were to combine the timers + background throttling + rate limit checks approaches all at once, I suppose it would be theoretically pretty hard for this to meaningfully make a dent in the polling budget :)