mbilokonsky / ambassador Goto Github PK

To avoid big blobs of posts when this application cycles, those toots to be boosted should be added to a queue which is published on a schedule.

If someone wants to PR this before I get to it I'd be appreciative, if not it's the next feature on the list!

would like to make a fediverse ambassador bot that boosts from the federated timeline

Maybe it could be made to boost once per hour, and the boost is the most-liked toot from the instance that hasn't been boosted by the bot yet? That way there's not a flurry of boosts all in one go, and it doesn't repeat itself.

Edit: I was going to say that it also doesn't have to calculate an average, but maybe that's a bad thing?

So perhaps it should boost once per hour, the most-liked boost that is above averagely liked, that hasn't been boosted by the bot yet?

This is pretty close to the current logic, if you squint a little...

Basically, this bot wants to boost the very best toots. Put another way, those are the outliers measured in favs! It'd end up something like:

SELECT id
  FROM public_toots
 WHERE favourites_count > (
       SELECT stddev(favourites_count) + avg(favourites_count)
         FROM public_toots
        WHERE created_at > NOW - INTERVAL '30 days'
       )

2*stddev seems to be a more common outlier function, but it'd only find the really exceptional toots instead of just the uncommonly good toots.

As a bonus, it's likely that stddev is implemented efficiently in the database!

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.

Hey,

So I'm not real familiar with JavaScript, but I'm a programmer in other languages, so I'm going to be general here. There's a simple way to fix your cache issue without using a cache at all.

Do this instead:

• Your first query should be the 30 days one. That's fine.
• In the toots reported from your query, select the newest one. You can do this pragmatically if you want. It doesn't matter.
• Store the timestamp in some persistent file for later usage in case of a shutdown. Read the file on startup if it's there.
• Use this query:

SELECT id 
FROM statuses 
WHERE favourites_count > (
  SELECT avg(favourites_count) 
  FROM statuses 
  WHERE favourites_count > 1
  AND created_at > (latest toot timestamp)
)
AND created_at > (latest toot timestamp);

It should be relatively efficient. I'm not sure how to make that SQL query better myself; I'm no SQL expert by any means.

Ambassador maintains a “cache” of already-boosted toots (to avoid necessary API calls, likely).

Right now, the cache is deleted, to avoid memory leaks, every 3598 seconds (and not “2s before the hour” as the comment claims), likely resulting in higher load immediately afterwards.

Instead, the cache could keep track of the created_at value for the toot, and periodically purge entries with created_at older than 5 days (since only toots newer than 5 days are considered for boosting).
This guarantees that the set of already-boosted toots does not grow larger than it needs to be, while avoiding spurious cache misses resulting in load spikes.