diff --git a/proposals/2723-add-forward-info.md b/proposals/2723-add-forward-info.md
new file mode 100644
index 000000000..4616ac0c5
--- /dev/null
+++ b/proposals/2723-add-forward-info.md
@@ -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.
+