From 2545ccfa17c9a208df32bc35bd509261ea182ff7 Mon Sep 17 00:00:00 2001 From: Richard van der Hoff Date: Mon, 26 Feb 2024 18:51:11 +0000 Subject: [PATCH 01/16] Proposal for membership information on events --- proposals/4115-membership-on-events.md | 131 +++++++++++++++++++++++++ 1 file changed, 131 insertions(+) create mode 100644 proposals/4115-membership-on-events.md diff --git a/proposals/4115-membership-on-events.md b/proposals/4115-membership-on-events.md new file mode 100644 index 00000000000..ace9d377b0f --- /dev/null +++ b/proposals/4115-membership-on-events.md @@ -0,0 +1,131 @@ +# MSC4115: membership metadata on events + +## Background + +Consider the following Event DAG: + +```mermaid +graph BT; + B[Bob joins]; + B-->A; + C-->A; + D-->B; + D-->C; +``` + +Bob has joined a room, but at the same time, another user has sent a message +`C`. + +Depending on the configuration of the room, Bob's server may serve the event +`C` to Bob's client. However, if the room is encrypted, Bob will not be on the +recipient list for `C` and the sender will not share the message key with Bob, +even though, in an absolute time reference, `C` may have been sent at a later +timestamp than Bob's join. + +Unfortunately, there is no way for Bob's client to reliably distinguish events +such as `A` and `C` that were sent "before" he joined (and he should therefore +not expect to decrypt) from those such as `D` that were sent later. + +This issue is discussed in more detail at +https://github.com/element-hq/element-meta/issues/2268. + +As a partial solution to this problem, we propose a mechanism for servers to +inform clients of room membership at each event. + +## Proposal + +The `unsigned` structure contains data added to an event by a homeserver when +serving an event over the client-server API. (See +[specification](https://spec.matrix.org/v1.9/client-server-api/#definition-clientevent)). + +We propose adding a new property, `membership`, which should contain the +membership of the user making the request, according to the state of the room +at the time of the event being returned. If the user had no membership at that +point (ie, they had yet to join or be invited), `membership` is set to `leave`. +Any changes caused by the event itself (ie, if the event itself is a +`m.room.member` event for the requesting user) are *excluded*. + +In other words: servers should follow the following algorithm when serving an +event E to a user Alice: + +1. Consider the room state just *before* event E landed (accounting for state + resolution accross E's `prev_events`, but not E itself). +2. Within the state, find the event M with type `m.room.member` and `state_key` + set to Alice's user ID. +3. * If no such event exists, set `membership` to `leave`. + * Otherwise, set `membership` to the value of the `membership` property of + the content of M. + +The new property should be *required* for all servers implementing a version of +the spec that includes this MSC. However, clients needing to maintain +compatibility with earlier versions of the spec will need to consider it as +optional. + +For the avoidance of doubt, the new `membership` property is added to all +Client-Server API endpoints that return events, including +[`/sync`](https://spec.matrix.org/v1.9/client-server-api/#get_matrixclientv3sync), +[`/messages`](https://spec.matrix.org/v1.9/client-server-api/#get_matrixclientv3roomsroomidmessages), +[`/state`](https://spec.matrix.org/v1.9/client-server-api/#get_matrixclientv3roomsroomidstate), +and deprecated endpoints such as +[`/events`](https://spec.matrix.org/v1.9/client-server-api/#get_matrixclientv3events) +and +[`/initialSync`](https://spec.matrix.org/v1.9/client-server-api/#get_matrixclientv3events). + + +Example event including the new property: + +```json +{ + "content": { + "membership": "join" + }, + "event_id": "$26RqwJMLw-yds1GAH_QxjHRC1Da9oasK0e5VLnck_45", + "origin_server_ts": 1632489532305, + "room_id": "!jEsUZKDJdhlrceRyVU:example.org", + "sender": "@example:example.org", + "state_key": "@user:example.org", + "type": "m.room.member", + "unsigned": { + "age": 1567437, + "membership": "leave", + "redacted_because": { + "content": { + "reason": "spam" + }, + "event_id": "$Nhl3rsgHMjk-DjMJANawr9HHAhLg4GcoTYrSiYYGqEE", + "origin_server_ts": 1632491098485, + "redacts": "$26RqwJMLw-yds1GAH_QxjHRC1Da9oasK0e5VLnck_45", + "room_id": "!jEsUZKDJdhlrceRyVU:example.org", + "sender": "@moderator:example.org", + "type": "m.room.redaction", + "unsigned": { + "membership": "leave", + "age": 1257 + } + } + } +} +``` + +## Potential issues + + * Depending on server implementation, it may be expensive or difficult to + implement? Feedback welcome from HS authors on this point. + +## Alternatives + +https://github.com/element-hq/element-meta/issues/2268#issuecomment-1904069895 +proposes use of a Bloom filter — or possibly several Bloom filters — to +mitigate this problem in a more general way. It is the opinion of the author of +this MSC that there is room for both approaches. + +## Security considerations + +None foreseen. + +## Unstable prefix + + +## Dependencies + +None. From 191e182c27beeac2775a93be35c7c44cb6223f40 Mon Sep 17 00:00:00 2001 From: Richard van der Hoff Date: Mon, 26 Feb 2024 18:52:11 +0000 Subject: [PATCH 02/16] unstable prefix --- proposals/4115-membership-on-events.md | 2 ++ 1 file changed, 2 insertions(+) diff --git a/proposals/4115-membership-on-events.md b/proposals/4115-membership-on-events.md index ace9d377b0f..c43bf80636d 100644 --- a/proposals/4115-membership-on-events.md +++ b/proposals/4115-membership-on-events.md @@ -125,6 +125,8 @@ None foreseen. ## Unstable prefix +While this proposal is in development, the name `io.element.msc4115.membership` +should be used in place of `membership`. ## Dependencies From b63d565374b2c59695121143939805cd9b2e559a Mon Sep 17 00:00:00 2001 From: Richard van der Hoff Date: Mon, 26 Feb 2024 18:57:58 +0000 Subject: [PATCH 03/16] typo --- proposals/4115-membership-on-events.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/proposals/4115-membership-on-events.md b/proposals/4115-membership-on-events.md index c43bf80636d..9d24ee9bb4a 100644 --- a/proposals/4115-membership-on-events.md +++ b/proposals/4115-membership-on-events.md @@ -49,7 +49,7 @@ In other words: servers should follow the following algorithm when serving an event E to a user Alice: 1. Consider the room state just *before* event E landed (accounting for state - resolution accross E's `prev_events`, but not E itself). + resolution across E's `prev_events`, but not E itself). 2. Within the state, find the event M with type `m.room.member` and `state_key` set to Alice's user ID. 3. * If no such event exists, set `membership` to `leave`. From 6b0776ccad3e439971983e29b2234dbf7d765043 Mon Sep 17 00:00:00 2001 From: Richard van der Hoff <1389908+richvdh@users.noreply.github.com> Date: Fri, 1 Mar 2024 14:04:02 +0000 Subject: [PATCH 04/16] Update proposals/4115-membership-on-events.md Co-authored-by: Matthew Hodgson --- proposals/4115-membership-on-events.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/proposals/4115-membership-on-events.md b/proposals/4115-membership-on-events.md index 9d24ee9bb4a..94633aa3a95 100644 --- a/proposals/4115-membership-on-events.md +++ b/proposals/4115-membership-on-events.md @@ -30,7 +30,7 @@ This issue is discussed in more detail at https://github.com/element-hq/element-meta/issues/2268. As a partial solution to this problem, we propose a mechanism for servers to -inform clients of room membership at each event. +inform clients of their room membership at each event. ## Proposal From 3ab18b52bf82f99720e8f08a2947ebbfaeee5f6e Mon Sep 17 00:00:00 2001 From: Richard van der Hoff Date: Thu, 18 Apr 2024 13:01:29 +0100 Subject: [PATCH 05/16] Update MSC4115 * Make the new property *optional*. * Describe linear-DAG situation. * Mention client-side calculation as an alternative. --- proposals/4115-membership-on-events.md | 55 ++++++++++++++++---------- 1 file changed, 35 insertions(+), 20 deletions(-) diff --git a/proposals/4115-membership-on-events.md b/proposals/4115-membership-on-events.md index 94633aa3a95..0c961b90b38 100644 --- a/proposals/4115-membership-on-events.md +++ b/proposals/4115-membership-on-events.md @@ -24,12 +24,22 @@ timestamp than Bob's join. Unfortunately, there is no way for Bob's client to reliably distinguish events such as `A` and `C` that were sent "before" he joined (and he should therefore -not expect to decrypt) from those such as `D` that were sent later. - -This issue is discussed in more detail at +not expect to decrypt) from those such as `D` that were sent later. This +situation is discussed in more detail at https://github.com/element-hq/element-meta/issues/2268. -As a partial solution to this problem, we propose a mechanism for servers to +A similar scenario can arise even in the absence of a forked DAG: clients +see events sent when the user was not in the room if the room has [History +Visibility](https://spec.matrix.org/v1.10/client-server-api/#room-history-visibility) +set to `shared`. (This is fairly common even in encrypted rooms, partly because +that is the default state for new rooms even using the `private_chat` preset +for the [`/createRoom`](https://spec.matrix.org/v1.10/client-server-api/#post_matrixclientv3createroom) +request, and also because history-sharing solutions such as +[MSC3061](https://github.com/matrix-org/matrix-spec-proposals/pull/3061) rely +on it. + +As a partial solution to the forked-DAG problem, which will also solve the +problem of historical message visibility, we propose a mechanism for servers to inform clients of their room membership at each event. ## Proposal @@ -38,15 +48,16 @@ The `unsigned` structure contains data added to an event by a homeserver when serving an event over the client-server API. (See [specification](https://spec.matrix.org/v1.9/client-server-api/#definition-clientevent)). -We propose adding a new property, `membership`, which should contain the -membership of the user making the request, according to the state of the room -at the time of the event being returned. If the user had no membership at that -point (ie, they had yet to join or be invited), `membership` is set to `leave`. -Any changes caused by the event itself (ie, if the event itself is a -`m.room.member` event for the requesting user) are *excluded*. +We propose adding a new optional property, `membership`. If returned by the +server, it should contain the membership of the user making the request, +according to the state of the room at the time of the event being returned. If +the user had no membership at that point (ie, they had yet to join or be +invited), `membership` is set to `leave`. Any changes caused by the event +itself (ie, if the event itself is a `m.room.member` event for the requesting +user) are *excluded*. -In other words: servers should follow the following algorithm when serving an -event E to a user Alice: +In other words: servers should follow the following algorithm when populating +the `unsigned.membership` property on an event E and serving it to a user Alice: 1. Consider the room state just *before* event E landed (accounting for state resolution across E's `prev_events`, but not E itself). @@ -56,10 +67,10 @@ event E to a user Alice: * Otherwise, set `membership` to the value of the `membership` property of the content of M. -The new property should be *required* for all servers implementing a version of -the spec that includes this MSC. However, clients needing to maintain -compatibility with earlier versions of the spec will need to consider it as -optional. +It is recommended that homeservers populate the new property whereever +practical, but they may omit it if necessary (for example, if calculating the +value is expensive, servers might choose to only implement it in encrypted +rooms). Clients must in any case treat the new property as optional. For the avoidance of doubt, the new `membership` property is added to all Client-Server API endpoints that return events, including @@ -114,10 +125,14 @@ Example event including the new property: ## Alternatives -https://github.com/element-hq/element-meta/issues/2268#issuecomment-1904069895 -proposes use of a Bloom filter — or possibly several Bloom filters — to -mitigate this problem in a more general way. It is the opinion of the author of -this MSC that there is room for both approaches. +1. https://github.com/element-hq/element-meta/issues/2268#issuecomment-1904069895 + proposes use of a Bloom filter — or possibly several Bloom filters — to + mitigate this problem in a more general way. It is the opinion of the author of + this MSC that there is room for both approaches. + +2. We could attempt to calculate the membership state on the client side. This + might help in a majority of cases, but it will be unreliable in the presence + of forked DAGs, state resolution, etc. ## Security considerations From bbcedf851a74e7b87ac6ab475ef61477ef03ade1 Mon Sep 17 00:00:00 2001 From: Richard van der Hoff Date: Thu, 18 Apr 2024 13:33:44 +0100 Subject: [PATCH 06/16] spleling --- proposals/4115-membership-on-events.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/proposals/4115-membership-on-events.md b/proposals/4115-membership-on-events.md index 0c961b90b38..cbe681726a4 100644 --- a/proposals/4115-membership-on-events.md +++ b/proposals/4115-membership-on-events.md @@ -67,7 +67,7 @@ the `unsigned.membership` property on an event E and serving it to a user Alice: * Otherwise, set `membership` to the value of the `membership` property of the content of M. -It is recommended that homeservers populate the new property whereever +It is recommended that homeservers populate the new property wherever practical, but they may omit it if necessary (for example, if calculating the value is expensive, servers might choose to only implement it in encrypted rooms). Clients must in any case treat the new property as optional. From 7142bc3e02ac50bc09d674818fef302437984caa Mon Sep 17 00:00:00 2001 From: Richard van der Hoff Date: Thu, 18 Apr 2024 19:02:55 +0100 Subject: [PATCH 07/16] Return state *after* the event This is much easier to calculate in Synapse. --- proposals/4115-membership-on-events.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/proposals/4115-membership-on-events.md b/proposals/4115-membership-on-events.md index cbe681726a4..c35264f01b8 100644 --- a/proposals/4115-membership-on-events.md +++ b/proposals/4115-membership-on-events.md @@ -54,13 +54,13 @@ according to the state of the room at the time of the event being returned. If the user had no membership at that point (ie, they had yet to join or be invited), `membership` is set to `leave`. Any changes caused by the event itself (ie, if the event itself is a `m.room.member` event for the requesting -user) are *excluded*. +user) are *included*. In other words: servers should follow the following algorithm when populating the `unsigned.membership` property on an event E and serving it to a user Alice: -1. Consider the room state just *before* event E landed (accounting for state - resolution across E's `prev_events`, but not E itself). +1. Consider the room state just *after* event E landed (accounting for E + itself, but not any other events in the DAG which are not ancestors of E). 2. Within the state, find the event M with type `m.room.member` and `state_key` set to Alice's user ID. 3. * If no such event exists, set `membership` to `leave`. From a28273006fb5144230146bb2089292fa5a5d632a Mon Sep 17 00:00:00 2001 From: Richard van der Hoff Date: Tue, 21 May 2024 17:44:52 +0100 Subject: [PATCH 08/16] Clarificatoins to scope of MSC --- proposals/4115-membership-on-events.md | 14 ++++++++++---- 1 file changed, 10 insertions(+), 4 deletions(-) diff --git a/proposals/4115-membership-on-events.md b/proposals/4115-membership-on-events.md index c35264f01b8..2725f7cd574 100644 --- a/proposals/4115-membership-on-events.md +++ b/proposals/4115-membership-on-events.md @@ -24,9 +24,15 @@ timestamp than Bob's join. Unfortunately, there is no way for Bob's client to reliably distinguish events such as `A` and `C` that were sent "before" he joined (and he should therefore -not expect to decrypt) from those such as `D` that were sent later. This -situation is discussed in more detail at -https://github.com/element-hq/element-meta/issues/2268. +not expect to decrypt) from those such as `D` that were sent later. + +(Aside: there are two parts to a complete resolution of this "forked-DAG" +problem. The first part is making sure that the *sender* of an encrypted event +has a clear idea of who was a member at the point of the event; the second part +is making sure that the *recipient* knows whether or not they were a member at +the point of the event and should therefore expect to receive keys for it. This +MSC deals only with the second part. The whole situation is discussed in more +detail at https://github.com/element-hq/element-meta/issues/2268.) A similar scenario can arise even in the absence of a forked DAG: clients see events sent when the user was not in the room if the room has [History @@ -36,7 +42,7 @@ that is the default state for new rooms even using the `private_chat` preset for the [`/createRoom`](https://spec.matrix.org/v1.10/client-server-api/#post_matrixclientv3createroom) request, and also because history-sharing solutions such as [MSC3061](https://github.com/matrix-org/matrix-spec-proposals/pull/3061) rely -on it. +on it.) As a partial solution to the forked-DAG problem, which will also solve the problem of historical message visibility, we propose a mechanism for servers to From 283a7e99512ef786a34f0958b3ede116f283f873 Mon Sep 17 00:00:00 2001 From: Richard van der Hoff Date: Tue, 21 May 2024 17:45:30 +0100 Subject: [PATCH 09/16] List of endpoints is incomplete --- proposals/4115-membership-on-events.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/proposals/4115-membership-on-events.md b/proposals/4115-membership-on-events.md index 2725f7cd574..4edbaea5451 100644 --- a/proposals/4115-membership-on-events.md +++ b/proposals/4115-membership-on-events.md @@ -79,7 +79,7 @@ value is expensive, servers might choose to only implement it in encrypted rooms). Clients must in any case treat the new property as optional. For the avoidance of doubt, the new `membership` property is added to all -Client-Server API endpoints that return events, including +Client-Server API endpoints that return events, including, but not limited to, [`/sync`](https://spec.matrix.org/v1.9/client-server-api/#get_matrixclientv3sync), [`/messages`](https://spec.matrix.org/v1.9/client-server-api/#get_matrixclientv3roomsroomidmessages), [`/state`](https://spec.matrix.org/v1.9/client-server-api/#get_matrixclientv3roomsroomidstate), From 638d299ecbf8976dfecd0ef35f832df459fdfff7 Mon Sep 17 00:00:00 2001 From: Richard van der Hoff Date: Tue, 21 May 2024 17:51:09 +0100 Subject: [PATCH 10/16] RFC2119 keywords --- proposals/4115-membership-on-events.md | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/proposals/4115-membership-on-events.md b/proposals/4115-membership-on-events.md index 4edbaea5451..8e58789c614 100644 --- a/proposals/4115-membership-on-events.md +++ b/proposals/4115-membership-on-events.md @@ -55,14 +55,14 @@ serving an event over the client-server API. (See [specification](https://spec.matrix.org/v1.9/client-server-api/#definition-clientevent)). We propose adding a new optional property, `membership`. If returned by the -server, it should contain the membership of the user making the request, +server, it MUST contain the membership of the user making the request, according to the state of the room at the time of the event being returned. If the user had no membership at that point (ie, they had yet to join or be invited), `membership` is set to `leave`. Any changes caused by the event itself (ie, if the event itself is a `m.room.member` event for the requesting user) are *included*. -In other words: servers should follow the following algorithm when populating +In other words: servers MUST follow the following algorithm when populating the `unsigned.membership` property on an event E and serving it to a user Alice: 1. Consider the room state just *after* event E landed (accounting for E @@ -73,10 +73,10 @@ the `unsigned.membership` property on an event E and serving it to a user Alice: * Otherwise, set `membership` to the value of the `membership` property of the content of M. -It is recommended that homeservers populate the new property wherever -practical, but they may omit it if necessary (for example, if calculating the +It is recommended that homeservers SHOULD populate the new property wherever +practical, but they MAY omit it if necessary (for example, if calculating the value is expensive, servers might choose to only implement it in encrypted -rooms). Clients must in any case treat the new property as optional. +rooms). Clients MUST in any case treat the new property as optional. For the avoidance of doubt, the new `membership` property is added to all Client-Server API endpoints that return events, including, but not limited to, @@ -147,7 +147,7 @@ None foreseen. ## Unstable prefix While this proposal is in development, the name `io.element.msc4115.membership` -should be used in place of `membership`. +MUST be used in place of `membership`. ## Dependencies From 6ef6feb71adb4cafd8ef7f7575413e01fb2dacdd Mon Sep 17 00:00:00 2001 From: Richard van der Hoff Date: Tue, 21 May 2024 17:51:16 +0100 Subject: [PATCH 11/16] Remove non-issue potential issue --- proposals/4115-membership-on-events.md | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/proposals/4115-membership-on-events.md b/proposals/4115-membership-on-events.md index 8e58789c614..3b4f451213f 100644 --- a/proposals/4115-membership-on-events.md +++ b/proposals/4115-membership-on-events.md @@ -126,8 +126,7 @@ Example event including the new property: ## Potential issues - * Depending on server implementation, it may be expensive or difficult to - implement? Feedback welcome from HS authors on this point. +None foreseen. ## Alternatives From 6db3b975f6a7793f65c235ee8a3bda47207f475b Mon Sep 17 00:00:00 2001 From: Richard van der Hoff Date: Tue, 21 May 2024 17:51:33 +0100 Subject: [PATCH 12/16] Expand on why doing it client side doesn't work --- proposals/4115-membership-on-events.md | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/proposals/4115-membership-on-events.md b/proposals/4115-membership-on-events.md index 3b4f451213f..d257a26bc74 100644 --- a/proposals/4115-membership-on-events.md +++ b/proposals/4115-membership-on-events.md @@ -137,7 +137,9 @@ None foreseen. 2. We could attempt to calculate the membership state on the client side. This might help in a majority of cases, but it will be unreliable in the presence - of forked DAGs, state resolution, etc. + of forked DAGs. It would require clients ti implement the [state resolution + algorithm](https://spec.matrix.org/v1.10/rooms/v11/#state-resolution), which + would be prohibitively complicated for most clients. ## Security considerations From b297b8b79a713db0e5982c5a808dc89a7b8b4eb5 Mon Sep 17 00:00:00 2001 From: Richard van der Hoff <1389908+richvdh@users.noreply.github.com> Date: Tue, 21 May 2024 18:38:21 +0100 Subject: [PATCH 13/16] Update proposals/4115-membership-on-events.md Co-authored-by: Patrick Cloke --- proposals/4115-membership-on-events.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/proposals/4115-membership-on-events.md b/proposals/4115-membership-on-events.md index d257a26bc74..0bab0735976 100644 --- a/proposals/4115-membership-on-events.md +++ b/proposals/4115-membership-on-events.md @@ -137,7 +137,7 @@ None foreseen. 2. We could attempt to calculate the membership state on the client side. This might help in a majority of cases, but it will be unreliable in the presence - of forked DAGs. It would require clients ti implement the [state resolution + of forked DAGs. It would require clients to implement the [state resolution algorithm](https://spec.matrix.org/v1.10/rooms/v11/#state-resolution), which would be prohibitively complicated for most clients. From 8b880df6c369663d77f67f341e16fa8e3b65bacb Mon Sep 17 00:00:00 2001 From: Richard van der Hoff <1389908+richvdh@users.noreply.github.com> Date: Wed, 22 May 2024 07:30:34 +0100 Subject: [PATCH 14/16] Update proposals/4115-membership-on-events.md --- proposals/4115-membership-on-events.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/proposals/4115-membership-on-events.md b/proposals/4115-membership-on-events.md index 0bab0735976..50532103e64 100644 --- a/proposals/4115-membership-on-events.md +++ b/proposals/4115-membership-on-events.md @@ -104,7 +104,7 @@ Example event including the new property: "type": "m.room.member", "unsigned": { "age": 1567437, - "membership": "leave", + "membership": "join", "redacted_because": { "content": { "reason": "spam" From ed20d8383e461538aca2bbfaa5d63d422bd1d990 Mon Sep 17 00:00:00 2001 From: Richard van der Hoff <1389908+richvdh@users.noreply.github.com> Date: Wed, 22 May 2024 08:52:14 +0100 Subject: [PATCH 15/16] Update proposals/4115-membership-on-events.md --- proposals/4115-membership-on-events.md | 13 +++++++------ 1 file changed, 7 insertions(+), 6 deletions(-) diff --git a/proposals/4115-membership-on-events.md b/proposals/4115-membership-on-events.md index 50532103e64..24a261de754 100644 --- a/proposals/4115-membership-on-events.md +++ b/proposals/4115-membership-on-events.md @@ -89,9 +89,9 @@ and [`/initialSync`](https://spec.matrix.org/v1.9/client-server-api/#get_matrixclientv3events). -Example event including the new property: +Example event including the new property, as seen in the response to a request made by `@user:example.org`: -```json +```json5 { "content": { "membership": "join" @@ -100,11 +100,12 @@ Example event including the new property: "origin_server_ts": 1632489532305, "room_id": "!jEsUZKDJdhlrceRyVU:example.org", "sender": "@example:example.org", - "state_key": "@user:example.org", + "state_key": "@example:example.org", "type": "m.room.member", "unsigned": { "age": 1567437, - "membership": "join", + // @user:example.org's membership at the time this event was sent + "membership": "leave", "redacted_because": { "content": { "reason": "spam" @@ -116,13 +117,13 @@ Example event including the new property: "sender": "@moderator:example.org", "type": "m.room.redaction", "unsigned": { - "membership": "leave", + // @user:example.org's membership at the time the redaction was sent + "membership": "join", "age": 1257 } } } } -``` ## Potential issues From 9323f48866920128212069330c156f6b2856ca65 Mon Sep 17 00:00:00 2001 From: Richard van der Hoff <1389908+richvdh@users.noreply.github.com> Date: Wed, 22 May 2024 14:50:32 +0100 Subject: [PATCH 16/16] fix formatting --- proposals/4115-membership-on-events.md | 1 + 1 file changed, 1 insertion(+) diff --git a/proposals/4115-membership-on-events.md b/proposals/4115-membership-on-events.md index 24a261de754..1ed8605a5c9 100644 --- a/proposals/4115-membership-on-events.md +++ b/proposals/4115-membership-on-events.md @@ -124,6 +124,7 @@ Example event including the new property, as seen in the response to a request m } } } +``` ## Potential issues