real-time updates of replies may not honour blocks/mutes

assigned to @dakkar

to get mutes/blocks to the frontend, we should add a semi-detailed option to UserEntityService.pack, and request that through NoteEntityService.pack from notes/show when called from use-note-capture when it receives the 'replied' event

this way we'd get isBlocked & isMuted and the frontend can act on that

or we could call users/relations from use-note-capture and cache the result, probably easier

actually we can do it better: packages/backend/src/server/api/stream/Connection.ts has a user, and it fetches userIdsWhoBlockingMe and others; the method onNoteStreamMessage should check the note's author against those lists of user ids (and yes, NoteCreateService needs to send the note.user.id along, but that's easy)

(the frontend is the wrong place for those checks, because if A blocks B, B should never see A's notes, we must not trust that they'll ignore those notes when we send them over the websocket connection!)

I (transfem.social/@NotThatDeep) can trivially reproduce this issue by muting, seemingly, any user. I noticed the problematic behaviour when I saw the reply of certain user upon visiting the parent note. I had blocked and muted the user since about 1½ weeks prior. I will follow up now with the test cases I carried out for this bug.

Note that I only tested with a user who I am following and had muted, but I did not observe any differences from the blocked and muted user case.

Viewing contexts: Home (timeline), Local (timeline), ancestors (of the note), descendants (of the note)

"Appeared" / "Did not appear" refers to the dynamic appearance of a new note while already in the viewing context.

"(In)Visible on page load" refers to the visibility of a note upon navigating to or refreshing the viewing context.

Test cases after muting a user:

User posted on the timeline
- Did not appear, invisible on page load (Home, Local)*
- Visible on page load (descendants)
User posted on the timeline, mentioning me
- Did not appear, invisible on page load (Home, Local)*
- Appeared, visible on page load (Notifications)
- Visible on page load (descendants)
User replied to a note of mine
- Did not appear, invisible on page load (Home*, Local*, Notifications)
- Appeared (ancestors)
- Visible on page load (ancestors, descendants)
User replied to a note of another user's
- Did not appear, invisible on page load (Home, Local)*
- Visible on page load (ancestors, descendants)
User boosted on the timeline
- Did not appear, invisible on page load (Home, Local)*

*I did not test the "did not appear" (dynamic) condition explicitly, but the behaviour seemed to be consistent and correct between Home and Local timelines.

Overall, I did not observe any incongruence between dynamic "appearance" and "visibility on page load".

I can provide test cases if needed, but this seems to happen regardless of who is muted. I'd prefer not to call out someone specific here.

added bug in progress labels

so, confirming:

[MS]kNoteDetailed, I can see replies from muted users
in notifications page or widget, I can not see notes from muted users, even when they mention me

which means that, at the very least, there's some mute check missing when serving replies

yep, the endpoint used is notes/children, which did not call this.queryService.generateMutedUserQuery(query, me)

of course now we need to decide: given a set of notes like this:

note1 (by me)
 |
 *- note2 (by muted)
 |   |
 |   *- note3 (by not-muted)
 |
 *- note4 (by not-muted)

when looking at note1, we definitely want to see note4, and not want to see note2, but what about note3?

as an extra data point: hard word mutes are ignored by [MS]kNote{Detailed,Sub}

I think the idea is that when you're looking at a specific note, you want to see all its parents and children… this may be a wrong idea.

maybe we should show the word-hard-muted / user-muted notes similarly to the word-muted ones, just "user said something"

also weird: if a note contains a muted word, its replies are not shown

I think that in order to maintain consistency between terminology we should rephrase soft mute of words to just being mute, and hard mute of words to be block. I know that we currently have confusion regarding what muting vs blocking is but I think that it's easier to understand. A block outright prevents you from seeing something, a mute allows you to still have it show up. I can mute my UPS alarm, but the screen will still relay to me it is off AC power. I'm tempted to go further and say we should replace "mute" with restrict. I block off access to something, that implies you cannot get access. I restrict access to something, that implies there's ways still ways to get access. Either way, we should make sure to keep things consistent in order to avoid confusing the end user.

Now, with that out of the way I think that blocking things should remain blocked, hidden from view. Soft mutes/mutes? They should still be visible but only if the user reveals them. Top post should follow this, and in the case there is a mute + reply the reply should be visible. If it's blocked -> visible reply there's not really a point in showing the user that visible reply if they cannot see the context.

note1 (by me)
 |
 *- note2 (by muted [either by word mute, or user mute])
 |   |
 |   *- note3 (by not-muted)
 |
 *- note4 (by not-muted)

note 3 should be visible

note1 (by me)
 |
 *- note2 (by blocked [either by hard mute, or user block])
 |   |
 |   *- note3 (by not-muted)
 |
 *- note4 (by not-muted)

note 3 should not be visible

At least to me the purpose of a soft mute is so that I can still interact, and see that. I'd say it is a direct equivalent of discord blocking. When you block me on discord you can open the block button. If we treat note2 and note3 as a separate post we can apply this to deeply nested threads. There's no point in showing the end user a reply chain between someone they blocked and someone else if it started by a blocked person. I argue that if you block someone you don't want to see references to them or their behavior anymore. I would not want to see a 5+ reply chain between someone I blocked and someone who is unblocked. Same applies to hard muted words, if you have a context that is showing hard muted words and the replies are related to that topic, Why would you want to see them? The blocked user only shows up if they interacted before you blocked them, it's still a possibility to end up with that in expanded view.

sorry, important detail that confuses everyone:

A blocks B: B can't see A's notes, A's profile, probably more, but A can still see B's notes! A will be notified if B mentions A!
A mutes B: A won't see most of B's notes unless A goes looking, A won't be notified if B mentions A

yes, the terminology is confusing, but it's what we currently have.

for muting, perhaps using the collapsed message that muted words uses could be utilized, like "a user you muted said something", and the message could branch off from there. for replies to said message, instead of showing the username in mentions, maybe putting [ muted ] instead of the username would work there.

Yes, I am sorry about misusing language there. I had confused what blocking and muting were supposed to accomplish on the user level. I do think that now is a good time to maintain some consistency between the user level and the word level although for organization, let's use feature requests to recommend adjustments to the behavior of user level blocks & mutes. I'll revise my diagram to remain in scope of this issue.

note1 (by me)
 |
 *- note2 (by soft muted)
 |   |
 |   *- note3 (by not-muted)

note3 should show up.

note1 (by me)
 |
 *- note2 (by hard muted)
 |   |
 |   *- note3 (by not-muted)

note2 and 3 shouldn't show up at all

note1 (by me)
 |
 *- note2 (by user who blocked me)
 |   |
 |   *- note3 (by not-muted/blocked)

note2 and 3 shouldn't show up at all

note1 (by me)
 |
 *- note2 (by user who I muted)
 |   |
 |   *- note3 (by not-muted/blocked)

note2 and 3 shouldn't show up at all

this seems more in line with the behavior dakkar was originally discussing, and is what I personally believe would be the way to handle this expanded view. Sorry for the confusion, off-topic derailment.

marked this issue as related to #573

please continue the discussion on #573 where I think I've listed all cases we care about

mentioned in merge request !566 (merged)

mentioned in commit 712af44d

closed

real-time updates of replies may not honour blocks/mutes

Designs

Child items ...

Activity

real-time updates of replies may not honour blocks/mutes

Relates to

Activity