Merge acea0854a1
into ecf996389f
commit
9d66ac39cd
@ -0,0 +1,116 @@
|
||||
# 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.
|
||||
|
||||
## Proposal
|
||||
|
||||
### 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 `sender`, `room_id` and `origin_server_ts`:
|
||||
|
||||
```
|
||||
{
|
||||
"content": {
|
||||
"body": "Big Ben, London, UK",
|
||||
"geo_uri": "geo:51.5008,0.1247",
|
||||
"m.forwarded": {
|
||||
"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
|
||||
|
||||
### 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.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.
|
||||
|
||||
### 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
|
||||
|
||||
### 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
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
### Discarded: Using m.relates_to
|
||||
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.
|
||||
|
||||
## Unstable prefix
|
||||
Clients can implement this feature with the unstable prefix `com.famedly.app.forwarded` instead of
|
||||
`m.forwarded` until this MSC gets merged.
|
||||
|
Loading…
Reference in New Issue