feat: send long messages as plain attachments#384
feat: send long messages as plain attachments#384lightclient wants to merge 1 commit intowhisperfish:mainfrom
Conversation
|
Thank you very much, this is great! |
Schmiddiii
left a comment
Schmiddiii
left a comment
There was a problem hiding this comment.
Do we also need to decode such attachments when we receive them? I don't think we do that anywhere yet.
| ContentBody::DataMessage(m) => m, | ||
| ContentBody::EditMessage(m) => match m.data_message.as_mut() { | ||
| Some(m) => m, | ||
| None => return Ok(()), | ||
| }, |
There was a problem hiding this comment.
Probably also need to handle sync messages analogously?
There was a problem hiding this comment.
I am currently doing that in the receiver of my project: https://github.com/hoehermann/purple-presage/blob/e6604db/src/rust/src/receive.rs#L163
By the way: Thank you very much for flare, it helped me in figuring out how to use presage. 🙂
|
@Schmiddiii thanks, that's a good point. Originally I thought the presage consumer could decide how to render messages with the plain text attachment, but on second thought it just seems more correct for Presage to make it happen on both sending and receiving. Will make the change. |
4 participants
I've been encountering an issue where messages would get delivered on desktop clients, but not on the iOS client. It took a bit of time to finally figure out that it was due to the message size, but I eventually found that iOS will just silently drop messages larger 2048 bytes.
It appears the official clients add long-text handling when the body exceeds 2048 bytes. They truncate the inline body at a UTF-8 boundary and upload the full text as a
text/x-signal-plainattachment.You can see here:
(MessageUtil.getSplitMessage)
I've implemented the same in this PR. Tested locally and am able to verify it is working now on macos desktop app and iOS app.