You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
* Fix membership state table and diagram
There were 2 missing cases which are legal:
* `invite->knock` (a fairly silly thing to do, but legal under the auth rules)
* `external->leave (via /kick)` (another somewhat silly thing to do, but no different than `external->ban (via /ban)`)
The state table considered the first as illegal, which is untrue.
* Changelog
* Make the graph prettier
* Update changelogs/client_server/newsfragments/3730.clarification
Co-authored-by: Richard van der Hoff <[email protected]>
Co-authored-by: Richard van der Hoff <[email protected]>
| **from `invite`** | No change. | User joined the room. | If the `state_key` is the same as the `sender`, the user rejected the invite. Otherwise, the `state_key` user had their invite revoked. | User was banned. | Must never happen. |
37
-
| **from `join`** | Must never happen. | `displayname` or `avatar_url` changed. | If the `state_key` is the same as the `sender`, the user left. Otherwise, the `state_key` user was kicked. | User was kicked and banned. | Must never happen. |
38
-
| **from `leave`** | New invitation sent. | User joined. | No change. | User was banned. | User is knocking. |
39
-
| **from `ban`** | Must never happen. | Must never happen. | User was unbanned. | No change. | Must never happen. |
40
-
| **from `knock`** | Knock accepted. | Must never happen. | If the `state_key` is the same as the `sender`, the user retracted the knock. Otherwise, the `state_key` user had their knock denied. | User was banned. | No change. |
34
+
| | to `invite` | to `join` | to `leave` | to `ban` | to `knock` |
| **from `invite`** | No change. | User joined the room. | If the `state_key` is the same as the `sender`, the user rejected the invite. Otherwise, the `state_key` user had their invite revoked. | User was banned. | User is re-knocking. |
37
+
| **from `join`** | Must never happen. | `displayname` or `avatar_url` changed. | If the `state_key` is the same as the `sender`, the user left. Otherwise, the `state_key` user was kicked. | User was kicked and banned. | Must never happen. |
38
+
| **from `leave`** | New invitation sent. | User joined. | No change. | User was banned. | User is knocking. |
39
+
| **from `ban`** | Must never happen. | Must never happen. | User was unbanned. | No change. | Must never happen. |
40
+
| **from `knock`** | Knock accepted. | Must never happen. | If the `state_key` is the same as the `sender`, the user retracted the knock. Otherwise, the `state_key` user had their knock denied. | User was banned. | No change. |
41
41
42
42
properties:
43
43
content:
@@ -72,7 +72,7 @@ properties:
72
72
73
73
Client and server implementations should be aware of the [signing implications](/rooms/v8/#authorization-rules) of including this
74
74
field in further events: in particular, the event must be signed by the server which
75
-
owns the user ID in the field. When copying the membership event's `content`
75
+
owns the user ID in the field. When copying the membership event's `content`
76
76
(for profile updates and similar) it is therefore encouraged to exclude this
77
77
field in the copy, as otherwise the event might fail event authorization.
0 commit comments