MSC3847: Ignoring invites with policy rooms

[Yoric]

Rendered

[turt2live]

initial feedback copied from MSC3840

[turt2live]

If we're introducing a new recommendation, let's shorten it to m.ignore to retain the generic nature of recommendations.

[Yoric]

Well, the objective is specifically to ignore invites. What would we gain by making it more vague?

[turt2live]

What do we gain by being overly restrictive? :P

The original design of policy rooms and the recommendation is that we would only ever need ~5 to cover everything, because we deliberately and intentionally do not assign behaviour to the recommendation - we assign ideas and suggestions. m.ignore suggests that the implementation ignore the described entity, but doesn't explain how or why that might be done. Context clues, like "here are the policy lists I want you to ignore invites from", help inform a better understanding of what to do with that policy rule/room. Making it specific just means we need more MSCs to introduce more recommendations.

[Yoric]

I don't understand the rationale.

My objective is to let users click on "ignore invites" in the UI of the client and have invites ignored. If the user clicks on "ignore invite", why would they want the client to do anything other than ignoring invites?

[turt2live]

At the UX level we wouldn't be changing anything. At the technical (spec) level, the context of "ignore these invites" comes from how the lists are used, not the explicit recommendation. We could still have a m.ban recommendation on all the rules and end up ignoring the invites: the client will have told the server that all rules in the listed policy rooms are for ignoring invites. Alternatively phrased: "please ban these entities from my invite list", "ban this room from showing up as an invite", etc

[turt2live]

it has been useful in the past, yea. It's how the original Mjolnir bot, synapse module, and Element Web implementation all did different things with exactly the same information.

[Yoric]

So, the latest version of my understanding, based on our conversation, is that "policy lists" are not about policies at all, and could just have well be named "entity lists". Also, that recommendation is actually kind of useless?

Am I correct?

[turt2live]

They're still policy lists containing rules. Eventually we want to put non-entity rules in there as well, which is where the recommendation also comes in.

The original design for policy lists included future proofing for decentralized reputation, access control, and more.

[Yoric]

I'll see what I can do.
Note that we still need the ability to have a "main" room in which to issue these rules.

[Yoric]

I've given it a few days trying to work things out on paper and I believe that, while context + rule is one way to express semantics, this is the wrong direction to head.

Option 1: One recommendation per semantics

In this case, this means adding a new recommendation m.invite.ignore or m.ignore.invite, rather than one new context of policy room.

Adding one recommendation per semantics has essentially a linear cost in terms of both specification size and cognitive load: if we want one new behavior, we add one recommendation and one paragraph in the spec.

It might make it harder to reuse lists in contexts for which they were not intended. For the time being, I don't see any real benefit to this.

Option 2: Reuse recommendations, introduce new meta-policies

By meta-policies, I mean ToS, CoC, specifying m.ignore.invites as a key in m.policies, etc.

Essentially, adding a new behavior to solve a problem means:

• either introduce a new meta-policy; or
• when a meta-policy is not sufficient to represent the expected behavior (e.g. numeric opinions, allow lists), introduce a new recommendation.

This has an explosive cost, both in terms of specification size and in terms of cognitive load:

• harder to determine whether we need to introduce a new meta-policy or a new recommendation;
• whenever we introduce either a meta-policy or a new recommendation, we need to specify all the semantics for each (meta-policy, recommendation) pair and one paragraph in the spec for each pair — or worse, not specify it at all, leaving it undocumented territory;
• similarly, when implementing a tool that works with policy lists, this means more unexpected combinations to handle, which makes it harder to write, test and trust.

Costs for both options are in addition to whatever specifications we're going to need for composition if/when policies start becoming non-trivial (e.g. allow lists and block lists, numeric opinions, etc.)

[turt2live]

I think it'd be better to make this an array, for decentralized reputation reasons.

[Yoric]

Well, the idea was to add the array as a followup MSC, for decentralized reputation reasons, and keep this MSC simpler by focusing on a single source.

Regardless of whether it's a single source or several, we need one of them to be primary. Otherwise, the client that is used to issue policy events won't know where to send these events. I suppose that I could arbitrarily pick the first from the array, but that feels really fragile.

[turt2live]

The client can make decisions about which one to post to based on how the room is structured. If someone subscribes to the code of conduct list on matrix.org then they won't have write access, but if the client sees a room that the user created then it can publish there.

Arrays are ordered in JSON, so would heavily rely on that as well.

