MSC2389: Toward the EDU-to-PDU transition: Typing. #2389
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,40 @@ | ||
| # MSC2389 - Typing (keyboard-input) EDU-as-a-PDU | ||
|
|
||
| ### Background | ||
|
|
||
| Typing events are a feature in Matrix which indicate a user is in the process | ||
| of entering a message. Typing events are currently specified as ephemeral data | ||
| units. A server will transmit a typing EDU when a user strikes a key to every | ||
| other server in the room. When the user stops, deletes, or transmits their entry, | ||
| another typing EDU is broadcast for stoppage and the message PDU is also | ||
| broadcast. | ||
|
|
||
| ### Problem | ||
|
|
||
| The typing indication intuitively appears to have a very ephemeral meaning. Their | ||
| specification as an EDU allows an order of magnitude more of them to exist than | ||
| PDU's and to be easily discarded afterward. In practice, typing events are a very | ||
| small part of the overall loads on implementations within Matrix. Consider in situ, | ||
| typing events repel each other because users actually avoid typing at the same | ||
| time. The result is that if typing indications were a part of the room timeline | ||
|
There was a problem hiding this comment.
If typing notifications become PDUs, they will naturally become slower than the current EDU system. Notifications will take longer to reach each destination simply because they will require more computation to authenticate and embed into the DAG. If this takes longer, there is scope for users to "miss" typing notifications, because they take so long to arrive at the clients of other users, and the "repel effect" is lessened. As an aside, I don't think there is a huge amount of proof that typing notifications do repel each other, and that simply might be wishful thinking. In some cases certainly, but it's not the rule. There was a problem hiding this comment.
Why? There was a problem hiding this comment.
There was a problem hiding this comment. That doesn't answer my question but maybe we should move performance concerns into #2390 as that would cover other EDU-to-PDU MSCs concerns in one place. |
||
| they would not overload it by any means; we contend that the timeline would even | ||
|
There was a problem hiding this comment. You should perhaps also expand upon "overload". Overload what? Overload how? |
||
| be enriched by their presence. | ||
|
There was a problem hiding this comment. Why does having typing notifications in the timeline enrich it. Is there a crying need for typing notifications to appear in the DAG, that isn't solved by the current solutions? |
||
|
|
||
| ### Solution | ||
|
|
||
| We specify the Event type `m.typing`. An `m.typing` event with `content` containing a | ||
| `timeout` millisecond integer field can be transmitted to the room, providing and | ||
| replacing the existing functionality of the `m.typing` EDU. Furthermore, we specify | ||
| that within the content of this event, an `m.relates_to` with a `rel_type` of | ||
| `m.typing` indicates to the remote party which message will be the focus of the | ||
| typing user. | ||
|
|
||
| - Implementations should indicate a user is typing upon receipt of a valid `m.typing` | ||
| event, and remains for at most the duration of the `content.timeout`. | ||
|
|
||
| - When `content.timeout` is undefined, zero, or null, implementations should | ||
| indicate a user is not typing. | ||
|
|
||
| - Further messages of type `m.room.message` from the user also indicate a user is no | ||
| longer typing, and thus transmitting parties should not negate prior typing events when the | ||
| user sends a visible message. | ||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think this MSC is predicated on the assumption that #2390 is merged and EDUs have been removed, and so there is nowhere else to put typing notifications than the DAG.
Considering the proposal independently of #2390: just because it's possible to store transient data like typing notifications in the timeline of a room, doesn't mean that there's any value in doing so. The only use-case I can think of would be to support 'time-travel' action replay of a room - but it's very unclear on how valuable this is, other than as a gimmick. It's certainly unclear that the value justifies the additional serverside load of DAG processing & persistence.
In an analogy to git: sure, you could go and persist audit log of transient and semantically insignificant operations (e.g. pulls, fetches, blames, diffs, logs) in the reflog of your repository. But in practice, you want to keep that data structure (and the associated data management overhead) for your actual code instead. There's no point in clogging it up with stuff which is irrelevant for the record of the structure of your code - or in this instance, conversation.
You could try to argue it both ways, but in practice this is a fairly fundamental design decision for the project: whether room timelines for IM are intended to be a full record of every interaction with the room, or whether you try to keep them lean and lightweight and don't clutter them up with irrelevant stuff. We chose the latter, and I'm not seeing a good reason to change that (assuming that EDUs are a thing).