MSC3840: Ignore invites #3840
MSC3840: Ignore invites #3840
Conversation
Signed-off: David Teller <davidt@element.io>
Yoric
force-pushed
the
yoric/ignored-rooms
branch
from
ffa4b4b
to
60094d7
Compare
|
(sign off on this is not required because it's done with a matrix.org hat automatically, not an element.io one) |
turt2live
added
proposal
| There is a risk that the list of ignored invites of some users may grow a lot, which might have | ||
| performance impact, both during initial sync and during filtering. We believe that this risk is | ||
| limited. If necessary, clients may decide to cleanup ignored invites after some time. | ||
|
|
There was a problem hiding this comment.
This solution seems to make it quite hard to review invites that have been "ignored", how does the client review ignored invites?
There was a problem hiding this comment.
My personal take on it is that each client may additionally cache a list of individual event_ids for invites that have been ignored, without needing to share it. But now that you mention it, this probably doesn't make sense, as we want to ignore invites across all devices/sessions.
Patching.
There was a problem hiding this comment.
So, the latest version adds ignored_event_ids to give users the ability to ignore individual invites across clients. However, it's not entirely clear to me whether this is sufficient to inspect, as the invites are going to be filtered by the server.
| ### Sync size | ||
|
|
||
| With this proposal, the server will repeat invites at each `/sync`. In time, this can grow expensive. | ||
|
|
||
| If necessary, clients may decide to convert ignored invites into rejected invites after a while. |
There was a problem hiding this comment.
I'm surprised this is the shape it is, ignoring users happens at the server level, why wouldn't ignoring rooms work the same?
There was a problem hiding this comment.
(FTR I have made an attempt to show what it would look like on the server, but it's not very serious yet matrix-org/synapse#13177)
Turning fields of `m.ignored_invites` into a map instead of (essentially) a list of tuples. This guarantees unicity and may simplify implementation.
| | `ignored_users` | A maps of user ids to `{}` | A list of users to ignore | | ||
|
|
||
|
|
||
| We adopt a similar `m.ignored_invites` with content: |
There was a problem hiding this comment.
this looks very close to what a policy room offers. We could adapt this sort of account data to support a list of policy rooms which the server can inspect for rules and apply them on behalf of the user. If needed, the user/client could also create a private policy room to share with the server via account data to hold some of the personal rules.
Future extensions would be adding recommendations for m.block and m.ignore (to outright error and consume invites, respectively), but for now the m.ban recommendation is probably good enough.
There was a problem hiding this comment.
So, to achieve feature-parity with this proposal, we would need:
- An account data event to subscribe to policy rooms.
- An account data event (or an optional field on the above) to specify which policy room is the main policy room for the user.
- A new recommendation
m.ignore_invites.
Right? On the downside, it's going to be harder to implement and slower, but on the upside it's going to be more orthogonal and extensible. I can write the spec for that.
There was a problem hiding this comment.
I think you just need point 1. Point 2 isn't really needed, and point 3 adds complexity we might not be comfortable with introducing here (it adds time).
There was a problem hiding this comment.
I don't understand your reasoning:
- point 3 is the sole objective here – we really, really want to give users the ability to ignore invites;
- without point 2, I don't see how users can publish their own policies from a client.
The way I see it, if anything, point 1 is the one that we could live with for a MVP.
There was a problem hiding this comment.
Opened a variant at #3847 building upon your idea.
There was a problem hiding this comment.
m.ban has enough room in its specification to support m.ignore_invites semantics is largely my argument.
|
|
||
| Matrix supports an event "m.ignored_user_list" to entirely ignore some users. | ||
|
|
||
| In some cases, ignoring the user is the wrong granularity, e.g. we may wish to: |
There was a problem hiding this comment.
It might be good if this proposal could mention #2270 as prior art on the same topic.
Rendered