File transfer

[GIPeon]

Hey there! First of all thank you for your effort in this! ;)

Basically I was trying to figure out how to send files via OMEMO from Pidgin on a Windows 7 machine to another OMEMO client (a Conversations client on Android to be specific if that can help).

For what I can tell from here, it should be supported, but maybe is not yet implemented in your plugin? or it's just for the Conversations client? maybe it's a Pidgin issue?

Thank you!

[leedoyle]

@GIPeon You need http upload xep 0363 plugin. https://github.com/Junker/purple-xmpp-http-upload

[leedoyle]

Update: lurch doesn't support encryption for http uploads as of now. https://github.com/Junker/purple-xmpp-http-upload/issues/7

[GIPeon]

Thank you for this! Hoping to hear updates on the encryption of HTTP uploads, unfortunately I'm quite a novice in the programming field and C is totally out of my knowledge :(

[gkdr]

Hi! You're welcome, I hope I can do some more in the near future. As you realized by now, file transfers are an entirely different XEP and not part of the OMEMO XEP. I'll leave this issue open as a feature request though.

[swats-the-floran]

just wonder if there is something to test. i get links like aesgcm:// which cannot open.

[gkdr]

This neither part of the OMEMO specification, nor of the HTTP File Upload specification, so there's not really anything to test. To be honest, I have no idea which specification this belongs to, so if you want to help you could find that out so I can more easily see how much effort it would be to implement it.

[jesse-git]

I found a reference to this page of the aesgcm scheme on the ChatSecure blog, implemented by both ChatSecure and Conversations: https://github.com/iNPUTmice/ImageDownloader

But does pidgin support XEP-0363 in the first place? I do see the aesgcm link in pidgin, so maybe it is a simple matter of decrypting the data?

[gkdr]

Well, there's a link to a plugin in the second comment, but I don't know how functional it is and if the creator intends to support it. I looked at how it works and I might be able to listen for the libpurple file transfer signals and encrypt then, but I'm not sure yet.

For decryption, it seems you have to install the tool you linked - see the Gajim example in the README.

[jesse-git]

For me, I can't test XEP-0363 plugin because my only environment is pidgin on Windows. The plugin seems to be geared toward linux.

---

I did test out the ImageDownloader program, as you said. I attempted to make ImageDownloader work well with pidgin and usable by an end-user who is not that tech savvy but knows how to work with files, since this is the only implementation of aesgcm we have to work with at this point.

TL;DR It's not going to work as-is, but I'll document here what I did just in case it's helpful.

1. Basic test: I tried executing the tool directly on command line with the link shown in pidgin:

   java -jar .\ImageDownloader-0.1.jar aesgcm://files.myxmppserver.com/data/UID/UID.jpg#HASH > file.jpg

   The java app spit back the error:

   could not connect to host unknown protocol: aesgcm

2. I replaced aesgcm with https, which worked. Will it always be a correct assumption that the file is hosted over https?

3. Because the aesgcm link is shown directly in pidgin, I thought it might be possible for the user to just click the link to have it executed with the ImageDownloader program automatically. Pidgin seems to check the Windows registry for the url scheme to see if there's a default program to handle that scheme, and then makes the text in the chat window into a hyperlink if there is a registered program.

4. The only way to add a scheme is to directly modify the registry. It would be possible for a semi-tech-savvy end-user to set it up via a .reg file. An advantage of doing it this way is that it would bypass the requirement for the XEP-0363 plugin in this environment. However, the parameter passed to ImageDownloader from pidgin would start with aesgcm, not https, so it won't work.

5. It should be possible to make a wrapper script of some kind (probably a batch file?) which replaces aesgcm with https and also sets the filename to the UID with an appropriate extension. I haven't tried this yet, but using ImageDownloader within pidgin seems to be getting uglier and uglier.

You may have already seen it, but in an old closed issue, iNPUTmice, the author of ImageDownloader, said:

I'm not interested in developing this into a full fledged user stack. Ideally your client should be able to handle the encryption out of the box.

Which I agree with. But I know it's probably a significant time requirement, so I guess I'll just +1 this issue. It would be really nice to have both receiving and sending aesgcm files integrated into one plugin.

[gkdr]

