MSC: Additive events

proposals/4058-additive-events.md

@@ -0,0 +1,84 @@
+# MSC4058: Additive Events
+
+New features in Matrix often need to introduce new event types to persist and
+communicate data within a room. Some of these features can ultimately clutter
+the room state/history with events that aren't providing critical function but
+do slow down scrollback.
+
+This proposal introduces a concept of "additive events", where users in a room
+can attach additional (structured) metadata to an event without having to take
+up an entire event ID themselves. This data is communicated ephemerally and is
+subject to random data loss, making it unsuitable for anything which needs a
+proper permanent record.
+
+## Proposal
+
+The `unsigned` portion of an event gains an optional `m.additive` object. The
+`m.additive` object is transmitted over federation, and is keyed by sender. The
+value is another object containing the additive information and a signature to
+cover the sent object.
+
+For example:
+
+```jsonc
+{
+  "type": "m.room.message",
+  "sender": "@alice:example.org",
+  // other fields not shown
+
+  "unsigned": {
+    "m.additive": {
+      "@bob:example.org": {
+        "hello": true,
+        "signatures": {
+          "@bob:example.org": {
+            // Only one of Bob's devices needs to sign this
+            "ed25519:DEVICEID": "<unpadded base64 signature covering `hello`>"
+          },
+          "example.org": { // must be the same server as the m.additive key
+            // Only one of the server's keys needs to sign this
+            "ed25519:KEYVERSION": "<unpadded base64 signature covering `hello`>"
+          }
+        }
+      }
+    }
+  }
+}
+```
+
+**TODO**: We need a way to describe a schema, to avoid abusive metadata being
+applied.
+
+**Note**: With respect to [MSC4049](https://github.com/matrix-org/matrix-spec-proposals/pull/4049),
+the keys of `m.additive` can be rooms or servers too.
+
+To add information to an event, a server transmits an EDU.
+
+**TODO**: Describe EDU, and APIs so clients can generate it.
+
+## Potential issues
+
+**TODO**: Detail.
+
+Spam/Abuse: Without a schema, users can add whatever they want.
+
+Unredactable: The added metadata can't be redacted/removed.
+
+Overwrite semantics: The MSC doesn't describe how to replace your added detail.
+
+## Alternatives
+
+**TODO**: Detail.
+
+## Security considerations
+
+**TODO**: Detail.
+
+## Unstable prefix
+
+As of writing, it is not intended that implementation begin. Therefore, an
+unstable prefix is deliberately not declared.
+
+## Dependencies
+
+No direct dependencies.