From b0797aedbbd7ded8bd456c647d103bfaccc12913 Mon Sep 17 00:00:00 2001 From: Matthew Hodgson Date: Sun, 11 Aug 2019 13:48:02 +0100 Subject: [PATCH 01/15] MSC for self destructing events based on lessons learned from #1763 --- proposals/2228-self-destructing-events.md | 97 +++++++++++++++++++++++ 1 file changed, 97 insertions(+) create mode 100644 proposals/2228-self-destructing-events.md diff --git a/proposals/2228-self-destructing-events.md b/proposals/2228-self-destructing-events.md new file mode 100644 index 00000000000..b539c405dd9 --- /dev/null +++ b/proposals/2228-self-destructing-events.md @@ -0,0 +1,97 @@ +# Proposal for self-destructing messages + +It's useful for users to be able to send sensitive messages within a +conversation which should be removed after the target user(s) has read them. +This can be achieved today by the sender redacting the message after the +receipient(s) have read them, but this is a tedious manual process. This +proposal provides a way of automating this process. + +Originally [MSC1763](https://github.com/matrix-org/matrix-doc/pull/1763) +attempted to solve this by applying retention limits on a per-message basis +and purging expired messages from the server; in practice this approach is +flawed because purging messages fragments the DAG, breaking back-pagination +and potentially causing performance problems. Also, the ability to set an +expiration timestamp relative to the send (rather than read) time is not of +obvious value. Therefore the concept of self-destructing messsages was +split out into this independent proposal. + +## Proposal + +Users can specify that a message should self-destruct by adding the following +field to any event's content: + +`m.self_destruct`: + the duration in seconds after which the participating servers should redact + this event on behalf of the sender, after seeing an explicit read receipt + delivered for the message from all users in the room. Must be null or in range + [0, 231-1]. If absent, or null, this behaviour does not take + effect. + +Clients and servers MUST send explicit read receipts per-message for +self-destructing messages (rather than for the most recently read message, +as is the normal operation), so that messages can be destructed as requested. + +The `m.self_destruct` field is not preserved over redaction (and +self-destructing messages may be redacted to speed up the self-destruct +process if desired). + +E2E encrypted messages must store the `m.self_destruct` field outside of the +encrypted contents of the message, given the server needs to be able to act on +it. + +## Server-side behaviour + +When a client sends a message with `m.self_destruct` true, the servers +participating in a room should start monitoring the room for read receipts for +the event in question. Once a given server has received read receipts for this +message from all members in the room (other than the sender), then the server +should redact the event, and send a synthetic `m.redaction` event to the +clients in the room on behalf of the sender. + +## Client-side behaviour + +Clients should display self-destructing events in a clearly distinguished +manner in the timeline. Details of the lifespan can be shown on demand +however, although a visible countdown is recommended. + +Clients should locally remove self-destructing events as if they have been +redacted N seconds after first attempting to send the read receipt for the +message in question. The synthetic redaction event sent by the local server +then acts as a fallback for clients which fail to implement special UI for +self-destructing messages. + +## Tradeoffs + +We could purge rather than redact destructed messages from the DB, but that +would fragment the DAG so we don't do that. + +We could have the sending server send an explicit redaction event on behalf of +the sender rather than synthesise a redaction on the various participating +servers. However, this would clog up the DAG with a redundant event, and also +introduce unreliability if the sending server is unavailable or delayed. +Therefore synthetic redaction events (which are only for backwards compatibility +anyway) feel like the lesser evil. + +## Issues + +We should probably ignore missing read receipts from bots when deciding +whether to self_destruct. This is blocked on having a good way to identify +bots. + +Should we even bother sending a redaction, versus just having all the servers +behave as if a redaction has been received? + +## Security considerations + +There's scope for abuse where users can send obnoxious self-destructing messages +into a room. + +One solution for this could be for server implementations to implement a +quarantine mode which initially marks redacted events as quarantined for N days +before deleting them entirely, allowing server admins to address abuse concerns. +This is of course true for redactions in general. + +## Conclusion + +This provides a simple and pragmatic way of automating the process of manually +redacting sensitive messages once the recipients have read them. \ No newline at end of file From 268551dd85e155bb72b71f783c0646450e67b9ff Mon Sep 17 00:00:00 2001 From: Matthew Hodgson Date: Sun, 11 Aug 2019 14:01:23 +0100 Subject: [PATCH 02/15] switch to milliseconds --- proposals/2228-self-destructing-events.md | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/proposals/2228-self-destructing-events.md b/proposals/2228-self-destructing-events.md index b539c405dd9..10d719103d4 100644 --- a/proposals/2228-self-destructing-events.md +++ b/proposals/2228-self-destructing-events.md @@ -21,11 +21,11 @@ Users can specify that a message should self-destruct by adding the following field to any event's content: `m.self_destruct`: - the duration in seconds after which the participating servers should redact - this event on behalf of the sender, after seeing an explicit read receipt - delivered for the message from all users in the room. Must be null or in range - [0, 231-1]. If absent, or null, this behaviour does not take - effect. + the duration in milliseconds after which the participating servers should + redact this event on behalf of the sender, after seeing an explicit read + receipt delivered for the message from all users in the room. Must be null + or an integer in range [0, 231-1]. If absent, or null, this + behaviour does not take effect. Clients and servers MUST send explicit read receipts per-message for self-destructing messages (rather than for the most recently read message, @@ -55,7 +55,7 @@ manner in the timeline. Details of the lifespan can be shown on demand however, although a visible countdown is recommended. Clients should locally remove self-destructing events as if they have been -redacted N seconds after first attempting to send the read receipt for the +redacted N milliseconds after first attempting to send the read receipt for the message in question. The synthetic redaction event sent by the local server then acts as a fallback for clients which fail to implement special UI for self-destructing messages. From 13e31e78d1cb415afb7586de069ef11794f907d3 Mon Sep 17 00:00:00 2001 From: Matthew Hodgson Date: Sun, 11 Aug 2019 18:40:16 +0100 Subject: [PATCH 03/15] more tradeoff --- proposals/2228-self-destructing-events.md | 5 +++++ 1 file changed, 5 insertions(+) diff --git a/proposals/2228-self-destructing-events.md b/proposals/2228-self-destructing-events.md index 10d719103d4..199f1aebcb9 100644 --- a/proposals/2228-self-destructing-events.md +++ b/proposals/2228-self-destructing-events.md @@ -72,6 +72,11 @@ introduce unreliability if the sending server is unavailable or delayed. Therefore synthetic redaction events (which are only for backwards compatibility anyway) feel like the lesser evil. +We could let the user specify an expiry time for messages relative to when +they were sent rather than when they were read. However, I can't think of a +good enough use case to justify complicating the proposal with that feature. +We can extend if/when that use case emerges. + ## Issues We should probably ignore missing read receipts from bots when deciding From c2d41c18285b91a414d5c3bd2cda04e2a14d5f57 Mon Sep 17 00:00:00 2001 From: Matthew Hodgson Date: Sun, 11 Aug 2019 18:57:47 +0100 Subject: [PATCH 04/15] switch to per-user synthetic redactions --- proposals/2228-self-destructing-events.md | 28 +++++++++++++++-------- 1 file changed, 18 insertions(+), 10 deletions(-) diff --git a/proposals/2228-self-destructing-events.md b/proposals/2228-self-destructing-events.md index 199f1aebcb9..064ab2cb617 100644 --- a/proposals/2228-self-destructing-events.md +++ b/proposals/2228-self-destructing-events.md @@ -43,10 +43,14 @@ it. When a client sends a message with `m.self_destruct` true, the servers participating in a room should start monitoring the room for read receipts for -the event in question. Once a given server has received read receipts for this -message from all members in the room (other than the sender), then the server -should redact the event, and send a synthetic `m.redaction` event to the -clients in the room on behalf of the sender. +the event in question. + +Once a given server has received a read receipt for this message from a member +in the room (other than the sender), then the message's self-destruct timer +should be started for that user. Once the timer is complete, the server +should redact the event from that member's perspective, and send the user a +synthetic `m.redaction` event in the room to the reader's clients on behalf of +the sender. ## Client-side behaviour @@ -68,9 +72,10 @@ would fragment the DAG so we don't do that. We could have the sending server send an explicit redaction event on behalf of the sender rather than synthesise a redaction on the various participating servers. However, this would clog up the DAG with a redundant event, and also -introduce unreliability if the sending server is unavailable or delayed. -Therefore synthetic redaction events (which are only for backwards compatibility -anyway) feel like the lesser evil. +introduce unreliability if the sending server is unavailable or delayed. It +would also result in all users redacting the message the same time. Therefore +synthetic per-user redaction events (which are only for backwards +compatibility anyway) feel like the lesser evil. We could let the user specify an expiry time for messages relative to when they were sent rather than when they were read. However, I can't think of a @@ -80,11 +85,14 @@ We can extend if/when that use case emerges. ## Issues We should probably ignore missing read receipts from bots when deciding -whether to self_destruct. This is blocked on having a good way to identify +whether to self-destruct. This is blocked on having a good way to identify bots. -Should we even bother sending a redaction, versus just having all the servers -behave as if a redaction has been received? +The behaviour for rooms with more than 2 participants ends up being a bit +strange. The client (and server) starts the expiry countdown on the message as +soon as the participant has read it. This means that someone can look over +the shoulder of another user to see the content again. This is probably a +feature rather than a bug(?) ## Security considerations From 8518e6249c0dafc209f5148c68fa69481cc3f366 Mon Sep 17 00:00:00 2001 From: Matthew Hodgson Date: Thu, 15 Aug 2019 00:03:18 +0100 Subject: [PATCH 05/15] mark synthetic redactions as synthetic --- proposals/2228-self-destructing-events.md | 5 +++++ 1 file changed, 5 insertions(+) diff --git a/proposals/2228-self-destructing-events.md b/proposals/2228-self-destructing-events.md index 064ab2cb617..03334bc56c5 100644 --- a/proposals/2228-self-destructing-events.md +++ b/proposals/2228-self-destructing-events.md @@ -52,6 +52,11 @@ should redact the event from that member's perspective, and send the user a synthetic `m.redaction` event in the room to the reader's clients on behalf of the sender. +The synthetic redaction event should contain some flag to show the client +that it is synthetic and used for implementing self-destruction rather than +actually sent from the claimed client. Perhaps `m.synthetic: true` on the +redaction's contents? + ## Client-side behaviour Clients should display self-destructing events in a clearly distinguished From feeff431d9fb8cfdccc20e65ae83f3853deeb6ec Mon Sep 17 00:00:00 2001 From: Matthew Hodgson Date: Fri, 16 Aug 2019 16:38:38 +0100 Subject: [PATCH 06/15] 64-bit timestamps --- proposals/2228-self-destructing-events.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/proposals/2228-self-destructing-events.md b/proposals/2228-self-destructing-events.md index 03334bc56c5..aba1e3a285d 100644 --- a/proposals/2228-self-destructing-events.md +++ b/proposals/2228-self-destructing-events.md @@ -24,7 +24,7 @@ field to any event's content: the duration in milliseconds after which the participating servers should redact this event on behalf of the sender, after seeing an explicit read receipt delivered for the message from all users in the room. Must be null - or an integer in range [0, 231-1]. If absent, or null, this + or an integer in range [0, 263-1]. If absent, or null, this behaviour does not take effect. Clients and servers MUST send explicit read receipts per-message for From ffc6d2bc41d8bcbdd1e5f95a8a41158ff9c8d2a5 Mon Sep 17 00:00:00 2001 From: Matthew Hodgson Date: Sat, 17 Aug 2019 01:26:24 +0100 Subject: [PATCH 07/15] Update proposals/2228-self-destructing-events.md Co-Authored-By: Richard van der Hoff <1389908+richvdh@users.noreply.github.com> --- proposals/2228-self-destructing-events.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/proposals/2228-self-destructing-events.md b/proposals/2228-self-destructing-events.md index aba1e3a285d..c7083de6ecb 100644 --- a/proposals/2228-self-destructing-events.md +++ b/proposals/2228-self-destructing-events.md @@ -24,7 +24,7 @@ field to any event's content: the duration in milliseconds after which the participating servers should redact this event on behalf of the sender, after seeing an explicit read receipt delivered for the message from all users in the room. Must be null - or an integer in range [0, 263-1]. If absent, or null, this + or an integer in range [0, 253-1]. If absent, or null, this behaviour does not take effect. Clients and servers MUST send explicit read receipts per-message for @@ -112,4 +112,4 @@ This is of course true for redactions in general. ## Conclusion This provides a simple and pragmatic way of automating the process of manually -redacting sensitive messages once the recipients have read them. \ No newline at end of file +redacting sensitive messages once the recipients have read them. From b54faf16103529e91c5734ced8f175e4a8bbf417 Mon Sep 17 00:00:00 2001 From: Matthew Hodgson Date: Sat, 17 Aug 2019 01:26:52 +0100 Subject: [PATCH 08/15] Update proposals/2228-self-destructing-events.md Co-Authored-By: Travis Ralston --- proposals/2228-self-destructing-events.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/proposals/2228-self-destructing-events.md b/proposals/2228-self-destructing-events.md index c7083de6ecb..a610d6873fe 100644 --- a/proposals/2228-self-destructing-events.md +++ b/proposals/2228-self-destructing-events.md @@ -41,7 +41,7 @@ it. ## Server-side behaviour -When a client sends a message with `m.self_destruct` true, the servers +When a client sends a message with `m.self_destruct` information, the servers participating in a room should start monitoring the room for read receipts for the event in question. From b8f172e540b26630d714605ef95544886dbe72da Mon Sep 17 00:00:00 2001 From: Matthew Hodgson Date: Wed, 4 Sep 2019 11:49:14 +0100 Subject: [PATCH 09/15] add notes about impermenance --- proposals/2228-self-destructing-events.md | 53 ++++++++++++++++++++++- 1 file changed, 52 insertions(+), 1 deletion(-) diff --git a/proposals/2228-self-destructing-events.md b/proposals/2228-self-destructing-events.md index a610d6873fe..ff9346c1fab 100644 --- a/proposals/2228-self-destructing-events.md +++ b/proposals/2228-self-destructing-events.md @@ -12,7 +12,7 @@ and purging expired messages from the server; in practice this approach is flawed because purging messages fragments the DAG, breaking back-pagination and potentially causing performance problems. Also, the ability to set an expiration timestamp relative to the send (rather than read) time is not of -obvious value. Therefore the concept of self-destructing messsages was +obvious value. Therefore the concept of self-destructing messsages was split out into this independent proposal. ## Proposal @@ -69,6 +69,57 @@ message in question. The synthetic redaction event sent by the local server then acts as a fallback for clients which fail to implement special UI for self-destructing messages. +Clients should warn the sender that self-destruction is based entirely on good +faith, and other servers and clients cannot be guaranteed to uphold it. +Typical text could be: + + "Warning: recipients may not honour disappearing messages". + +We recommend exposing the feature in UX as "disappearing messages" rather than +"self-destructing messages", as self-destruction implies a reliability and +permenance that the feature does not in practice provide. + +Other possible user-friendly wording might include: + * Ephemeral messages (which feels even less reliably destructive than + 'disappearing', but may be too obscure a word for a wide audience) + * Vanishing messages (which implies they reliably vanish) + * Vanishable messages (which is clunky, but more implies that it's an intent + rather than a guarantee) + * Evanescent messages (which is too obscure, but implies that it's a message + which /can/ vanish, rather than that it /will/) + * Fleeting messages (which is again quite an obscure word) + * Transient messages (too techie) + * Temporary messages (could work) + * Short-term messages + +## Threat model + +Any proposals around coordinating deletion of data (e.g. this, +[MSC1763](https://github.com/matrix-org/matrix-doc/issues/1763), +[MSC2278](https://github.com/matrix-org/matrix-doc/issues/2278)) are sensitive +because there is of course no way to stop a malicious server or client or user +ignoring the deletion and somehow retaining the data. (We consider any attempt +at trying to use DRM to do so as futile). + +This MSC is intended to: + + * Give a strong commitment to users on trusted clients and servers that + message data will not be persisted on Matrix servers and clients beyond the + requested timeframe. This is useful for legal purposes in rooms which span + only trusted (e.g. private federated) servers, to enforce data retention + behaviour. + + * Give a weak commitment to users on untrusted clients and servers (e.g. + arbitary users on the public Matrix network) that message data may not be + persisted beyond the requested timeframe. This should be adequate for + unimportant disappearing messages (e.g. a casual fleeting message which is so + unimportant or of such shortlived relevance that it is not worthy of being put + in the timeline). It is **not** adequate for attempting to ensure that + sensitive content is deleted after reading for legal or security purposes. + + * Help server admins manage diskspace by letting users dictate retention + lifetime per message. + ## Tradeoffs We could purge rather than redact destructed messages from the DB, but that From 23e80fd5eec15e45435ff7c471b29c4866cf46a4 Mon Sep 17 00:00:00 2001 From: Matthew Hodgson Date: Wed, 4 Sep 2019 12:43:18 +0100 Subject: [PATCH 10/15] handle edits and `m.synthetic` --- proposals/2228-self-destructing-events.md | 14 ++++++++++---- 1 file changed, 10 insertions(+), 4 deletions(-) diff --git a/proposals/2228-self-destructing-events.md b/proposals/2228-self-destructing-events.md index ff9346c1fab..99c48a10dca 100644 --- a/proposals/2228-self-destructing-events.md +++ b/proposals/2228-self-destructing-events.md @@ -39,6 +39,12 @@ E2E encrypted messages must store the `m.self_destruct` field outside of the encrypted contents of the message, given the server needs to be able to act on it. +Senders may edit the `m.self_destruct` field in order to retrospectively +change the intended lifetime of a message. Each new `m.replaces` event should +be considered to replace the self-destruction information (if any) on the +original, and restart the destruction timer. On destruction, the original +event (and all `m.replaces` variants of it) should be redacted. + ## Server-side behaviour When a client sends a message with `m.self_destruct` information, the servers @@ -52,10 +58,10 @@ should redact the event from that member's perspective, and send the user a synthetic `m.redaction` event in the room to the reader's clients on behalf of the sender. -The synthetic redaction event should contain some flag to show the client -that it is synthetic and used for implementing self-destruction rather than -actually sent from the claimed client. Perhaps `m.synthetic: true` on the -redaction's contents? +The synthetic redaction event should contain an `m.synthetic: true` flag on +the reaction's content to show the client that it is synthetic and used for +implementing self-destruction rather than actually sent from the claimed +client. ## Client-side behaviour From afc6d63d9bb8ab33a64b6d46bf964140c853c666 Mon Sep 17 00:00:00 2001 From: Matthew Hodgson Date: Wed, 4 Sep 2019 12:46:39 +0100 Subject: [PATCH 11/15] redactions can't self destruct --- proposals/2228-self-destructing-events.md | 3 +++ 1 file changed, 3 insertions(+) diff --git a/proposals/2228-self-destructing-events.md b/proposals/2228-self-destructing-events.md index 99c48a10dca..1a9c6fad2d0 100644 --- a/proposals/2228-self-destructing-events.md +++ b/proposals/2228-self-destructing-events.md @@ -35,6 +35,9 @@ The `m.self_destruct` field is not preserved over redaction (and self-destructing messages may be redacted to speed up the self-destruct process if desired). +The `m.self_destruct` field must be ignored on `m.redaction` events, given it +should be impossible to revert a redaction. + E2E encrypted messages must store the `m.self_destruct` field outside of the encrypted contents of the message, given the server needs to be able to act on it. From fe08d641f4224007a1646ac3319437152d3616e6 Mon Sep 17 00:00:00 2001 From: Matthew Hodgson Date: Wed, 4 Sep 2019 13:41:03 +0100 Subject: [PATCH 12/15] mention #1206 and #2199 --- proposals/2228-self-destructing-events.md | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/proposals/2228-self-destructing-events.md b/proposals/2228-self-destructing-events.md index 1a9c6fad2d0..3213a185f1f 100644 --- a/proposals/2228-self-destructing-events.md +++ b/proposals/2228-self-destructing-events.md @@ -151,7 +151,10 @@ We can extend if/when that use case emerges. We should probably ignore missing read receipts from bots when deciding whether to self-destruct. This is blocked on having a good way to identify -bots. +bots. [MSC1206](https://github.com/matrix-org/matrix-doc/pull/1206) provides +one possible way, as does +[MSC2199](https://github.com/matrix-org/matrix-doc/pull/2199) (important v. +unimportant users in immutable DMs). The behaviour for rooms with more than 2 participants ends up being a bit strange. The client (and server) starts the expiry countdown on the message as From f3f083338529dbe915146d99ef1e4637c4b829d1 Mon Sep 17 00:00:00 2001 From: Matthew Hodgson Date: Wed, 4 Sep 2019 13:54:06 +0100 Subject: [PATCH 13/15] add m.self_destruct_after for @uhoreg --- proposals/2228-self-destructing-events.md | 28 +++++++++++++++++------ 1 file changed, 21 insertions(+), 7 deletions(-) diff --git a/proposals/2228-self-destructing-events.md b/proposals/2228-self-destructing-events.md index 3213a185f1f..9d57e8f61fd 100644 --- a/proposals/2228-self-destructing-events.md +++ b/proposals/2228-self-destructing-events.md @@ -17,8 +17,8 @@ split out into this independent proposal. ## Proposal -Users can specify that a message should self-destruct by adding the following -field to any event's content: +Users can specify that a message should self-destruct by adding one or more of +the following fields to any event's content: `m.self_destruct`: the duration in milliseconds after which the participating servers should @@ -27,22 +27,28 @@ field to any event's content: or an integer in range [0, 253-1]. If absent, or null, this behaviour does not take effect. + m.self_destruct_after: + the timestamp in milliseconds since the epoch after which participating + servers should redact this event on behalf of the sender. Must be null + or an integer in range [0, 253-1]. If absent, or null, this + behaviour does not take effect. + Clients and servers MUST send explicit read receipts per-message for self-destructing messages (rather than for the most recently read message, as is the normal operation), so that messages can be destructed as requested. -The `m.self_destruct` field is not preserved over redaction (and +The `m.self_destruct` fields are not preserved over redaction (and self-destructing messages may be redacted to speed up the self-destruct process if desired). -The `m.self_destruct` field must be ignored on `m.redaction` events, given it +The `m.self_destruct` fields must be ignored on `m.redaction`events, given it should be impossible to revert a redaction. -E2E encrypted messages must store the `m.self_destruct` field outside of the +E2E encrypted messages must store the `m.self_destruct` fields outside of the encrypted contents of the message, given the server needs to be able to act on it. -Senders may edit the `m.self_destruct` field in order to retrospectively +Senders may edit the `m.self_destruct` fields in order to retrospectively change the intended lifetime of a message. Each new `m.replaces` event should be considered to replace the self-destruction information (if any) on the original, and restart the destruction timer. On destruction, the original @@ -66,18 +72,26 @@ the reaction's content to show the client that it is synthetic and used for implementing self-destruction rather than actually sent from the claimed client. +For `m.self_destruct_after`, the server should redact the event and send a +synthetic redaction once the server's localtime overtakes the timestamp given +by `m.self_destruct_after`. The server should only perform the redaction once. + ## Client-side behaviour Clients should display self-destructing events in a clearly distinguished manner in the timeline. Details of the lifespan can be shown on demand however, although a visible countdown is recommended. -Clients should locally remove self-destructing events as if they have been +Clients should locally remove `m.self_destruct` events as if they have been redacted N milliseconds after first attempting to send the read receipt for the message in question. The synthetic redaction event sent by the local server then acts as a fallback for clients which fail to implement special UI for self-destructing messages. +Clients should locally remove `m.self_destruct_after` events when the local +timestamp exceeds the timestamp indicated in the `m.self_destruct_after` +field. + Clients should warn the sender that self-destruction is based entirely on good faith, and other servers and clients cannot be guaranteed to uphold it. Typical text could be: From 831253b6b42652978153668784d7389ed0486bfc Mon Sep 17 00:00:00 2001 From: Matthew Hodgson Date: Wed, 4 Sep 2019 13:54:22 +0100 Subject: [PATCH 14/15] remove tradeoff --- proposals/2228-self-destructing-events.md | 5 ----- 1 file changed, 5 deletions(-) diff --git a/proposals/2228-self-destructing-events.md b/proposals/2228-self-destructing-events.md index 9d57e8f61fd..79f52683451 100644 --- a/proposals/2228-self-destructing-events.md +++ b/proposals/2228-self-destructing-events.md @@ -156,11 +156,6 @@ would also result in all users redacting the message the same time. Therefore synthetic per-user redaction events (which are only for backwards compatibility anyway) feel like the lesser evil. -We could let the user specify an expiry time for messages relative to when -they were sent rather than when they were read. However, I can't think of a -good enough use case to justify complicating the proposal with that feature. -We can extend if/when that use case emerges. - ## Issues We should probably ignore missing read receipts from bots when deciding From f0644a004e049409299e962794f7ccd9098f4ae1 Mon Sep 17 00:00:00 2001 From: Matthew Hodgson Date: Mon, 4 Nov 2019 15:23:22 +0000 Subject: [PATCH 15/15] Update 2228-self-destructing-events.md --- proposals/2228-self-destructing-events.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/proposals/2228-self-destructing-events.md b/proposals/2228-self-destructing-events.md index 79f52683451..626315d318a 100644 --- a/proposals/2228-self-destructing-events.md +++ b/proposals/2228-self-destructing-events.md @@ -27,7 +27,7 @@ the following fields to any event's content: or an integer in range [0, 253-1]. If absent, or null, this behaviour does not take effect. - m.self_destruct_after: +`m.self_destruct_after`: the timestamp in milliseconds since the epoch after which participating servers should redact this event on behalf of the sender. Must be null or an integer in range [0, 253-1]. If absent, or null, this