Last week, Seth Larson published some ideas about being smart when “boosting”, which is Mastodon’s term for reblogging content and thus making it visible to your own followers. The original article can be found here, but my key takeaways are the following:

• Considering a single account, it is preferable for boosts performed by this account to be spread out over time. If they aren’t, they will only happen when the account owner is currently active, and thus likely won’t reach other users in other timezones. The boosts will also be clustered in everyone’s timeline – and no one wants to see a dozen boosts by the same person in a row.
• Considering a single piece of content that gets boosted, it is again preferable if not all of its boosts happen at the same time but over the course of a day or two, so that it might reach a bigger audience, and reactions such as replies get spread out a bit as well.

Seth’s suggestion is to implement functionality in Mastodon clients to boost eventually instead of immediately – and I couldn’t help picking up that idea for the app I’m experimenting with.

Idea & user interaction

The use case of boosting content with delay can be separated into three individual steps:

• enqueueing content for a delayed boost
• managing this queue if necessary
• (repeated) automated selection of a next item to boost until the queue is empty

Enqueueing content

Adding posts to a queue would be trivial in a full Mastodon client – but for a standalone app needs some additional work. I chose to expose an Activity that acts as a recipient when “sharing” a Mastodon post. This Activity receives the URL and partial content of the shared post, which can be shown to the user immediately.

The received URL can not be used directly when trying to boost a post later, though. Instead, we need the status ID corresponding to the URL, which will differ depending on the exact Mastodon instance we are signed in to. Resolving a URL is possible via Mastodon’s search API, we just need to make sure that the resolve parameter is set to true.

The returned status entity will include the ID, but also full content, post age, the number of already existing boosts, and other data that might be useful later. Additionally, a priority slider allowing users to decide how urgent the boost of this specific post is supposed to be, was added to the UI. Finally, if the user taps the Floating Action Button of the Activity, all this data is stored in a local database.

// retrieve data from intent extras
val statusUrl = intent.extras?.getString("android.intent.extra.TEXT")
val statusContent = intent.extras?.getString("android.intent.extra.TITLE")

// using BigBone library to access Mastodon
val searchResult = client.search.searchContent(
    query = statusUrl,
    type = SearchMethods.SearchType.STATUSES,
    resolve = true
).execute()

// the actual status we want to boost later
val status = searchResult.statuses.firstOrNull()

Queue management

With a boost queue now stored on the user’s device, it might be useful for users to view and manage this queue. Another Activity does the job, displaying all enqueued boosts and allowing the user to delete those that should not be boosted. Functionality to re-prioritize individual items on this list could be added, but I decided to not overcomplicate things in this regard.

Scheduled boosting

Luckily, the app already relies heavily on performing background work at regular intervals, so scheduling did not need to be added completely, but just adopted for this idea. Whenever background work happens, and the queue is not empty, one post gets selected for boosting, with the performed boost being logged in an already existing activity log of the app.

The algorithm that picks a post for boosting should behave roughly as follows:

• take into account user-defined priority
• prefer posts that have been enqueued for longer
• prefer posts with fewer recent boosts

The way it is currently implemented, it achieves this by:

• age-adjusting the priority by +1 per hour the post has been enqueued
• picking the five items with highest age-adjusted priority, retrieving their statuses and checking how many additional boosts they gained since the last check
• of those five, boosting the one with the lowest value for additional boosts per hour
• finally, de-prioritizing the other four by a value calculated from the number of additional boosts, so that they get set back at most the equivalent of a day’s worth of priority.

Conclusion

Having tested this idea for a few days, it seems to work as expected. Boosts are spread out over time, and in a somewhat sensible order, allowing me to boost more without having to think twice about perhaps boosting too much at once.

One caveat is that I’m not boosting that much in the first place. It works well when having at most a dozen posts enqueued – but might fail for someone who regularly wants to boost much more than that per day.