-
Notifications
You must be signed in to change notification settings - Fork 382
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
MSC4146: Shared Message Drafts #4146
base: main
Are you sure you want to change the base?
Conversation
{ | ||
"type": "m.room_drafts", | ||
"content": { | ||
"!ROOMID:example.com": { |
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.
Using room specific account data could remove a layer of mapping in this.
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'll look into that, thank you! :)
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.
Account data would have been my first guess for implementing this feature, but you'd need to figure out some encryption scheme to avoid leaking data to the server.
Co-authored-by: Patrick Cloke <clokep@users.noreply.github.com>
Co-authored-by: Patrick Cloke <clokep@users.noreply.github.com>
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.
Implementation requirements:
- Client recognizing and using the feature
oversight where I took a local copy and wordwrapped it when I already had changes done remotely 🤦
Added a section about drafting media (`m.image` in this example) and also how you could draft a whole event. This could be useful for polls, custom events, or drafting messages with other MSCs.
- If a client removes the `m.draft_in` as part | ||
of an edit the draft would no longer be associated with a room, causing | ||
confusion on the users' end as to where their draft went. | ||
|
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.
Another issue is that converting to and from a user's input to a Matrix message can be lossy. For example, if a user starts writing a message on a client that uses Markdown, and resumes editing later on a different client that uses a different input format, some formatting may get lost.
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 that shouldn't be too much of a problem considering the plaintext should (in theory) be stored in the body
, alongside a pre-formatted version in the formatted_body
The client is expected to import the body
, although maybe I should make that more explicit in the document
(or, alternatively to the body
, if available the m.draft_full_event
if it's something like a poll or other more complex event, but I have not gotten much feedback on that yet)
Rendered
This MSC proposes a way to share message drafts between clients, to edit and/or send them on clients they weren't initially written in.
Signed off by: Simon Müller (simeonlps@proton.me)