Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

MSC3840: Ignore invites #3840

Open
wants to merge 6 commits into
base: main
Choose a base branch
from
Open

MSC3840: Ignore invites #3840

Changes from all commits
Commits
Show all changes
6 commits
Select commit Hold shift + click to select a range
60094d7
MSC 3840: Ignore invites
Yoric Jun 28, 2022
f53bc19
WIP: Typo fix
Yoric Jun 29, 2022
ff031fb
WIP: Adding ignored_event_ids
Yoric Jun 30, 2022
fd918ab
WIP: Moving everything client-side
Yoric Jun 30, 2022
3531287
WIP: We need timestamps
Yoric Jul 1, 2022
124e62b
WIP: Applying feedback
Yoric Jul 7, 2022
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
84 changes: 84 additions & 0 deletions proposals/3840-ignore-invites.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,84 @@
# MSC3840: Ignoring invites
Yoric marked this conversation as resolved.
Show resolved Hide resolved

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:
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It might be good if this proposal could mention #2270 as prior art on the same topic.


- ignore invites to rooms entirely;
- ignore invites from some servers entirely.

While both features are pretty easy to implement client-side, standardizing how this preference
is stored as part of the account is necessary to make sure that users can share this ignore list
across devices and sessions.

## Proposal


Matrix currently supports a type `m.ignored_users_list` with content:

| Content | Type | Description |
|---------|------|-------------|
| `ignored_users` | A maps of user ids to `{}` | A list of users to ignore |


We adopt a similar `m.ignored_invites` with content:
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So, to achieve feature-parity with this proposal, we would need:

  1. An account data event to subscribe to policy rooms.
  2. An account data event (or an optional field on the above) to specify which policy room is the main policy room for the user.
  3. 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.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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).

Copy link
Author

@Yoric Yoric Jul 13, 2022 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Opened a variant at #3847 building upon your idea.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

m.ban has enough room in its specification to support m.ignore_invites semantics is largely my argument.


| Content | Type | Description |
|---------|------|-------------|
| `ignored_user_ids` | optional map `UserId` => `IgnoreMetadata` | Ignore invites from these users. |
| `ignored_servers` | optional map `domain` => `IgnoreMetadata` | Ignore invites from users in these homeservers. |
| `ignored_room_ids` | optional map `RoomId` => `IgnoreMetadata` | Ignore invites towards these rooms. |
| `ignored_invites` | optional map `RoomId` => map `UserId` => `IgnoreMetadata` | Ignore specific invites. |

where `IgnoreMetadata` is

| Content | Type | Description |
|------------|--------|-------------|
| `ts` | timestamp | The instant at which the invite was received. Used for visual purposes (i.e. order by most recent) and/or cleanup. |
| `reason` | optional string | A human-readable reason for ignoring the invite. |

### Client behaviour

If a user modifies `m.ignored_invites`, discard silently any matching pending invite
currently displayed.

### Server behaviour

None.

This is handled entirely client-side.

## Potential issues

### Event size

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.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This solution seems to make it quite hard to review invites that have been "ignored", how does the client review ignored invites?

Copy link
Author

@Yoric Yoric Jun 30, 2022 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.
Comment on lines +59 to +63
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm surprised this is the shape it is, ignoring users happens at the server level, why wouldn't ignoring rooms work the same?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

(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)


## Alternatives

### Server-side filtering

Just as `m.ignored_users_list` is handled mostly on the server, we could handle `m.ignored_invites`
largely on the server. However, this would make it much harder to undo erroneous ignores (i.e.
implementing some sort of recovery from trashcan) on the client.

So we prefer handling things on the client, even if this may require more traffic.

## Security considerations

Can't think of any right now.

## Unstable prefix

During testing, `m.ignored_invites` should be prefixed `org.matrix.msc3840.ignored_invites`.

Fields `ignored_user_ids`, `ignored_servers`, `ignored_room_ids` of this new event should remain unprefixed.