Use n-th percentile rather than average

[KellerFuchs]

Would it make more sense to boost the n% most favored toots rather than all toots above average?

This would likely in more a predictable way: roughly, if your local feed had k toot/hour, n-th percentile has n*k/100 boosts per hour, so instance admins can pick n so that following the ambassador does not flood one's timeline.

[mbilokonsky]

The rationale behind the current sliding window strategy is to allow huge curve-breaking spikes to eventually fade away and not wreck the curve for everyone else - but yeah, I guess an n% approach would ultimately work the same way. Better, even, in that it's more predictable and as you say admins can pick a value for n.

I'll look into doing this or, if you feel like it, feel free to PR this option in. That 'n' value can be a config variable?

BTW thank you so much for your contributions, this has been so helpful! :)

[KellerFuchs]

Thanks a lot for testing and merging my other PRs so swiftly :-)

Yes, the sliding window mechanism itself is a good idea, and should likely stay as-is, though that raises some questions about how nth-percentile interacts with it; what I had in mind was, as currently, to compute the nth-percentile based on the large (30 days) window, then restrict to toots newer than 5 days.

I'm honestly not sure if I will manage to have the time/spoons to make this happen, even though it should be pretty straightforward, so I definitely won't be upset if you go ahead and implement this before I can :-)