-
Notifications
You must be signed in to change notification settings - Fork 385
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
- Loading branch information
Showing
1 changed file
with
84 additions
and
0 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -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. |