Timeline smoothing via FIFO queue

What feature would you like implemented? (Please give us a brief description of what you'd like.)

I'd like to work a bit on how timelines display notes. I think that the current method is kind of inefficient in the sense that it can produce these really jarring floods of posts followed by an emptiness in timeline. I am thinking that what we could do is add posts to a "buffer" (we already kind of do this look at misskey "fan out timeline technology"/FTT) and trickle out the buffer via a rate limiting strategy called the leaky bucket. I think this would help mitigate some of the jarring movements that are prone to happen with instances that take some time processing their inbox queue. I'll describe in the next section why this is an issue for me.

Why should we add this feature? (Please give us a brief description of why your feature is important.)

I find it hideous when my timeline trickles about 20 notes at once during bulk processing of inbox jobs and then i get silence before going into another spurt of rapid fire posts. This is less prevalent now that my workers are decoupled from my frontend (via misskey environmental variables MK_SERVER_ONLY & MK_WORKER_ONLY I believe). It's still an occasional issue though. It makes my timeline feel "dead" until the server is finished catching up on posts, and then I get rapid fire with my timeline scrolling in quick succession as a lot of notes are displayed at once. I'd like this to be an optional feature to enable (if it's not too hard) in case people want to revert back to the prior behavior.

Version (What version of Sharkey is your instance running? You can find this by clicking your instance's logo at the top left and then clicking instance information.)

2024.6.0-transfem

Instance (What instance of Sharkey are you using?)

https://transfem.social/

Contribution Guidelines By submitting this issue, you agree to follow our Contribution Guidelines

• I agree to follow this project's Contribution Guidelines
• I have searched the issue tracker for similar requests, and this is not a duplicate.

I believe this should be a frontend thing, not backend. The code would need to go in https://activitypub.software/TransFem-org/Sharkey/-/blob/develop/packages/frontend/src/components/MkTimeline.vue#L75-91 (which then calls https://activitypub.software/TransFem-org/Sharkey/-/blob/develop/packages/frontend/src/components/MkPagination.vue#L390-399)

I concur, I'd like to keep this a client side thing as much as possible. If it were in the backend it may hamper the performance of automated moderation bots (not being able to see timelines in real time on their websocket connection). I also think that the fetching of timelines via POST (https://transfem.social/api-doc#tag/notes/operation/notes___global-timeline and the other ones) should mostly remain unaffected. Deferring the work over to the client to have the actual leaky bucket would mean server resources are not being held up (think about the memory usage involved with thousands of users that's not exactly fun).

I was doing something earlier with the misskey registry and I came back to this. I believe that if this is implemented it should be stored as a registry key. I'm thinking about the options I'd like to implement for this.

• bool enabled - whether it's enabled or not, self explanatory
• int nps - notes per second (ie how fast it can push things into timeline)
• int max - maximum notes in queue before it cuts off.

I was thinking, we could use the domain 'System' like other client preferences, and we could use the scope "client/base", setting a key for timeline_smoothing. Underlying representation could be

{
    "enabled":false,
    "nps":20,
    "max_size":100
}

(I'm not sure about those as default values no, but this is just to show an example)

It's consistent with the codebase imo, because the deck views are not necessary for the backend to be aware of, so the client just stores each profile as a misskey registry key instead. I'm thinking this is the approach to take in order to prevent unnecessary headache by introducing a new account option that has to be added to db. Especially since this is a feature in the frontend.

we already have the defaultStore, where all user settings are kept. we use that. you don't want different speeds for different columns in the deck, do you? (please tell me you don't…)

No, I just didn't know about defaultStore. I don't think that having different speeds would be a viable option for deckui. I don't see a reason to make the speeds different for the same timelines (assuming we're talking about multiple columns of the same timeline). I do want to have separate configs for each timeline type though. I don't think it's feasible to apply this to global unless someone really wanted to suffer? I'd support the config option but I personally wouldn't use it on global because it'd be finicky to set the right "note per second" value that doesn't cause the queue to build up. It would also be highly dependent on the instance's federation traffic so there's not really a good default value one could come up with.

I need to look to see if there's an existing type I can piggyback off of or if I need to make my own FIFO queue type for this. Another option is to use an existing "leaky bucket" library (I found a couple) and see if I can hack that together.

let's start simple: one speed slider, that gets mapped to the leaky bucket parameters, for all timelines. yes, including global. the leaky bucket algorithm is designed to handle excessive input without needing extra memory (it just disables itself 😜)

I mean yeah, that's the point of doing a "leaky" bucket here, once capacity is reached the timelines flood again instead of a slow trickle. There are plenty of other ratelimiter algorithms but I thought this would be the simplest (we don't need to do a sliding window or anything crazy). I agree just for this to implement it as a global bucket and separate timelines later.

to be clear: one bucket per timeline (so, in deck view, the columns are independent), one set of bucket parameters per deviceAccount

Yeah, sorry I confused myself. For working on this i can just ignore deckview, going to the default view to have 1 timeline open. For the behavior when the bucket is full... Let's say the limit is 100. The first 100 in there continue to trickle out (just going to use my 20 value from earlier) with 20 notes per second. If timeline is 40 notes per second and it keeps "overflowing" anything that's not held within the queue just gets shoved into the timeline bypassing the bucket entirely. This allows for the bucket to slowly drain. The second it has space for posts, the timeline goes to the bucket to fill up again right? if timeline smoothing is turned off it just bypasses the bucket like it would if the bucket's queue was exceeded.

I doubt anyone is going to have that high of a number if they're not using global but it helps to visualize.

pretty much, yes

I'm hoping that this would make "reduced motion" usable for people like me who follow a lot of accounts. it can be jarring at best when my timeline instantly scrolls about 10+ notes at once. It's still jarring with the animation but at least that's slower as they each pop in...