State events from blocked users should not be shown to clients

[everypizza1]

Suggestion
In the client-server API, this is said:

Servers must still send state events sent by ignored users to clients.

Ignoring a user should imply that you won't see anything from said user, including joins, leaves, display name changes, avatar changes, etc.

[KitsuneRal]

This is problematic in case the user gets un-ignored at some later point. If state events are not sent, I as the ignoring/un-ignoring side have no idea whether that user is gone, if their display name is current etc. Clients are expected to hide all events from ignored users, but they have to keep track of what is happening to those users.

[everypizza1]

Clients are expected to hide all events from ignored users, but they have to keep track of what is happening to those users.

I haven't seen this in the spec at all, and multiple clients I've tried (gomuks, fluffychat, even element x) don't hide state events from blocked users. I also wasn't able to block users at all until conduwuit implemented it server-side in any of those clients.

[clokep]

but they have to keep track of what is happening to those users.

An option could be to always redact the state events of blocked users? I think that would allow the "room state" to maintain intact while blocking potentially abusive content from them. This would work well for joins, topics, etc.

This probably breaks down with some events though (e.g. power levels).

[olivia-fl]

The spec mentions that clients should hide historical events from ignored-users client side unless they want to do an initial sync every time a new user is ignored. I believe element implements this by just dropping all events sent by ignored users in the UI, which hides both historical events and new events sent by the server.

IMO server-side ignore was kinda a mistake in the first place, because it doesn't give clients flexibility to implement things like a "N events from an ignored user" placeholder, and requires an initial sync every time a user is unignored. I would strongly prefer clarifying that clients need to determine how state events related to ignored users are presented over expanding the scope of server-side ignore.

Some situations where clients might want varying behavior:

• an unignored user kicks, bans, or invites an ignored user. You probably want to hide these in the UI, even though they are not sent by the ignored user, and so wouldn't be covered even by the spec's current text for non-state events.
• an ignored user changes room topic, or kicks/bans/invites another user. You may want to show these, but may want to hide the name of the ignored user by default.

[olivia-fl]

Oh, just noticed another case where client-side ignore is currently needed: server-side ignore does not apply to the /messages endpoint, which is used when filling gaps in the sync timeline. Clients that don't implement client-side ignore probably have problems here, where events from ignored users are visible when scrolling back after the client was offline for a while (or when joining a new room).