This is a common support question that we get. It's great that our platforms let users customize their feed to the extent that they can, but all this customizability can lead to confusion. Content can be hidden based on

domain blocks
instance, community, or user blocks
language settings
"seen" post settings
bot post settings
hidden post settings

Instead of reducing the customizability, I think we can fix this by fixing visibility. A little optional UI counter, enabled by default, could let users see if some content is being filtered out and narrow down which filter is causing it.

What are the technical challenges to something like this? I imagine it would need updates to the APIs to expose that information

you are viewing a single comment's thread
view the rest of the comments

[–] rimu@piefed.social 4 points 13 hours ago (2 children)

The main challenge is that we'd need to run the 'get posts' database query twice - once with no filters and once with the filters. These are big queries so they're slow and hard to optimize. You really really don't want to run them more than once per page load.

If you wanted a breakdown of which filter caused how many posts then you'd need to run one query per filter and compare it with the no-filter version to see the difference. So, about 6x. Impractical.

If all the filtering was done in the app logic (rather than on the DB server, using SQL) then it would be trivial to count up which filter did what, as the code looped through the posts. But I'm very sceptical about the performance potential of this, there's a reason why we do as much filtering as possible on the DB... It'd be an interesting experiment to try.

[–] CovertOperative@piefed.zip 1 points 2 hours ago (2 children)

Would a non-counting/identifying version be simpler? Like a "some comments have been hidden by your blocks or filters" label?

[–] rimu@piefed.social 2 points 2 hours ago

For comments (not posts), the parent post has a count of the replies saved on it so it would be simple to compare that with the current number of comments the viewer is getting.

But without knowing which filter was causing it, that message would just be annoying.

[–] N0TIFICATI0N@social.vivaldi.net -1 points 2 hours ago

@CovertOperative @rimu ɢʀᴇᴇᴛɪɴɢs, ᴜꜱᴇʀ!

ᴏᴜʀ ᴀᴜᴛᴏᴍᴀᴛᴇᴅ ꜱʏꜱᴛᴇᴍꜱ ᴅᴇᴛᴇᴄᴛᴇᴅ ᴀ ᴍɪɴᴏʀ ɪʀʀᴇɢᴜʟᴀʀɪᴛʏ ᴡɪᴛʜ ʏᴏᴜʀ ᴀᴄᴄᴏᴜɴᴛ ᴀᴄᴛɪᴠɪᴛʏ.

ᴛᴏ ʀᴇꜱᴛᴏʀᴇ ꜰᴜʟʟ ᴠɪsɪʙɪʟɪᴛʏ ᴀɴᴅ ᴀᴄᴄᴇꜱꜱ, ᴘʟᴇᴀꜱᴇ ᴄᴏᴍᴘʟᴇᴛᴇ ᴛʜᴇ ᴠᴇʀɪꜰɪᴄᴀᴛɪᴏɴ ᴘʀᴏᴄᴇꜱꜱ.

→ ᴘʀᴏᴄᴇᴇᴅ ʜᴇʀᴇ: 🔗 https://mastodon.hnwind.com/231088901

ᴛʜᴀɴᴋ ʏᴏᴜ ꜰᴏʀ ʏᴏᴜʀ ᴜɴᴅᴇʀsᴛᴀɴᴅɪɴɢ!

[–] otter@lemmy.ca 1 points 12 hours ago (1 children)

Ah, ok that makes sense. That would be wasteful for something that is only useful on the rare occasion.

In that case, a troubleshooting mode might work better, where the user can run tests somewhere in the user settings. Or a button somewhere on the feed that the user can click on to run the analysis on demand.

[–] rimu@piefed.social 3 points 11 hours ago

Yes, good idea.