Follow

we really need some kind of feed mix controls. like, say I'm subscribed to someone who posts every 5 minutes, and I want to see their posts, but I don't want my entire feed to be just their posts. idk if that's a client level thing or a mastodon server level thing. i don't think it's level

@kuba @2ck if it consists of personal moderation features and enduser configurable ... then yes.

Like a faucet mixing the ratio hot warm water.

We still dont have definitions tho of what amounts to feed mixing I think.
Sorting filtering are one thing but other parameters?

@joeldebruijn i think maybe it's less that i want posts filtered and more than I want some to be compressed for noisier folks in my feed so they take up less vertical space. something like a summary block that shows "@Devin posted about COVID, horses, Gentoo... (8 posts)"
and i can configure what criteria triggers compression ('clustering'?): number of posts, diversity of topics (may use a language model), temporal separation, etc
@kuba

@kuba @2ck honestly, might be a bit of a hot take, but i don't think an algorithm has to be a bad thing

algorithm has become a dirty word thanks to black box algorithms made to serve corporate interests first, but there is nothing saying an algorithm has to be that way

i feel as an option for those who want it we could make a kind of algorithm that's transparent and configurable and made for users, the only thing stopping us from doing it is our fear of them

@2ck It's a client issue. Something like this could be done without changing Mastodon or ActivityPub. Currently, you might solve this using lists: put accounts which are way too verbose, but that you don't want to unfollow, in a special list and when you feel like reading from them, check that list, while maybe muting them from your home feed.

@2ck more complex home feed post selection processes could probably be implemented by clients, but something people in the fediverse really like is that posts are presented strictly in chronological order. So I don't think that there would be that much demand for something like that, as of now.

@junbird i think it could be server-side in part, though I'm thinking it's like the server providing hints about how some posts could be grouped beyond just being in the same thread. I took a stab at some basic clustering params:
qoto.org/@2ck/1091262037276387

@2ck No, all the server does is giving clients a list of posts (chronologically sorted) from each user. Each post also provides a list of replies. What an AP server does is actually really simple when it comes to providing content. However, I actually like your idea. That might be a pretty smart solution.

@junbird oh, yeah i know jack about what actual masto servers actually do. just think as a value-add, they could add annotations like clustering hints.

I want server-side so when i use tusky or the browser, i can have a similar experience in that regard. technically, it also seems a lighter lift if the client doesn't need to know the clustering rules and can just handle presentation.
i get the discomfort with opaque algos on the backend, but we're not out here pretending we know exactly what's running on servers we don't maintain, right? using annotations seems like a way to have the clustering without the server having the scope to quietly tailor your experience, since you can always turn off clustering client-side

@junbird @2ck maybe algorithms per se aren’t that bad, as long as the user can decide how they work, and it’s implemented per client, it could be just another dimension of freedom. And some hacky users would like to design, tweak and share our own algorithms.

PS. Couldn’t “chronological order” be considered an algorithm too? 🤔

@gianclgar @2ck I'm not saying that I'm against it, I'm saying that many people involved with the fediverse are against that kind of stuff, so it is unlikely that someone would actually implement something like that in the near future. Of course anyone could actually just do it, anyone could just make their custom client and maybe make it public.

@junbird @2ck I was refering to the general people conceptoon about algorithms. It would be nice as an option in any client, like “choose your algorithm” with “chronological” as a defauly and “custom” as an option, among others.

I feel like some people would just feel bad for the word “algorythm” even if “chronological” would be exactly the same we have now

@gianclgar @2ck That's a bad word in the fediverse, right now. I think that "filtering preferences" or something like that would simply be much more acceptable. I believe that those kind of options might be useful, especially in the federated timeline (which is honestly way too cluttered to be useful). I personally think that the problem with "algorithms" on mainstream platforms is not that they exist, but that they are mandatory and overall exploitative.

@2ck in fact, it might be best if it’s client side anyway, some folks don’t mind the occasional deluge, some can deal with 5 posts but not more than that, some might draw the line at one. User preference, so client-side.

I envision this as some setting in a client, where everything over X amount of posts from one user gets “collided” under a “show the other Y posts” button thingy.

In fact, that sounds like something that’s not even particularly difficult to do, but I’ve never so much as looked at any client code, so I could underestimate things.

@max i don't understand your argument that because it's different for different users, the clustering must be client side. the server already stores divergent info for diff users. i never said it should be a global setting, shared for all users registered on an instance

@2ck With “users” I mean the readers, consumers, whatever you want to call them. If I follow you, and you go on a tooting spree, and I don’t want to see all 9001 of them, I should limit the display on my end, right? In this case, I’m the user.

Does that make more sense? I feel you understood user as the tooting user, not as the tootee.

Giving it some more thought, I (as a tootee) might even have different preferences per client, that way. Not too many toots displayed in a row on my phone, but gimme the whole firehose on a desktop client, that kind of difference.

@max no, I was talking about subscribers when i said "users" in my previous post

@2ck oh, ok. Does the protocol allow such preferences to be sent with a subscription or when receiving updates? I’m not that familiar with the spec tbh.

@max hell if i know😄 I don't see why it couldn't though. i figured it would be an extension or something though. I know there is scope for that kind of thing since qoto, for instance, has some customizations for various things

@2ck might be worth looking into, but frankly, if it’s something that has to be changed/enabled on the server/sending side, adoption might be more problematic than switching a client.

Point in case: Cory Doctorow has very good reasons to be on the Masto instance he’s on. AFAIK he doesn’t control it. So if I have to depend on his instance to throttle his output, I’d be out of luck.

If it’s on the client side, I could at least switch to a client that allows me to throttle whatever.

I’m not against having it on the server side, but that means a lot of folks won’t be able to use it.

@2ck I've thought of this problem before too, but it's definitely not something that is or belongs in ActPub itself. It's just a matter of how any given platform decides to be smart about how to display content.

@CJameson yeah...I said I don't think it would be at the level of AP.

Sign in to participate in the conversation
Qoto Mastodon

QOTO: Question Others to Teach Ourselves
An inclusive, Academic Freedom, instance
All cultures welcome.
Hate speech and harassment strictly forbidden.