Mastodon: Blocked users' toots still appear on the profiles of users who retoot them

[Skirmisher]

Reworded: The posts on the profile page of a user are not filtered for blocked users, so retoots of them still appear. (Yes, I'm going to keep using that word.) This affects the home-interface user view and dedicated profile page view. (As a side note, those feel like different things, but it's hard to refer to them separately--what's the deal there?)

Thanks to @[email protected] for pointing this out!

[grimedango]

Seems like the filtering needs to be applied to those views, yes. This would be great to have implemented (if there isnt anything in particular stopping it from being implemented) cuz its a problem that still plagues other platforms.

[hoodieak]

i just confirmed this issue still exists

[ineffyble]

There has been some commits since the 16th in this area. Could someone verify if this issue is solved?

[Gargron]

Nope, we're still not filtering on that API method atm

[wxcafe]

this is still a thing.

[Cassolotl]

I just saw and accidentally BOOSTED a toot by someone I block, in someone else's profile. This should absolutely NOT be possible!

[nynhex]

Is this still reproducible on master? I can bootstrap and try to reproduce and submit a PR.

[Cassolotl]

@nynhex It's still happening on mastodon.social!

[trwnh]

Ins't this the difference between "blocking" and "muting" someone?

Block = "I don't want you to see anything from me."
Mute = "I don't want to see anything from you."

[Cassolotl]

@trwnh When you block someone, it also mutes them.

[trwnh]

@Cassolotl so then, do toots from muted users appear when boosted? Because you can block and mute someone separately, and I have some people blocked but not muted. AFAIK I've always had to explicitly do both actions.

[Cassolotl]

@trwnh I don't know, but that's okay because this particular issue/bug report is for blocked people, and I shouldn't have to mute AND block to stop seeing someone's toots anywhere.

[Cassolotl]

Instance mod of vulpine.club said I could pass this along:

if i'm blocked by someone, it seems like i shouldn't be able to see their toots when other people boost them, except that I can

There are a whole bunch of replies from people who have given up on blocks working like they are supposed to. :S

[nightpool]

most of those replies sounded like people interacting with pleroma/gnu
social instances. pleroma doesn't support blocks and I don't know how we
can fix that except asking them to support blocks or defederating with them

On Mon, Mar 26, 2018, 1:40 PM Cassolotl [e-mail] wrote:

Instance mod of vulpine.club said I could pass this
https://vulpine.club/@mxsparks/99750775765519966 along:

if i'm blocked by someone, it seems like i shouldn't be able to see their
toots when other people boost them, except that I can

There are a whole bunch of replies from people who have given up on blocks
working like they are supposed to. :S

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/tootsuite/mastodon/issues/251#issuecomment-376250155,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAORVygTcX7EcJLeK6wMw_SHOVfdbjc5ks5tiSgdgaJpZM4K7gPD
.

[Cassolotl]

When it happens to me it's always people from other Mastodon instances. Only one replier in that thread mentions Pleroma.

[nightpool]

yeah the boosting problem is legit. I'm talking about the overall "I gave
up on things not being visible to people I blocked" sentiment

On Mon, Mar 26, 2018, 2:03 PM Cassolotl [e-mail] wrote:

When it happens to me it's always people from other Mastodon instances.
Only one replier in that thread mentions Pleroma.

—
You are receiving this because you commented.

Reply to this email directly, view it on GitHub
https://github.com/tootsuite/mastodon/issues/251#issuecomment-376257655,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAORV0xCw461mNw3ODTxsnRzk2HImDfjks5tiS1dgaJpZM4K7gPD
.

[trwnh]

Late reply / clarification to @Cassolotl : I agree you shouldn't have to mute AND block someone to stop seeing them -- muting them should do that.

If behavior changed such that blocking would ALSO mute someone, that would be a regression and a loss of functionality to me. There are some people who I want to be able to see, but who I also don't want them able to see me -- consider the case of an overzealous family member attempting to scan your social media, who you don't want to hide entirely but simply want them to not be able to see your posts. Although, this might perhaps be served better by a slightly more granular permissions model rather than a simple "hide me from them" / "hide them from me" bifurcation -- out of scope for this issue, though.

[Cassolotl]

Blocking someone also removes them from your notifications though. I don't know, I'm not super knowledgeable about this but I feel like if I have blocked someone I shouldn't be seeing them anywhere at all. I don't think I should have to mute them as well.

[trwnh]

I'm not too clear on the technical implementations either, but from a purely design standpoint, the fundamental division between a block and a mute is the direction of the hiding.

There's possibly some confusion because for some time, other networks like Twitter considered blocks and mutes to be the same thing and didn't have a separate mute function. When they added mutes, they did so as a "weaker block" -- almost like a shadowban vs. a ban on a forum (where each user's profile is their own forum).

[Cassolotl]

Gargron said in https://github.com/tootsuite/mastodon/issues/7230#issuecomment-383395486:

But: "Blocked users' toots still appear on the profiles of users who retoot them" is something completely different. It's specifically when you open someone's profile, you see everyone who they boost. And I kinda think it's supposed to be like that. If a user is boosting someone I blocked I'd rather know about it.

I feel like if you want to know if someone is boosting someone you've blocked you can open their profile in a new tab and scan their boosts, maybe?

Also, since there is no indication that someone is blocked when you're looking at their posts in someone else's profile, if someone has changed their display name or avatar since you blocked them you might not realise that someone is boosting someone you've blocked by looking at their profile anyway.

Also here https://github.com/tootsuite/mastodon/issues/7248#issuecomment-383946632:

Just tested it - yes, people who've been blocked still get notifications when you boost and like their posts and when you reply to their posts, all via the profile of someone who boosted the blocked user.

Also #7231:

The only differences between block and mute should be:

• Mutes can optionally NOT affect notifications
• Mutes should not be visible to the muted

I think this issue could be expanded to cover mutes as well as blocks, since mutes were added after this issue was created.

[mal0ki]

I want to work over how blocks and mutes display, for improved UX. The discussion here is definitely giving me some more ideas. I was thinking of bringing it up for discussion on discourse, where we can have more space to just talk, and slide off topic etc.

I have an idea, that I did put down on paper, and shared in the discord.

[trwnh]

Seems there's been a regression at some point: when muting someone and then going to the profile of another person who boosted them, I am now able to see those boosts, where previously I wasn't able to before.

Situation:
1) A boosts B.
2) I mute B from my timeline.
3) I load A's profile.

Expected behavior:
4) A's boost of B should no longer appear for me in web UI.

Actual behavior:
4) A's boost of B is still visible.
5) The context menu option reads "mute user B" as if they aren't already muted.
6) Muting B again will hide them in the web UI, but refreshing the page will bring them back.
7) Repeat Step 6 to infinity.

If I mute someone then I shouldn't have to see their posts anywhere in timelines or in profiles. Since #7231 was supposed to remove disparities between blocks and mutes, I assume the same would happen were I to block user B.

[Gargron]

Fixed this but forgot to x-reference