Is this sort of thing inevitable? The fact we feel compelled to bring algorithmic content sorting into the fediverse says something about the way we use social media. The author mentions that reverse-chronological timelines make you feel like you need to spend hours scrolling through much of the same thing to make sure you’re not falling behind on the internet. The other side of that is, why is it that we’re all spending so much time dumping the same thing into each other’s timelines? (I’m at least a little aware that I’m probably the nth person you’ve seen posting about this or a similar problem in the last week)
My solution to the timeline getting too fast has always been to unfollow/mute people, but maybe that’s getting impractical.
@anova I don’t think it is inevitable for algorithms to be implemented, but it’s true that algorithms prioritizing “important”, relevant, and less spammy content can be useful. I think if we’re going to do that we need to consider what metrics are going in to the algorithm - how we can avoid encouraging exploitation of this algorithm, and how we can ensure that the algorithm represents what users want to see rather than what makes the company the most ad money. Twitter’s algorithm was exploitative and hurt its users massively, compounded by the fact that it stopped remembering preferences for a chronological timeline; it’s a primary reason I stopped being regularly involved in the platform, the timeline stopped making any logical sense and was filled with messages I didn’t care about.
What do you think of @jonny@social.coop 's idea of allowing user-configurable algorithms? It sounds like it might be difficult to implement well but that could be a more individual approach, and it’d help to deal with people exploiting the algorithm. The biggest issue I see with it is that it could just end up streamlining the existing problem of algorithmically generated echo chambers. I can’t imagine a single algorithm that generates timelines for all user that wouldn’t be exploitable, though maybe democratic control of how it works would compensate for that.
@jonny @anova I like the idea of user-configurable algorithms, and I think a key point is to ensure that the algorithm is open-source and not an AI black box. Good point about echo chambers, though; I’m not sure where the balance is between freedom of attention and exposing people to a diversity of ideas.
@f00fc7c8 @anova
I got kind of stalled on this bc helping start a new instance (and part of that instance will be explicitly to support hacking on masto), but I have some notes on modifying Lists to give an API endpoint that accepts posts, rather than accounts here:
https://wiki.jon-e.net/Masto_Forks/DIY_Algorithms
As far as the actual algorithm part, some initial ideas I had were making paired “inverse algo” lists that show you what’s being downranked …
@f00fc7c8 @anova
… but I also am much more interested in a parametric algorithm that lets you rank based on an explicit set of derived features, rather than any sort of ML model. The implementation of “lists that also accept posts” is extremely general, so you could plug in anything to that, and so I’m dissociating the literal algorithm part from the masto fork that supports arbitrary algorithms.
@f00fc7c8 @anova the much touchier side of this imo is opting out of having your posts ranked/scraped/etc. like imo I think a bot that caches your home/local feed for some short period is basically the same as what any mobile app would do, but ideally it would be possible for people to opt out of even that - which points to a need for richer metadata at the account/post level, which is also something I’ll be exploring by trying to expose arbitrary JSON-LD in posts
@f00fc7c8 @anova and something I had been thinking about with @axz recently was how to make/use shortnames in posts/accounts, so it would be nice to be able to, eg. make a schema/etc. in something like JSON-LD that describes your account’s disposition towards bots, or your particular set of algo params like @jonny:rules:bots, or @jonny:algo:timezoneCorrection so they could be reused/swapped/modified/etc.
@f00fc7c8 @anova @axz ideally long-term I would like to generalize this so you can declare any sort of post formatting/field structure/as a schema and then be able to use it s.t. other clients could consume it with reference to your schema (as opposed to the way eg. glitch-soc can do markdown but base masto just renders as plaintext). those ideas are over here, but still need work: https://jon-e.net/infrastructure/#documents–notebooks