What could a self-hosted social feed mixer do?

I’ve been thinking for a few weeks about how a self-hosted personal feed mixer could work. Like many other folks I’ve recently revived my presence on Mastodon - @Rob_Russell@mastodon.cloud. When I read this post from @nuthatch

I started dumping my ideas into a reply but soon realized I was hundreds of words off on a tangent. So instead I captured my ideas here.

A personal feed mixer, as I’m calling it, is a way to take multiple periodic data sources and produce a ranked list for the reader. This is the same function as what’s often just called the algorithm. I’ll avoid going on a tangent from my first tangent right now and gripe about that particularly obnoxious bit of terminology later.

On any given day, at any given moment, There are a lot of publishers that you want to read, but they publish more than you want to read in a session, so you need some way to choose what to read. The UI that we’ve become used to is just a single scrolling list. Almost always, the next thing to read is the next thing in the list. Ranking the items in the list - i.e. deciding which order to show items - is where the choice about what to read is made. The order of that list is what everyone seems to be arguing about.

My concept of a self-hosted personal feed mixer is making this ranking explicit and managed by the user.

Imagine you start with a set of input feeds, maybe Mastodon lists. Sampling and ranking rules are applied per input. All the ranked results go into a mixer and the mixer output is the feed that the user reads.The unique component in my proposal is exposing the sampling and ranking rules in some configuration UI available to the user.

Of course the devil is in the details. The concepts here are abstract and a clear UI with good defaults makes all the difference. For example, a configuration UI might start with some defaults that make it easy for casual users to get a result they might like:

• A high priority list of feeds with very few posts
• A list for the infrequently posting friends who you want to always want to read chronologically
• A list for entertainment feeds that post many times per hour

With this default configuration, the mixer outputs a feed for the user to read. Since there are few items from the high priority list they pop up to the top and the user scrolls through them quickly. Next up are posts from the friends and entertainment lists. The friends’ posts are mostly toward the top and sorted strictly chronologically. If it’s been a long time since the user has looked at their feed, there may be a lot of unread posts from friends. In that case they’ll see a lot of these posts and very few from the entertainment feeds at first. As the user continues scrolling, there are more posts from the entertainment feeds as the new items from friends run out. When the posts from the entertainment feed show up they’re ranked by a weighted combination of chrono, popularity, and random selection across the entertainment lists.

These defaults are what I imagine I’d like to use. Finer grained controls could change weights for ranking within lists and across lists and new lists could be added with their own factors. The number and kinds of lists doesn’t need to be a fixed set. The relative importance of chrono ordering, popularity, randomness, and other factors can all be fluid .

Things get more complicated because the mixer needs to evaluate which items have been read. A closed application can use a combination of feedback from the UI that displays the posts and time-based criteria to decide. The self-hosted mixer could use the same strategy, but the controls and the read/unread indicator can be exposed to the user. The control could be even more granular than that: feedback from the UI can send all kinds of detail back to the mixer, e.g. how long was the post on screen, did you interact with it by clicking or tapping, how many times did these things happen, etc. In this case, there’s no need to guess whether the post was actually read.

Of course the in-app feedback from the UI would include Mastodon actions like bookmarking, favouriting, and boosting. It could also include things like opening a post or lingering with it on screen. This is a lot of data about exactly what you’re doing as a user.This is the reason why it’s important that the feed mixer be tied to a self-hosted database. The user data is probably a lot of the same information collected on a modern social networking app. However, instead of using your behaviour to serve you more ads, the data can be used to improve your experience. Imagine creating a rule in the mixer that says once per hour I want to see an item I bookmarked over a week ago. That item could be a happy cat picture, a phrase in a language you’re learning, or something on your todo list. Wouldn’t it be nice to be reminded of the things you yourself marked as significant?

One final bit to chew on - there’s no reason the output feed has to be unique. A user with complex needs could run multiple mixers if they wanted to. It obviously becomes more complex as the mix changes from the default. Despite the challenge of building a really clear configuration UI, I think this is a worthwhile experiment.