Have conventional file transfer mechanism remember local file destination

[UnitedMarsupials]

The embedded pictures -- like JPGs and PNGs -- used to simply display inline. Now, after upgrading to 1.20, Pidgin pops up a question asking, whether I want to download each image (like it always did with videos).

If I do, the image will be shown inline too (as before). If I press "Cancel", I will not see the picture at all... In 1.18 this was not a problem.

[hoehermann]

Thank you for the report. Yes, that behaviour can be regarded as a regression. The code is working as intended – only my intentions are off. 😅

The new behaviour is a side-effect of 67830d3. In that commit, I radically changed how attachments are handled:

Previously:

1. Message referencing attachment is received
2. Encrypted attachment is downloaded into volatile memory
3. Attachment data is decrypted (the encrypted buffer is not immediately dropped, though)
4. Attachment data is forwarded to the front-end (creating another copy)
5. In case of an image, the image is embedded into the conversation (creating a copy, again)
6. The user is asked where they want to put the attachment data on their drive

The keen eye notices that an attachment might take up space up to three times (encrypted, decrypted, front-end copy) of its actual size. There are some crazy people out there wo send gigabytes of attachments via WhatsApp. I received user reports of this plug-in exhausting RAM due to the multiplication. If I want a RAM-hog, then I'll use the official "WhatsApp Desktop". 😉 So this had to be fixed.

Now:

1. Message referencing attachment is received
2. The user is asked where they want to put the attachment data on their drive
3. The attachment data is downloaded into the file and decrypted in-place (no significant amount of memory is used)
4. In case of an image, the data is read from the file and embedded into the conversation

As you can see in the new variant, I simply forgot that users might want to see the images embedded – without explicitly storing them on the disk first. Would it be okay for you to use the auto-downloader for now? I recommend $purple/whatsapp-attachments/$chat/$hash$extension (not tested on Windows).

[UnitedMarsupials]

I received user reports of this plug-in exhausting RAM due to the multiplication. If

The Telegram-plugin allows the user to specify the maximum size of an attachment, which will be downloaded without questions asked... A bigger one would trigger a prompt -- but still displayed inline, if MIME-type permits.

Would it be okay for you to use the auto-downloader for now?

Sorry, what's an "auto-downloader"?

I recommend $purple/whatsapp-attachments/$chat/$hash$extension (not tested on Windows).

For the record, I'm on FreeBSD, not Windows.

[hoehermann]

Telegram-plugin

Good idea. I will probably bring back the option "inline-only" and make use of a similar technique (download to temporary directory).

what's an "auto-downloader"?

I am referring to the setting "attachment file path template".

I'm on FreeBSD, not Windows.

Nice to hear it works on FreeBSD. :)

[UnitedMarsupials]

I will probably bring back the option "inline-only" and make use of a similar technique (download to temporary directory).

Would be nice -- just checked, 1.20 is still the most recent release...

Nice to hear it works on FreeBSD. :)

The port does require same hacking around -- because your code insists on downloading additional parts at build-time...

[hoehermann]

1.20 is still the most recent release

I am sorry, but life is happening. Working on this project is not always my top priority, especially during summer. You can make use of the auto-download function by setting the "Attachment file path template" in the account options. Images are inlined after they have been downloaded automatically.

your code insists on downloading additional parts at build-time

That should be taken care of with commit 283b995 (May this year) since release version 1.17.0. It was quite a task, but it made the openSUSE folks happy. How are the demands of FreeBSD in regard to vendoring different?

[UnitedMarsupials]

I am sorry, but life is happening

You don't have to apologize :-)

How are the demands of FreeBSD in regard to vendoring different?

Probably aren't :) But, having once dealt with it, when I first created the port, I didn't bother changing it -- I just update the dependencies to the most recent versions of each one...

[UnitedMarsupials]

By the way... When the same image -- or video -- is sent in multiple chats, such as with John, Abe, and Mary, I get multiple prompts to save them. One for each conversation. When I pick the same location (under /tmp), I get a warning, that the file already exists. Duh...

This shows three problems:

• The prompt claims, that the file is being sent by John, Abe, and Mary -- even when it was me who sent the file to them.
• No attempt is made to notice the file-duplication -- once it is processed for one conversation, the other ones should reuse the results automatically.
• Any messages arriving after the one containing the file are shown before it, messing up the flow of conversation...

[hoehermann]

The reason for some of these problems is that Pidgin 2 is designed for instant messaging of the late 90s, not distributed mobile messaging we use nowadays.

The prompt claims, that the file is being sent by John, Abe, and Mary -- even when it was me who sent the file to them.

Pidgin can handle "sync" text messages (messages sent from own account, but different device) to some degree, but with file-transfers it is a different story. File-transfers are handled per contact. Pidgin 2 always assumes that the file originates from the contact. Contrary to text messages, there is no "sync" flag for file-transfers. 😕 Would you like a user setting to ignore files that have been sent by you?

Any messages arriving after the one containing the file are shown before it, messing up the flow of conversation...

When you look closely, you will notice that the time-stamps are actually correct, but in the conversation text area, the messages appear out of order. This is due to the fact that Pidgin 2 cannot re-order messages in the display, only append to them. That is where the "attachment file path template" setting for purple-gowhatsapp's integrated auto-downloader comes in handy: The downloader will block receiving other messages until the attachment has been stored.

No attempt is made to notice the file-duplication -- once it is processed for one conversation, the other ones should reuse the results automatically.

By default, I am using the WhatsApp provided hash to differentiate between files. When using the auto-downloader, the file gets overwritten – that is one form of de-duplication. ;) I might be able to look up the list of completed file transfers to find a transfer with a file of the same name and re-use the local path. So far, my attempts were not successful. Of course, that can only work if the user setting "delete completed file transfers" is inactive.

As for the original issue: You now have the option to have images displayed inline again without needing to set a location for storing them first in the https://github.com/hoehermann/purple-gowhatsapp/tree/dev branch. Feel free to try it and tell me whether it is to your liking.

[UnitedMarsupials]

Would you like a user setting to ignore files that have been sent by you?

I don't need such a setting myself. Especially, if such sending no longer blocks the program -- and you fixed that.
But I do think, identifying the sender properly would be useful.

Same with the "likes" by the way. When reporting my own reaction to me, the plugin uses my name instead of saying "You reacted with ...". A minor nit, but could be confusing, when some other user in a chat has the same -- or similar -- nickname.

Feel free to try it and tell me whether it is to your liking.

I'm a bit busy at the moment -- and don't want to block you waiting for my testing. l'll wait for the next release and report...

[verm]

I tried the dev branch on FreeBSD with the download to temporary location and show, it works great. No more asking to save every image thank you!

[hoehermann]

But I do think, identifying the sender properly would be useful.

I am afraid, this is not possible with the conventional libpurple xfer. There is only one field (who) for the "sender" – and that also characterises the conversation the attachment is associated with.

When reporting my own reaction to me, the plugin uses my name instead of saying "You reacted with ...".

I see the problem. The current approach is easy to implement since I just inject the "reacted with…" message into the conversation. The prefix with the name is added by the front-end. I usually work around by adding myself to the buddy list and alias myself "I". This way, the message becomes "I: reacted with…". 😉

I tried the dev branch on FreeBSD with the download to temporary location and show, it works great.

Thank you for checking my work and the positive feed-back. ☺️