Optionally Store images in a filesystem folder instead of passing them to the front-end

[Juliaria08]

Maybe this should go to upstream?

I have pidgin configured to "do both" with incoming images, and I've noticed that if I receive multiple images and at least one of those is from a user with autoaccept on ask, pidgin doesn't let me accept it to save it to somewhere, and crashes.

I've had this happen after having pidgin stopped for a while and have had received a lot of images, so that's a bit annoying.

[Juliaria08]

So I'd propose to have another option which is similar to tdlib-purple, have a whatsmeow folder or something in purple, and allow another option to store the images there, (and only there too)?

[hoehermann]

Thank you for the suggestion. This can definitely be done. It completely bypasses all involvement of the UI, which may even be a good thing in some circumstances. From Spectrum and Bitlbee server admins I heard both, positive and negative feedback each. Henceforth it must be an optional feature. I can probably recycle some of the code from https://github.com/hoehermann/purple-signald.

I currently do not use the auto-accept plug-in, but I did not configure it for daily use, yet. No estimate when I can come around to try it. Unfortunately, my day job has become more demanding which leaves me with less energy to spend on this project. :(

[Juliaria08]

Thank you for the suggestion. This can definitely be done. It completely bypasses all involvement of the UI, which may even be a good thing in some circumstances. From Spectrum and Bitlbee server admins I heard both, positive and negative feedback each. Henceforth it must be an optional feature. I can probably recycle some of the code from https://github.com/hoehermann/purple-signald.

Yes it should be an optional feature, I forgot to mention that.

I currently do not use the auto-accept plug-in, but I did not configure it for daily use, yet. No estimate when I can come around to try it. Unfortunately, my day job has become more demanding which leaves me with less energy to spend on this project. :(

Oh, I have no need to rush so do it when you're able to.

[hoehermann]

We can have a short discussion here, I can clean up the conversation later. In https://github.com/hoehermann/purple-gowhatsapp/blob/whatsmeow/src/go/profile.go, I just download the profile picture and give it to the front-end. I obtain the source URI via https://pkg.go.dev/go.mau.fi/whatsmeow#Client.GetProfilePictureInfo. Is there an alternative approach which yields higher quality pictures?

[Juliaria08]

That sounds good enough for me. Thank you for giving it a try.

FYI It seems the image is bigger, but not the size WhatsApp's servers store it as, so it's likely in my case pidgin is compressing the image or something, as I know the real image size is bigger, and the quality still isn't the best so this issue would still apply to images of profile pictures.

[hoehermann]

Is e1ebc5b to your liking?

[Juliaria08]

Is e1ebc5b to your liking?

Yes, I haven't tested the downloading profile pictures part but I assume it'll work fine.

[Juliaria08]

Is e1ebc5b to your liking?

Wait, if you change the profile picture, next time it'll be overwritten.

[Juliaria08]

I'd do this:

diff --git a/src/go/profile.go b/src/go/profile.go
index 1bca8d6..7a82c3f 100644
--- a/src/go/profile.go
+++ b/src/go/profile.go
@@ -102,7 +102,7 @@ func (handler *Handler) profile_picture_downloader() {
 		directory := purple_get_string(handler.account, C.GOWHATSAPP_ATTACHMENT_DIRECTORY_OPTION, C.GOWHATSAPP_ATTACHMENT_DIRECTORY_DEFAULT)
 		if directory != "" {
 			os.MkdirAll(filepath.Join(directory, pdr.who), os.ModePerm)
-			local_path := filepath.Join(directory, pdr.who, "profile.jpg")
+			local_path := filepath.Join(directory, pdr.who, "profile" + "-" + pdr.picture_id + ".jpg")
 			file, err := os.Create(local_path)
 			if err == nil {
 				file.Write(b.Bytes())

[hoehermann]

Personally, I think this is a bit on the creepy side. Sometimes people do replace their profile picture because they explicitly want the old one gone.

Alas, same goes for show once messages, deletion or revision of messages and other privacy functions which cannot be implemented in libpurple due to its limitations. Twenty years ago, using the internet certainly was different…

I am hesitant to put this in. Bad gut feeling. For now, that patch will be part of your local build. 🙂

[Juliaria08]

Personally, I think this is a bit on the creepy side. Sometimes people do replace their profile picture because they explicitly want the old one gone.

Alas, same goes for show once messages, deletion or revision of messages and other privacy functions which cannot be implemented in libpurple due to its limitations. Twenty years ago, using the internet certainly was different…

I am hesitant to put this in. Bad gut feeling. For now, that patch will be part of your local build. 🙂

Oh, that's true

[Juliaria08]

Also, I've noticed status@broadcast messages don't get the user's reference, ie, you can't tell who sent that broadcast unless you look at the logs, differently from other groups.

[Juliaria08]

Tho being honest technically the removal of the old status updates could now be implemented

[hoehermann]

Unfortunately, I cannot work on any feature regarding status updates / broadcasts at all. I have one account I actually use and three additional accounts for testing purposes. For reasons unknown, I do not receive status updates on any device. That means I do not know how such a message actually looks like and even if I implemented some handling, I cannot test it. I am afraid, someone else needs to look into that. 😕

In regard to the original topic of storing attachments directly, it looks like this issue is closed, is it?

[Juliaria08]

Yes, it's closed. Except sometimes you don't get things you sent on other devices I think, but that should likely be registered as another issue?

[hoehermann]

it's closed.

Glad to read that. 🙂

sometimes you don't get things you sent on other devices

Yes, please open another issue for that.