XMPP requires HTTPS, that link is to an encrypted file, but the connection is HTTP so not encrypted.

Ask that server admin to fix their server.

@hantu85 since HTTPS it is a MUST ( https://xmpp.org/extensions/xep-0363.html#request ) shouldn't Siskin reject such a file?

It rejected this file and logged info about incoming "link" as link and HTTP file transfers are similar on the XMPP side, so you can act on this link, ie. open it if you decide to do so.

True, but that would yield a "corrupted" file that can't be used in this case, right? (unless the user knows how to decrypt it)

Assuming the file was encrypted - yes, but then you would have aesgcm:// and not https:// prefix in the URL.

The OP picture has http://file.ext#somesortofhash hence I thought it might be encrypted, was i wrong?

@rdravi110 every file you get has this issue or only from that server?

As far as I can tell, if file is encrypted with OMEMO it should have a link starting with aesgcm:// which for download should be replaced with https:// so it would not work anyway, see https://xmpp.org/extensions/inbox/omemo-media-sharing.html#aesgcm

@rdravi110 every file you get has this issue or only from that server?

Every file has the same issue. The issue arises only when I receive images on Siskin IM. I sent images using Conversations app to another Siskin user, they were also not receiving the images but just this type of link. I have tried various accounts with different servers on the receiving side of the file in the Siskin IM app.

My guess is that Conversations is sending OMEMO encrypted file over HTTP (even that HTTPS is required!) and just sends it with http prefix instead of aesgcm. But this would not happen if the server would properly support HTTPS for file transfers as the XMPP extension requires.

@inputmice ^^^

Yes this is Conversations' legacy behaviour from before aesgcm:// was specified. aesgcm always uses https. If your server doesn’t support https:// the only other option would be to fail the transfer entirely.

@hantu85 You could add http + correct number of hex digits after the anchor to the code that triggers downloads.

But really op should just enable https

When I sent an image using a Disroot account from Conversations app to an account from Nixnet.services account which was logged in to Siskin IM, the image was received.

A surprising thing is that one user I know used a sure.im domain for Siskin account. The domain was recommended by Siskin itself. But the sure.im user also did not receive the images but these links which did not work.

If the problem is with the server, why is the issue only seen when I transfer to SIskin IM? Other apps(like Conversations) work fine.

The issue is with the configuration of the senders XMPP server, in your case poddery.com as it is responsible for saving image and providing your client with a link to uploaded file which is then sent by your client to the Siskin IM which is unable to handle it as it is, as stated by @iNPUTmice` a legacy behavior and not supported by Siskin IM.

There is nothing wrong with Siskin IM or with sure.im as they are recipients of the message sent by Conversations using a legacy mechanism not supported by Siskin IM.

As this is a legacy mechanism I do not plan to implement it and the issue should be fixed by the admin of poddery.com by enabling HTTPS for HTTP File Upload.

the issue should be fixed by the admin of poddery.com by enabling HTTPS for HTTP File Upload.

Thanks @hantu85 . I will talk to the admin of the poddery.com .

@rdravi110 but are you really using Conversations Legacy? If so why not update?

@rdravi110 but are you really using Conversations Legacy? If so why not update?

@licaon-kter What is Conversations Legacy? I see only one Conversations app on F-Droid and that is what I am using.

@rdravi110 at Conversations 2.0 iirc some changes (OTR support, swipe, Android version compatibilities) warranted a fork named "Legacy" that eventually got moved to Archive after some time (years).

iNPUTmice` meant "legacy" behaviour actually, not the old app.

I have Conversations version 2.9.13+fcr

poddery.com admin here, I'm tryin to enable https as per https://prosody.im/doc/http but after setting https_certificate = '', sending images fail. Looks like we are using prosody 0.9 syntax.

@mwild1 ^^^

I tried different options including setting http_external_url, https_ports and some more but none worked. Can anyone share their prosody configuration with https enabled?

After a closer reading of https://prosody.im/doc/certificates#service_certificates I added two symbolic links https.crt -> poddery.com.crt and https.key -> poddery.com.key and added https_ports = { 5281 } in prosody.cfg.lua. I also had to enable 5281 port in firewall. Now siskin can see images sent from conversations. But it seems siskin can't send any images still.

But it seems siskin can't send any images still.

Looks like you have HTTP upload enabled on the base virtualhost. I believe Siskin requires that it be enabled on a subdomain.

@zash is a separate sub domain mandatory as per http upload spec?

It's not explicitly mandatory, no. But unfortunately the examples in the spec all use a subdomain, and many clients don't look for the service anywhere else except subdomains.

@mwild1 Well, works well in conversations and Dino. I think if the spec don't mandate it, clients should be fixed.

That was already discussed and concluded in https://github.com/tigase/siskin-im/issues/37#issuecomment-625880042

@hantu85 so won't this break all the files shared earlier if we change it now ?

If the HTTP server name will not change, then it would not break previously shared files.

As I recall, people already did that on a few installations and not complained about that, but we could ask @mwild1 as I'm not a prosody developer nor user.

If the HTTP server name will not change, then it would not break previously shared files.

As I recall, people already did that on a few installations and not complained about that, but we could ask @mwild1 as I'm not a prosody developer nor user.

Under the component set http_host = "example.com" and the HTTP host will remain the same. There are many ways to configure HTTP upload though (internal, external, etc.) so can't guarantee this is enough for every setup. Prosody support chat is at https://prosody.im/discuss :-)