From ad720c410eb403e9c064cfcf2b541c490fb295d2 Mon Sep 17 00:00:00 2001 From: Johannes Renkl Date: Fri, 31 Jul 2020 03:47:38 +0200 Subject: [PATCH 1/7] Very early draft of forward info proposal --- proposals/2714-add-forward-info.md | 81 ++++++++++++++++++++++++++++++ 1 file changed, 81 insertions(+) create mode 100644 proposals/2714-add-forward-info.md diff --git a/proposals/2714-add-forward-info.md b/proposals/2714-add-forward-info.md new file mode 100644 index 000000000..3d75c5a25 --- /dev/null +++ b/proposals/2714-add-forward-info.md @@ -0,0 +1,81 @@ +# MSC2714: Add forward information to forwarded messages + +Currently a forwarded message is not easily recognized as a forwarded message. While for messages of `msgtype` `m.text`, `m.emote` and `m.notice` clients could do something in the `formatted_body` of `content`, for all other message types the forward highlighting would be very poor. To get around this and provide a guideline to clients which information should go with a forward, we suggest adding the "forward info" explicitly. See also https://github.com/vector-im/riot-web/issues/4747. + +## Proposal + +### Extending info + +``` +{ + "content": { + "body": "Big Ben, London, UK", + "geo_uri": "geo:51.5008,0.1247", + "info": { + "forward_info": { + "event_id": "$123275682943PhrSn:example.org", + "room_id": "!jEsTZKDJdhfrheTzSU:example.org", + "sender": "@someone:example.org", + "origin_server_ts": 1432735824141 + } + }, + "msgtype": "m.location" + }, + "event_id": "$143273582443PhrSn:example.org", + "origin_server_ts": 1432735824653, + "room_id": "!jEsUZKDJdhlrceRyVU:example.org", + "sender": "@example:example.org", + "type": "m.room.message", + "unsigned": { + "age": 1234 + } +} +``` + +### Providing m.forward + +``` +{ + "content": { + "body": "Big Ben, London, UK", + "geo_uri": "geo:51.5008,0.1247", + "m.forward": { + "event_id": "$123275682943PhrSn:example.org", + "room_id": "!jEsTZKDJdhfrheTzSU:example.org", + "sender": "@someone:example.org", + "origin_server_ts": 1432735824141 + }, + "msgtype": "m.location" + }, + "event_id": "$143273582443PhrSn:example.org", + "origin_server_ts": 1432735824653, + "room_id": "!jEsUZKDJdhlrceRyVU:example.org", + "sender": "@example:example.org", + "type": "m.room.message", + "unsigned": { + "age": 1234 + } +} +``` + + +## Potential issues + + + +## Alternatives + +We've also discussed and discarded usind `m_relates_to` for highlighting the message as forward, like the following: + +``` +"m.relates_to": { + "rel_type": "m.forwarded", + "event_id": "!1234:server.abc", +} +``` + +We discarded this idea for two reasons: + +1. The idea of `m.relates_to` seems to be that related messages belong to the same room. +2. Its unclear who should fetch the event from a different room she/he/it is potentially not in and how this could be done at all. + From 29c7cb99820d8875116f6bb3f425d504d2fa29f5 Mon Sep 17 00:00:00 2001 From: Johannes Renkl Date: Fri, 31 Jul 2020 04:08:25 +0200 Subject: [PATCH 2/7] This and that --- proposals/2714-add-forward-info.md | 46 +++++++++++++++++------------- 1 file changed, 26 insertions(+), 20 deletions(-) diff --git a/proposals/2714-add-forward-info.md b/proposals/2714-add-forward-info.md index 3d75c5a25..e44b7957f 100644 --- a/proposals/2714-add-forward-info.md +++ b/proposals/2714-add-forward-info.md @@ -4,20 +4,19 @@ Currently a forwarded message is not easily recognized as a forwarded message. W ## Proposal -### Extending info +### Providing m.forward + +Leaning onto edits (adding `m.new_content` inside `content`), we want to suggest to add `m.forwarded` to `content` to forwarded messages. The required information would cover at least the original `senden`, `room_id` and `origin_server_ts`: ``` { "content": { "body": "Big Ben, London, UK", "geo_uri": "geo:51.5008,0.1247", - "info": { - "forward_info": { - "event_id": "$123275682943PhrSn:example.org", - "room_id": "!jEsTZKDJdhfrheTzSU:example.org", - "sender": "@someone:example.org", - "origin_server_ts": 1432735824141 - } + "m.forward": { + "room_id": "!jEsTZKDJdhfrheTzSU:example.org", + "sender": "@someone:example.org", + "origin_server_ts": 1432735824141 }, "msgtype": "m.location" }, @@ -32,18 +31,28 @@ Currently a forwarded message is not easily recognized as a forwarded message. W } ``` -### Providing m.forward +Additional infos could be the original `event_id`, `displayname` and `avatar_url` (optionally?). + +## Potential issues + +Should we care of/can we avoid "fake forwards"? Does it make sense/is it possible at all to only add the original `event_id` when sending a forward and assign the server the responsibility of adding the forward information? + +## Alternatives + +### Extending info ``` { "content": { "body": "Big Ben, London, UK", "geo_uri": "geo:51.5008,0.1247", - "m.forward": { - "event_id": "$123275682943PhrSn:example.org", - "room_id": "!jEsTZKDJdhfrheTzSU:example.org", - "sender": "@someone:example.org", - "origin_server_ts": 1432735824141 + "info": { + "forward_info": { + "event_id": "$123275682943PhrSn:example.org", + "room_id": "!jEsTZKDJdhfrheTzSU:example.org", + "sender": "@someone:example.org", + "origin_server_ts": 1432735824141 + } }, "msgtype": "m.location" }, @@ -58,12 +67,7 @@ Currently a forwarded message is not easily recognized as a forwarded message. W } ``` - -## Potential issues - - - -## Alternatives +### Discarded using m.relates_to We've also discussed and discarded usind `m_relates_to` for highlighting the message as forward, like the following: @@ -79,3 +83,5 @@ We discarded this idea for two reasons: 1. The idea of `m.relates_to` seems to be that related messages belong to the same room. 2. Its unclear who should fetch the event from a different room she/he/it is potentially not in and how this could be done at all. + +See also our discussion here https://gitlab.com/famedly/app/-/issues/320. From d8d66280b115c870ae6cfa03e2199181b967d3ee Mon Sep 17 00:00:00 2001 From: Johannes Renkl Date: Wed, 12 Aug 2020 15:46:04 +0200 Subject: [PATCH 3/7] Details about resolving displayname and avatar --- proposals/2714-add-forward-info.md | 15 +++++++++++++-- 1 file changed, 13 insertions(+), 2 deletions(-) diff --git a/proposals/2714-add-forward-info.md b/proposals/2714-add-forward-info.md index e44b7957f..1805ec39d 100644 --- a/proposals/2714-add-forward-info.md +++ b/proposals/2714-add-forward-info.md @@ -31,10 +31,21 @@ Leaning onto edits (adding `m.new_content` inside `content`), we want to suggest } ``` -Additional infos could be the original `event_id`, `displayname` and `avatar_url` (optionally?). +Additional the original `event_id` could be added. ## Potential issues +### Resolving display name and avatar +Since the receiver (of a forward) may not be in the room, the message has originally been posted to, he may not be able to get the original sender's `displayname` and `avatar_url` from `/_matrix/client/r0/rooms/{roomId}/members`. + +We see two possible solutions at the moment: + +1. The forwarder adds `displayname` and `avatar_url` to `m.forward`. +2. The receiving client resolves the `displayname` and the `avatar_url` from the user id given by `sender` using `/_matrix/client/r0/profile/{userId}`. + +Both solutions have a drawback. In case of 1., changing the display name or the avatar would not be reflected in forwards. And the avatar URL may even become invalid(?). The second solution may cause confusion is the original sender has set different display names and avatars for different rooms. I.e. if the original sender is in the room where the message is forwarded to, it may appear there under a different display name and avatar. + +### Clients can fake forwards Should we care of/can we avoid "fake forwards"? Does it make sense/is it possible at all to only add the original `event_id` when sending a forward and assign the server the responsibility of adding the forward information? ## Alternatives @@ -67,7 +78,7 @@ Should we care of/can we avoid "fake forwards"? Does it make sense/is it possibl } ``` -### Discarded using m.relates_to +### Discarded: Using m.relates_to We've also discussed and discarded usind `m_relates_to` for highlighting the message as forward, like the following: From 6c20d8926e3d2fc0dbfea755a7aede0953c94d68 Mon Sep 17 00:00:00 2001 From: Johannes Renkl Date: Wed, 12 Aug 2020 16:05:53 +0200 Subject: [PATCH 4/7] According to review by @sorunome - m.forward -> m.forwarded - added unstable prefix section - added event_id --- proposals/2714-add-forward-info.md | 9 ++++++--- 1 file changed, 6 insertions(+), 3 deletions(-) diff --git a/proposals/2714-add-forward-info.md b/proposals/2714-add-forward-info.md index 1805ec39d..aa1dc82e6 100644 --- a/proposals/2714-add-forward-info.md +++ b/proposals/2714-add-forward-info.md @@ -13,7 +13,8 @@ Leaning onto edits (adding `m.new_content` inside `content`), we want to suggest "content": { "body": "Big Ben, London, UK", "geo_uri": "geo:51.5008,0.1247", - "m.forward": { + "m.forwarded": { + "event_id": "$123275682943PhrSn:example.org", "room_id": "!jEsTZKDJdhfrheTzSU:example.org", "sender": "@someone:example.org", "origin_server_ts": 1432735824141 @@ -40,7 +41,7 @@ Since the receiver (of a forward) may not be in the room, the message has origin We see two possible solutions at the moment: -1. The forwarder adds `displayname` and `avatar_url` to `m.forward`. +1. The forwarder adds `displayname` and `avatar_url` to `m.forwarded`. 2. The receiving client resolves the `displayname` and the `avatar_url` from the user id given by `sender` using `/_matrix/client/r0/profile/{userId}`. Both solutions have a drawback. In case of 1., changing the display name or the avatar would not be reflected in forwards. And the avatar URL may even become invalid(?). The second solution may cause confusion is the original sender has set different display names and avatars for different rooms. I.e. if the original sender is in the room where the message is forwarded to, it may appear there under a different display name and avatar. @@ -79,7 +80,6 @@ Should we care of/can we avoid "fake forwards"? Does it make sense/is it possibl ``` ### Discarded: Using m.relates_to - We've also discussed and discarded usind `m_relates_to` for highlighting the message as forward, like the following: ``` @@ -94,5 +94,8 @@ We discarded this idea for two reasons: 1. The idea of `m.relates_to` seems to be that related messages belong to the same room. 2. Its unclear who should fetch the event from a different room she/he/it is potentially not in and how this could be done at all. +## Unstable prefix +Clients can implement this feature with the unstable prefix `com.famedly.app.forwarded` onstead of `m.forwarded` until this MSC gets merged. + See also our discussion here https://gitlab.com/famedly/app/-/issues/320. From 110bd6ab3c628656750a60dd3e69a22c621651d5 Mon Sep 17 00:00:00 2001 From: Johannes Renkl Date: Wed, 12 Aug 2020 16:11:11 +0200 Subject: [PATCH 5/7] Rename according to pull request number --- .../{2714-add-forward-info.md => 2717-add-forward-info.md} | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) rename proposals/{2714-add-forward-info.md => 2717-add-forward-info.md} (98%) diff --git a/proposals/2714-add-forward-info.md b/proposals/2717-add-forward-info.md similarity index 98% rename from proposals/2714-add-forward-info.md rename to proposals/2717-add-forward-info.md index aa1dc82e6..030f8a8e6 100644 --- a/proposals/2714-add-forward-info.md +++ b/proposals/2717-add-forward-info.md @@ -1,4 +1,4 @@ -# MSC2714: Add forward information to forwarded messages +# MSC2717: Add forward information to forwarded messages Currently a forwarded message is not easily recognized as a forwarded message. While for messages of `msgtype` `m.text`, `m.emote` and `m.notice` clients could do something in the `formatted_body` of `content`, for all other message types the forward highlighting would be very poor. To get around this and provide a guideline to clients which information should go with a forward, we suggest adding the "forward info" explicitly. See also https://github.com/vector-im/riot-web/issues/4747. From 26e35243707dc29fc68c8a2cb18476b68d996216 Mon Sep 17 00:00:00 2001 From: Johannes Renkl Date: Wed, 12 Aug 2020 16:15:41 +0200 Subject: [PATCH 6/7] Okay, guessed PR number wasn't right, fixed it --- .../{2717-add-forward-info.md => 2723-add-forward-info.md} | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) rename proposals/{2717-add-forward-info.md => 2723-add-forward-info.md} (98%) diff --git a/proposals/2717-add-forward-info.md b/proposals/2723-add-forward-info.md similarity index 98% rename from proposals/2717-add-forward-info.md rename to proposals/2723-add-forward-info.md index 030f8a8e6..81185a7c6 100644 --- a/proposals/2717-add-forward-info.md +++ b/proposals/2723-add-forward-info.md @@ -1,4 +1,4 @@ -# MSC2717: Add forward information to forwarded messages +# MSC2723: Add forward information to forwarded messages Currently a forwarded message is not easily recognized as a forwarded message. While for messages of `msgtype` `m.text`, `m.emote` and `m.notice` clients could do something in the `formatted_body` of `content`, for all other message types the forward highlighting would be very poor. To get around this and provide a guideline to clients which information should go with a forward, we suggest adding the "forward info" explicitly. See also https://github.com/vector-im/riot-web/issues/4747. From acea0854a1c9489599295a858b068ce02a6b2b20 Mon Sep 17 00:00:00 2001 From: Johannes Renkl Date: Wed, 12 Aug 2020 17:06:04 +0200 Subject: [PATCH 7/7] Easy fixes according to review - fixed typos - fixed title - removed dead link - removed obsolete line regaring event_id - line wrap --- proposals/2723-add-forward-info.md | 45 ++++++++++++++++++++---------- 1 file changed, 30 insertions(+), 15 deletions(-) diff --git a/proposals/2723-add-forward-info.md b/proposals/2723-add-forward-info.md index 81185a7c6..4616ac0c5 100644 --- a/proposals/2723-add-forward-info.md +++ b/proposals/2723-add-forward-info.md @@ -1,12 +1,19 @@ -# MSC2723: Add forward information to forwarded messages +# MSC2723: Forwardes message metadata -Currently a forwarded message is not easily recognized as a forwarded message. While for messages of `msgtype` `m.text`, `m.emote` and `m.notice` clients could do something in the `formatted_body` of `content`, for all other message types the forward highlighting would be very poor. To get around this and provide a guideline to clients which information should go with a forward, we suggest adding the "forward info" explicitly. See also https://github.com/vector-im/riot-web/issues/4747. +Currently a forwarded message is not easily recognized as a forwarded message. While for messages +of `msgtype` `m.text`, `m.emote` and `m.notice` clients could do something in the `formatted_body` +of `content`, for all other message types the forward highlighting would be very poor. +To get around this and provide a guideline to clients which information should go with a forward, +we suggest adding the "forward info" explicitly. +See also https://github.com/vector-im/riot-web/issues/4747. ## Proposal -### Providing m.forward +### Providing m.forwarded -Leaning onto edits (adding `m.new_content` inside `content`), we want to suggest to add `m.forwarded` to `content` to forwarded messages. The required information would cover at least the original `senden`, `room_id` and `origin_server_ts`: +Leaning onto edits (adding `m.new_content` inside `content`), we want to suggest to add +`m.forwarded` to `content` to forwarded messages. The required information would cover at least +the original `sender`, `room_id` and `origin_server_ts`: ``` { @@ -32,22 +39,29 @@ Leaning onto edits (adding `m.new_content` inside `content`), we want to suggest } ``` -Additional the original `event_id` could be added. - ## Potential issues ### Resolving display name and avatar -Since the receiver (of a forward) may not be in the room, the message has originally been posted to, he may not be able to get the original sender's `displayname` and `avatar_url` from `/_matrix/client/r0/rooms/{roomId}/members`. +Since the receiver (of a forward) may not be in the room, the message has originally been posted +to, he may not be able to get the original sender's `displayname` and `avatar_url` from +`/_matrix/client/r0/rooms/{roomId}/members`. We see two possible solutions at the moment: 1. The forwarder adds `displayname` and `avatar_url` to `m.forwarded`. -2. The receiving client resolves the `displayname` and the `avatar_url` from the user id given by `sender` using `/_matrix/client/r0/profile/{userId}`. +2. The receiving client resolves the `displayname` and the `avatar_url` from the user id given by + `sender` using `/_matrix/client/r0/profile/{userId}`. -Both solutions have a drawback. In case of 1., changing the display name or the avatar would not be reflected in forwards. And the avatar URL may even become invalid(?). The second solution may cause confusion is the original sender has set different display names and avatars for different rooms. I.e. if the original sender is in the room where the message is forwarded to, it may appear there under a different display name and avatar. +Both solutions have a drawback. In case of 1., changing the display name or the avatar would not be +reflected in forwards. And the avatar URL may even become invalid(?). The second solution may cause +confusion is the original sender has set different display names and avatars for different rooms. +I.e. if the original sender is in the room where the message is forwarded to, it may appear there +under a different display name and avatar. ### Clients can fake forwards -Should we care of/can we avoid "fake forwards"? Does it make sense/is it possible at all to only add the original `event_id` when sending a forward and assign the server the responsibility of adding the forward information? +Should we care of/can we avoid "fake forwards"? Does it make sense/is it possible at all to only +add the original `event_id` when sending a forward and assign the server the responsibility of +adding the forward information? ## Alternatives @@ -80,7 +94,8 @@ Should we care of/can we avoid "fake forwards"? Does it make sense/is it possibl ``` ### Discarded: Using m.relates_to -We've also discussed and discarded usind `m_relates_to` for highlighting the message as forward, like the following: +We've also discussed and discarded usind `m_relates_to` for highlighting the message as forward, +like the following: ``` "m.relates_to": { @@ -92,10 +107,10 @@ We've also discussed and discarded usind `m_relates_to` for highlighting the mes We discarded this idea for two reasons: 1. The idea of `m.relates_to` seems to be that related messages belong to the same room. -2. Its unclear who should fetch the event from a different room she/he/it is potentially not in and how this could be done at all. +2. Its unclear who should fetch the event from a different room she/he/it is potentially not in + and how this could be done at all. ## Unstable prefix -Clients can implement this feature with the unstable prefix `com.famedly.app.forwarded` onstead of `m.forwarded` until this MSC gets merged. - +Clients can implement this feature with the unstable prefix `com.famedly.app.forwarded` instead of +`m.forwarded` until this MSC gets merged. -See also our discussion here https://gitlab.com/famedly/app/-/issues/320.