@sethmlarson @andypiper See also this issue: https://github.com/mastodon/mastodon/issues/33873

@sethmlarson That's an interesting concept. One problem might be to determine the "time of last boost", because that's not a part of Mastodon's status entity, and thus might have to rely on incomplete information the client happens to have about the status.

Other than that, "delayed boosts" and a "boosting queue" that gets evenly spread in time are great ideas!

@sethmlarson This should all be server side.

Clients don't know if/when they will run (think mobile apps with spotty network connectivity, or browser tabs that could be closed at any moment) so a client can't meaningfully "delay" a boost.

My server already knows what's in my timeline, so it could "drip-feed" boosts into my timeline over the day, or aggregate multiple boosts of the same post into a single boost-post in my timeline.