Well, the thing is - HTTP Upload is just that, upload. You get a link from the server and that's it. I guess the mobile clients use it for sending pictures, so they know to download them and display a thumbnail. But what is a libpurple (not Pidgin!) plugin supposed to do with it, assuming it can detect the links by the aesgcm://? I didn't look that closely at the plugin yet, but I think it just displays the link and has no download either. Maybe if there was the possibility to start a libpurple file transfer to download a link it could be doable but I really don't know enough about how it works to say that yet.

[RayZopf]

here the explanation https://xmpp.org/extensions/inbox/omemo-media-sharing.html

afaik encrypted http-upload of an image and then sending link+key within omemo chat so that the client then downloads the content and decrypts it

[stevegwh]

Hey all, so I've been interested in Pidgin being able to handle the "aesgcm" links that Conversations sends too (in Pidgin you just get a unclickable URL). I am unsure whether this is really the correct place to talk about it (I am not sure if lurch really covers this?) but this is the closest thing I've found to people addressing the issue.

I did the same as @jesse-git and got the images displaying with an image viewer if I subbed out the aesgcm prefix for https. I set the default Pidgin browser as the shell script provided in the "ImageDownloader" README but unfortunately Conversations always prepends the URL with aesgcm (I am sure for a good reason) which Pidgin does not automatically recognise as a hyperlink (making it unclickable). I can reply with the same image URL with https instead of aesgcm and then I am able to click and view it in an image viewer. Interestingly, Conversations also displays the "https" image in the chat as it would with the aesgcm one.

An extremely hacky way of making this work would be to find a way of making aesgcm links clickable in Pidgin and then replacing "aesgcm" for "https" before running ImageDownloader. If anyone is aware of a way of doing that, or a better solution (which I am sure there is) then please let me know! :grimacing:

[jesse-git]

Yeah maybe this is not the best place to talk about it, but there really isn't a good place. We are trying to make "glue" to patch together Pidgin and ImageDownloader in the interim of an actual plugin to handle it, and this glue would most often be used with lurch.

I had tried to make aesgcm links clickable by adding a registry key as I described in step 3 above, but pidgin would still not recognize it as a clickable link. It is probably a limitation of pidgin. I don't know of any possible workaround.

The linked "XEP" above is very unofficial, even though it seems to be supported by ChatSecure and Conversations and probably other clients.

[EionRobb]

For Pidgin 2.x you'll need to register the URL with the history area using gtk_imhtml_class_register_protocol() https://developer.pidgin.im/doxygen/2.7.11/html/gtkimhtml_8h.html#0e49bc0a42869ac2965891eed0239d3b

[paniq]

any progress on aesgcm:// support?

[gkdr]

It may not look like it, but yes! I have been working on a little plugin which automatically downloads "HTTP Upload" URLs. So far my idea is to send some signal when it's done, and if the "protocol" is aesgcm, decrypt it in place with this plugin and then write some notification to the chat window. Maybe handling it as an incoming file transfer would be cleaner, but I'm not sure about that.

It's ugly, but pulling in functionality from some totally different XEP would be even more ugly. If I (or someone else...) someday get(s) around to do an actual Pidgin UI, there could maybe be a clickable thumbnail or something like in other clients. Does the proposition sound at least usable?

[jesse-git]

This issue has been awhile for me, But could the notification in the chat window include a local link to the image which opens it with the default program? or alternatively, a link to the parent folder?

[Jieiku]

It may not look like it, but yes! I have been working on a little plugin which automatically downloads "HTTP Upload" URLs. So far my idea is to send some signal when it's done, and if the "protocol" is aesgcm, decrypt it in place with this plugin and then write some notification to the chat window.

Awesome! do you have your current work available to try anywhere? or is it not yet to the testing phase?

currently on linux desktop the application "Dino" already handles this natively, but for windows users lurch is amazing because pidgin really is the best client on windows at the moment for Omemo XMPP communication. I am also waiting for when Kaidan supports Omemo, I suspect I will move both linux and windows to Kaidan once it has omemo integrated.

[gkdr]

Hey @Jieiku,

I made a little strategic mistake :grimacing: I decided that since it's such an easy plugin, I'll try to write it in another language. Which of course did not go as smoothly as I had hoped. And then I decided to focus on the "main" plugin again. Thanks for asking, to be honest I forgot it existed! I think I'll have a look soon, I got it almost working before I stopped.

[Jieiku]

Awesome! Happy to test once you are to the point of needing testers

[Syntaxrabbit]

Additional helper here.