[Yoric]

The client can make decisions about which one to post to based on how the room is structured. If someone subscribes to the code of conduct list on matrix.org then they won't have write access, but if the client sees a room that the user created then it can publish there.

Arrays are ordered in JSON, so would heavily rely on that as well.

Sure, we could make the information implicit (or even use a heuristic such as "first room in the array in which we can write state events"), but I feel that this is much more brittle. For instance, if a user suddenly becomes homeserver moderator and gains rights to the homeserver's coc room, we don't want this to accidentally change into which room they store their individual policies.

So, if we introduce an array, I strongly believe that we need to make an explicit difference between the target room and the source rooms.

[deepbluev7]

I do have some concerns regarding that, which maybe should affect the design even now:

I moderate 3 very different communities with partially shared and partially separate banlists (and one of them is a bigger community moderation effort across very different communities). In this case we currently have usually 2 different policy rooms per community, although this varies a bit. So in my case that would be 5 separate policy rooms.

Currently we only issue m.ban and having a specific list for ignores or invite ignores probably has different rules, but in general I think there needs to be a method to pick out of several policy lists as a target. This can of course have different methods, that might be useful. For example since usually community rooms are inside a space, it might make sense to pick the policy rooms for that space. This would probably be set in the room account data. Alternatively targets could be a list, where the client automatically picks the only list, if there is only one, but if there are multiple elements, it could offer a choice.

Now yes, this is out of scope for this MSC, but I think if it adds something incompatible with such goals, that might interfere with some use cases in the future?

[Yoric]

So you'd like all the users who join any room in your space to share a list of ignored invites? Or do I misunderstand?

[deepbluev7]

No, but if this is ever reused for something like m.ban, I don't want all my bans to automatically go to one list, I want it to go to different lists depending on what list I have open. I can't have a single "target" list in account data.

[Yoric]

So, if I understand correctly your concern, you're afraid that some Matrix client could start issuing policies into a community policy room (e.g. a space's CoC room) instead of your own individual policy room (e.g. the list of invites that you, as a user, don't want to see). Is that correct?

Normally, this shouldn't happen.

The idea is that all your individual bans (i.e. the bans that are expected to affect only events you receive) will go into your individual policy rooms, as specified by the target. However, your community bans (i.e. the bans that you're enacting as a moderator/admin/... for a room/a space/a server) go to their policy rooms, just as they do right now.

Unless you specifically configure your account to use a community room as your individual policy room (and I don't see any reason why someone would do that), these lists are entirely distinct. Chances are that they are going to be managed by different tools, too (your usual Matrix client for the individual policies, Mjölnir or another bot for the community policies).

Does this make sense?

[deepbluev7]

No, my concern is that this duplicates/conflicts with how I planned to have Nheko apply policy rules in the next major release, where you can define a list of target policy rooms per space to which the ban recommendations get posted. The plan was to control that by adding a policy target account data event to each space, which has a list of targets and sources from which policy rules are taken or to which the policy rules are posted.

[Yoric]

This looks complementary, no?

You're defining source/target per space, I'm defining source/target for individual users.

[deepbluev7]

Well, usually you have an inheritance change of a global default (for the account) and then finer grained settings for each space/room.

[Mikaela]

Could this MSC include requiring invite reasons to be specified for an invite to be acceptable or is that something for a future MSC that these lines speak of?

[Johennes]

It might be nice to mention #3659 here which does the filtering on the server.

[joshqou]

@Johennes Both specs aim to fix the same problem but #3659 drops invites as opposed to ignoring them. imo dropping invites is better than a client-side ignore since it wouldn't require all a user's clients to support the spec, even if such behaviour is more "destructive".

[Johennes]

Sorry, I merely meant to say that mentioning #3659 here would be nice for context on prior art, not necessarily that I'd prefer one over the other. On that matter, filtering invites on the server sounds more efficient but it won't allow you to review ignored invites (and possibly even unignore them). So both seem to have pros and cons.

[joshqou]

Literal rule matches can be filtered out using a sync filter

[turt2live]

Overall: Based on #4192, I feel as though this MSC would be best positioned as an extension to #4155 rather than being a dedicated mechanism (for the parts that aren't already covered).

[Half-Shot]

I think in practice this means:

• m.policies is no longer a dedicated event, but a key under m.invite_permission_config.
• Policies should be evaluated after the other rules. Both so users can set their own overrides, and for efficiency.
• This should be evaluated on the server, too.