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

@@ -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.