Blocked or muted accounts still appear when boosted

[kit-ty-kate]

Using Mastodon 2.4.1 when you have blocked or muted an account, if one of your followers have boosted on of their toot it will still appear on your timeline.
The weird thing is when you just click on the mute or block button they disappear from the timeline but as soon as you reload the page they reappear (and are still muted/blocked).

I'm not sure of the behaviour of muted account (someone told me that it is normal to see boosted toot from a muted account) so even if I would find this behaviour weird, at least it surely shouldn't happen with blocked accounts.

[Gargron]

The weird thing is when you just click on the mute or block button they disappear from the timeline

The JS in the client immediately removes that stuff from your browser window as a form of "lag compensation". In reality, "clean up my home feed from this person" is a background task queued at the time of block/mute, but if the Sidekiq queue is clogged up it could take some time and when you refresh the page, the toots are still there. Are you sure you did not report this issue too soon?

Because there's definitely code to deal with this, the question is, did something about it break so it doesn't work anymore, or is the server you are using just a bit laggy.

[logicsoup]

There's another issue regarding this as well.

Blocked accounts are able to interact with public posts of the user who has blocked them, and it's a consistent bug with various servers. They're able to reply to those posts, where the reply is visible in thread view, only the user doesn't receive notifications about it. Potentially a very serious issue, which seems to work when those posts are boosted, are public or replies in another thread.

[kit-ty-kate]

@Gargron mmh it "seems" (not totally sure) to have worked in the end but it took at least several hours.
I just tried on another account and it still not hidden after an hour blocked and almost two hours muted (should mutes suffice in this case ?). cc @wxcafe for social.wxcafe.net

[hannahjherself]

From the point of view of UX this is still an issue. Several times in the last few weeks I have blocked an account in order to remove upsetting content that has been boosted into my timeline. In both cases the content has remained in place. I have checked / refreshed my timeline on Tusky and Tootdon, cleared cache, hard restarted the apps, tried logging out and in again and the post remained viewable. I confirmed the boosted post was still there on the mobile web site too.

I think there needs to be some mechanism to hide posts outside of the asynchronous clean-up process so that upsetting posts are gone immediately from the point of view of the user. I have been fortunate that the specific posts I was concerned about were only mildly upsetting - I just didnt want to see them - but I am worried for the next time.

I guess what I am arguing is that user expectation about what happens to visible posts when they block an account probably differs from what is actually implemented right now.

[Cassolotl]

I think there needs to be some mechanism to hide posts outside of the asynchronous clean-up process so that upsetting posts are gone immediately from the point of view of the user.

Something like Hide a specific status #1669 might be relevant to your interests. :) (I strongly agree!)

[paintedsky]

Would like to add my +1 to this issue- It seems to me like something so crucially important to the Mastodon user experience shouldn't be relegated to a "whenever" queuing system.

I have just now run into this issue personally on cybre.space, and then logged into mastodon.social and confirmed it was happening there as well.

Luckily, I don't have any really strong aversions to content, so for me personally this issue is just "highly annoying", but it could be really distressing for someone with PTSD or severe depression or anxiety.

I guess what I am arguing is that user expectation about what happens to visible posts when they block an account probably differs from what is actually implemented right now.

100%.

[Packbat]

Bumping the thread: this problem is not resolved, and judging by the multiple people I've encountered whose blocks and mutes have silently failed, is fairly common and is upsetting and confusing to those who encounter it.

This is an accessibility issue: being unable to filter out upsetting or even triggering content - and many people have very specific and rarely-CWed triggers - can make a site difficult or impossible to use. Mastodon has done a great deal to make itself a site that people with PTSD, anxiety, dissociation and depersonalization issues, and many sources of mental health struggles can use safely; reliable and instantaneous (within a second) mutes and blocks should be an automatic.

I don't know why the priority-high label has been removed, but this is a major bug whose presence harms the users - I would urge for it to be dealt with quickly.

[Packbat]

Off-the-top-of-my-head suggestion: give the client a list of mutes and blocks that Sidekiq hasn't gotten around to implementing and let the client do the work of discarding posts until Sidekiq finishes and removes them from the not-yet-implemented list? That would prevent the failure mode reported.

[nightpool]

@Packbat the priority high label was deleted from the ticketing system, it wasn't specifically removed from this ticket.

[nightpool]

If sidekiq tasks are taking more then seconds to complete, that reflects a more fundamental problem with the way mastodon is being run—either it needs more resources or something else is hogging processing power and needs to be dealt with manually by the admins.

@paintedsky I don't remember anyone reaching out to me about this issue on cybre.space, so I can't say definitively what the cause was, sorry.

But sidekiq isn't a "whatever" queueing system, it's the backbone of all processing done by mastodon. If it's regularly lagging by more then a couple seconds, then the instance as a whole is broken in fundamental ways.

[Packbat]

What else would happen if Sidekiq tasks were running slowly? If hour-long Sidekiq lags would have obvious effects for the userbase that would already be noticed, then maybe there's something else going on with this bug.

[ghost]

just a random user here, but this is a bad bug for any user to deal with

[anampses]

as admin of an instance that hosts a lot of sensitive content, this is a major issue still for many of my users who want control of content they don’t want to see on their home timeline. I continue to receive reports that muting does nothing as their boosted content still appears.

I implore the devs to please look into this issue.

[marrus-sh]

I understand that removing posts from a timeline takes a long time, and because UIs donʼt know the relationship of every user to every other user (ATM AFAIK the relationship request is only sent when you view their profile, not when a toot pops up in your timeline) itʼs impossible for them to immediately filter out muted/blocked users when rendering toots.

But I think a large part of this problem isnʼt so much the presence of the toots in the timeline, but the fact that they get “raised” when they are boosted again by users. Would it be possible to add a check on boosting, and simply not raise toots to the top of a userʼs timeline if they have its OP muted or blocked? This wonʼt delete the original post from the timeline (queued for later), but it will make it much less likely that the original post gets seen (as people mostly just hang out at the tops of their timelines anyway).

(Alternatively, the problem would presumably be solved if the UI fetched any/all unknown relationships upon updating a timeline, but Iʼm assuming that thereʼs a performance reason why this doesnʼt already happen though?)

[ghost]

Not being familiar with the code, I have trouble understanding why this is so difficult or complicated.

[miguelprovencio]

I muted and blocked a user from cybre.space and the user would still show up in my timeline because it was boosted. Even waiting 60 minutes didn't help. My only recourse was to mute the person that boosted the user even though I'm still following him.

[trwnh]

I do think relationships should be cached so that the client can do its filtering if the server generates a feed with something it shouldn't have in it.

[trwnh]

maybe fixed by #14339 ?

[pbeens]

I see this is still a problem. This would seem to me to be a pretty serious issue in the usability of Mastodon, so I'm surprised it hasn't been fixed since it was first reported in 2018.

Edit: grammar

[hjhornbeck]

I can second this as an ongoing problem. One of my follows reported an issue very much like this. I'm not a Ruby programmer, but I eyeballed #14339 against the current code and there didn't seem to be an obvious regression. clear_from_timeline() became clear_from_home() and statuses.filter became statuses.select, but neither seems likely to be the cause. If I get some time, I'll try to replicate it on the instance I run.

[ronilaukkarinen]

Also happens with words/tags, confirmed here.