MSC3038: Typed typing notifications #3038
Conversation
turt2live
changed the title
turt2live
added
client-server
| 6. Other users now see them as typing a text message again | ||
| 7. Finally, the user sends `{"typing": false}` to clear their typing status for other users. | ||
|
|
||
| ## Potential issues |
There was a problem hiding this comment.
something that is unclear is how we'd represent edits. Ideally we don't include metadata about which message is being edited (for privacy reasons), but we could include the remainder of the relationship?
There was a problem hiding this comment.
also applies to threads
| ``` | ||
|
|
||
| The `event` is a stripped-down version of a real event, indicating the `type` and relevant parts of | ||
| the `content` to be included. This does technically allow a client to also send partial events such |
There was a problem hiding this comment.
How does this interact with MSC1767 ooi? I think it still is sane?
There was a problem hiding this comment.
yea, I think it'd probably just send a bunch of empty objects (ie: content: {"m.text": {}, "m.image": {}})
| from the room for doing this. Servers could also use pattern-detecting behaviour if appropriate for their | ||
| deployment to determine if a user is abusing typing notifications (for example, a user is unlikely to be | ||
| typing a message for 4 solid hours). | ||
|
|
There was a problem hiding this comment.
It also makes it a bit easier for an attacker to send large amounts of data in the typing event and generally waste resources. One could argue there are other ways to do that though. That said, I'm inclined to say that making it a namespaced string rather than a partial event body would solve all the use cases with fewer footguns?
There was a problem hiding this comment.
that's not as future proof (we'd have to remember to add m.edit, m.voice, m.file, etc with each MSC), but it would probably be more sane data-wise.
Could also be argued that servers should be size-limiting EDUs like this.
turt2live
changed the title
turt2live
added
the
needs-implementation
| such as potentially streaming uploads or other lengthy message sending stats (as this approach could | ||
| send progress information too). | ||
|
|
||
| ## Alternatives |
There was a problem hiding this comment.
Couldn't #2477 also be counted as a potential alternative?
There was a problem hiding this comment.
With a bit of a stretch for "alternative", sure. I don't think it's fair to count it given we're fundamentally sending a rich typing notification.
There was a problem hiding this comment.
I'd argue that that MSC could subsume this one and typing notifications entirely, and so could be seen as an alternative, thus the mention. 👍
There was a problem hiding this comment.
2477 defines a way for custom EDUs to be sent, not replace the existing EDUs system. If we push typing notifications into that, we're effectively introducing fragmentation.
Rendered