From b12ae325da15bc005293756a1c1764e4df65935e Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Erkin=20Alp=20G=C3=BCney?= Date: Sun, 7 Mar 2021 10:13:33 +0300 Subject: [PATCH 1/6] Per-room limits MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Signed-off by: Erkin Alp Güney --- proposals/3053-per-room-limits.md | 77 +++++++++++++++++++++++++++++++ 1 file changed, 77 insertions(+) create mode 100644 proposals/3053-per-room-limits.md diff --git a/proposals/3053-per-room-limits.md b/proposals/3053-per-room-limits.md new file mode 100644 index 00000000000..b2f03b9a025 --- /dev/null +++ b/proposals/3053-per-room-limits.md @@ -0,0 +1,77 @@ +# MSC3053: Limits API — Part 2: per-Room Fanout and Complexity Limits + +Not all servers are as lucky as matrix.org to have variable scaling, +hence some of them will need to place fanout limits on users and rooms, +such as how many rooms a user is allowed to be member of, how many members can +a room simultaneously have, how may child rooms a space room is allowed +to have, or how many sessions a user is allowed to have simultaneously open. +This MSC deals with per-room fanout and complexity limits. + +## The basics + +Per-room fanout limit means a limit imposed on a particular room, across +all participating server instances. Room complexity limit means a limit +imposed across some or all rooms in a particular instance. Room complexity +limit is only an upper bound and a server may choose to implement +a lower limit than one set by this API. + +To modify the limit of a particular room: +``` +PUT /_matrix/client/r0/admin/limits/{room_id} HTTP/1.1 +{ + "type": "m.limits.complexity.user_cap", + "value": 123456789 +} +``` + +To modify the limits of all rooms: +``` +PUT /_matrix/client/r0/admin/limits/ HTTP/1.1 +{ + "type": "m.limits.complexity.user_cap", + "value": 123456789 +} +``` + +The modify the user limit of room across servers, this state event shall be +sent to the room: +``` +{ + "type": "m.limits.fanout.room_users", + "value": 123456789 +} +``` + +If `value` is not defined, then said limit is not defined. + +The query will be made to the same paths, using the GET method instead. +And to delete the limit for the particular user, use the DELETE method +for the same path. A user is allowed to query users from own homeserver only. +If, a server-wide limit is defined but a user specific limit is not, +the user specific limit shall be returned as if it were the same. In case +both limits exist, the smaller limit for a given user shall apply. + +For now, two such limits are proposed: + +* Per-room user fanout limit: `m.limits.fanout.room_users` +* Per-room user complexity limit: `m.limits.complexity.user_cap` +* * Per-room-as-type user complexity limit: `m.limits.complexity.room_users.{room_type}` +## The per-room user limit semantics + +A room shall not be allowed to have more members once it has as many members as +specified by the per-room user limit. The join requests will be rejected, +invites overturned and knocks ignored by the server. As soon as the number of +rooms user has joined drops below the limit, joins will be processed as usual. + +If a room has more users than it is allowed to be joined when the limit is put +in place, then the join of exceeding users shall be undone according to +the state resolution order, but only to the point of the limit request, +and no further. If a limit for a particular type of room exists, that limit +shall only be considered for that type of room. For example, +`m.limits.complexity.room_users.space` will only affect space rooms and +not bare rooms. If the limit for a subtype of room is greater than +the general user limit per room, the subtype limit will be ignored. +To set per-room user fanout limit, user has to have power to `limits`. +The power level required for `limits` shall be greater than or equal to +the greatest of the power level required for `invite`, `redact`, `ban`, +`power_levels`. From 967be6d4f00cafff55cb548e9f8c7df3b1794173 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Erkin=20Alp=20G=C3=BCney?= Date: Sun, 7 Mar 2021 21:44:57 +0300 Subject: [PATCH 2/6] Room nesting limits MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Signed-off by: Erkin Alp Güney --- proposals/3053-per-room-limits.md | 35 +++++++++++++++++++++++++------ 1 file changed, 29 insertions(+), 6 deletions(-) diff --git a/proposals/3053-per-room-limits.md b/proposals/3053-per-room-limits.md index b2f03b9a025..21766fc22be 100644 --- a/proposals/3053-per-room-limits.md +++ b/proposals/3053-per-room-limits.md @@ -42,20 +42,28 @@ sent to the room: } ``` -If `value` is not defined, then said limit is not defined. +If `value` is not defined, then said limit is not defined either. The query will be made to the same paths, using the GET method instead. And to delete the limit for the particular user, use the DELETE method for the same path. A user is allowed to query users from own homeserver only. -If, a server-wide limit is defined but a user specific limit is not, -the user specific limit shall be returned as if it were the same. In case -both limits exist, the smaller limit for a given user shall apply. +If, a server-wide limit is defined but a room specific limit is not, +the room specific limit shall be returned as if it were the same. In case +both limits exist, the smaller limit for a given room shall apply. -For now, two such limits are proposed: +For now, four such limits are proposed: * Per-room user fanout limit: `m.limits.fanout.room_users` +* Immediate child room nesting limit: `m.limits.fanout.room_children` +* Inherited child room nesting limit: `m.limits.fanout.room_branching` +* Descendant room nesting limit: `m.limits.fanout.room_rooms` * Per-room user complexity limit: `m.limits.complexity.user_cap` -* * Per-room-as-type user complexity limit: `m.limits.complexity.room_users.{room_type}` + * Per-room-as-type user complexity limit: `m.limits.complexity.user_cap.{room_type}` + +Room limits specified as sub-keys of `m.limits.fanout` are sent as state events, +and room limits specified as subkeys of `m.limits.complexity` are sent as admin +API settings, as shown above by user capping example. + ## The per-room user limit semantics A room shall not be allowed to have more members once it has as many members as @@ -75,3 +83,18 @@ To set per-room user fanout limit, user has to have power to `limits`. The power level required for `limits` shall be greater than or equal to the greatest of the power level required for `invite`, `redact`, `ban`, `power_levels`. + +## Room nesting limit semantics + +A room shall not be allowed to have more child rooms once it has as many children +as specified by the child limit. New child rooms will not be added. As soon as +the number of child rooms drops below the limit, joins will be processed as usual. + +* Immediate child room nesting limit only affects direct children of said rooms. +* Inherited child room limit affects direct children of said rooms, and + is recursively applied to child rooms. +* Descendant room nesting limit affects all descendants of said rooms. + +If the limit for a subtype of room is greater than the general nesting limit +per room, the subtype limit will be ignored. To set per-room nesting limit, +user has to have power to `tombstone` and `attach`. From 0c59940aa33fa78256451355128e7c40395aeef7 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Erkin=20Alp=20G=C3=BCney?= Date: Thu, 13 May 2021 21:26:31 +0300 Subject: [PATCH 3/6] Add the forgotten state key MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Signed-off by: Erkin Alp Güney --- proposals/3053-per-room-limits.md | 14 ++++++++------ 1 file changed, 8 insertions(+), 6 deletions(-) diff --git a/proposals/3053-per-room-limits.md b/proposals/3053-per-room-limits.md index 21766fc22be..dcf2ec23a6e 100644 --- a/proposals/3053-per-room-limits.md +++ b/proposals/3053-per-room-limits.md @@ -38,6 +38,7 @@ sent to the room: ``` { "type": "m.limits.fanout.room_users", + "state_key": "user_cap", "value": 123456789 } ``` @@ -51,14 +52,15 @@ If, a server-wide limit is defined but a room specific limit is not, the room specific limit shall be returned as if it were the same. In case both limits exist, the smaller limit for a given room shall apply. -For now, four such limits are proposed: +For now, four such limits are proposed (with event types and state keys respectively): -* Per-room user fanout limit: `m.limits.fanout.room_users` -* Immediate child room nesting limit: `m.limits.fanout.room_children` -* Inherited child room nesting limit: `m.limits.fanout.room_branching` -* Descendant room nesting limit: `m.limits.fanout.room_rooms` -* Per-room user complexity limit: `m.limits.complexity.user_cap` +* Per-room user fanout limit: `m.limits.fanout.room_users` / `users` +* Immediate child room nesting limit: `m.limits.fanout.room_children` / `children` +* Inherited child room nesting limit: `m.limits.fanout.room_branching` / `branches` +* Descendant room nesting limit: `m.limits.fanout.room_rooms` / `room_rooms` +* Per-room user complexity limit: `m.limits.complexity.user_cap` / `user_cap` * Per-room-as-type user complexity limit: `m.limits.complexity.user_cap.{room_type}` + / not applicable to room state events Room limits specified as sub-keys of `m.limits.fanout` are sent as state events, and room limits specified as subkeys of `m.limits.complexity` are sent as admin From 13c63f98b7b06b1a34963ef9749e8f33691313f2 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Erkin=20Alp=20G=C3=BCney?= Date: Thu, 3 Jun 2021 23:55:19 +0300 Subject: [PATCH 4/6] Security considerations added MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Signed-off by: Erkin Alp Güney --- proposals/3053-per-room-limits.md | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/proposals/3053-per-room-limits.md b/proposals/3053-per-room-limits.md index dcf2ec23a6e..5912b53b5c0 100644 --- a/proposals/3053-per-room-limits.md +++ b/proposals/3053-per-room-limits.md @@ -100,3 +100,7 @@ the number of child rooms drops below the limit, joins will be processed as usua If the limit for a subtype of room is greater than the general nesting limit per room, the subtype limit will be ignored. To set per-room nesting limit, user has to have power to `tombstone` and `attach`. + +## Security considerations + +Misuse of this feature might cause permanently forking a room. From 9c45d17b3bda89bdef0bd66a449c594de76e9099 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Erkin=20Alp=20G=C3=BCney?= Date: Sun, 13 Jun 2021 20:10:18 +0300 Subject: [PATCH 5/6] Alternatives added MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Signed-off by: Erkin Alp Güney --- proposals/3053-per-room-limits.md | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/proposals/3053-per-room-limits.md b/proposals/3053-per-room-limits.md index 5912b53b5c0..57d214a59b3 100644 --- a/proposals/3053-per-room-limits.md +++ b/proposals/3053-per-room-limits.md @@ -101,6 +101,12 @@ If the limit for a subtype of room is greater than the general nesting limit per room, the subtype limit will be ignored. To set per-room nesting limit, user has to have power to `tombstone` and `attach`. +## Alternatives considered + +Having those limits as permanent limits specified as fields in the `m.room.create` +event of the respective room (Later changed the plans to bring this forward as +another MSC, as an orthogonal feature with changeable ones). + ## Security considerations Misuse of this feature might cause permanently forking a room. From 42413e3faf659e8b832ce58cfa469a65196f37a9 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Erkin=20Alp=20G=C3=BCney?= Date: Sun, 13 Jun 2021 20:21:20 +0300 Subject: [PATCH 6/6] Unstable prefix and room version added MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Signed-off by: Erkin Alp Güney --- proposals/3053-per-room-limits.md | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/proposals/3053-per-room-limits.md b/proposals/3053-per-room-limits.md index 57d214a59b3..5315ededa78 100644 --- a/proposals/3053-per-room-limits.md +++ b/proposals/3053-per-room-limits.md @@ -110,3 +110,9 @@ another MSC, as an orthogonal feature with changeable ones). ## Security considerations Misuse of this feature might cause permanently forking a room. + +## Unstable prefix and room version + +As this feature requires a new room version, `org.matrix.msc3053.limits` can be +used as the unstable room version. And `r0` should be replaced by `unstable` for +unstable endpoint paths.