Server logs?

sure, sorry for delay

May 26 22:54:35 c2s5636bbf29fa0 info    Stream encrypted (TLSv1.2 with ECDHE-RSA-AES256-GCM-SHA384)
May 26 22:54:36 c2s5636bbf29fa0 info    Authenticated as karcio@crystalhub.duckdns.org
May 26 22:54:59 c2s5636bc05bd60 info    Client connected
May 26 22:55:00 c2s5636bc05bd60 info    Stream encrypted (TLSv1.2 with ECDHE-RSA-AES256-GCM-SHA384)
May 26 22:55:00 c2s5636bc05bd60 info    Authenticated as lucyna@crystalhub.duckdns.org
May 26 22:55:42 upload.crystalhub.duckdns.org:http_upload       info    File uploaded by karcio@crystalhub.duckdns.org/Karol’s iPhone to slot r7HwATkHUkCYO_jV                                                                               
May 26 22:56:06 upload.crystalhub.duckdns.org:http_upload       info    File uploaded by lucyna@crystalhub.duckdns.org/Lucyna’s iPhone to slot wtUIGIQahdFq_WIv                                                                              
May 26 22:57:20 upload.crystalhub.duckdns.org:http_upload       info    File uploaded by karcio@crystalhub.duckdns.org/Karol’s iPhone to slot vW3W0hy6KlSamrv1                                                                               
May 26 22:57:45 upload.crystalhub.duckdns.org:http_upload       info    File uploaded by lucyna@crystalhub.duckdns.org/Lucyna’s iPhone to slot ZDq0oP6ABQFL9HKy                                                                              
May 26 22:57:55 c2s5636bc05bd60 info    Client disconnected: closed
May 26 22:59:27 stanzarouter    warn    Unhandled c2s stream element or stanza: r; xmlns=urn:xmpp:sm:3: <r xmlns='urn:xmpp:sm:3'/>                                                                                                           
May 26 22:59:27 c2s5636bbf29fa0 info    Client disconnected: connection closed
May 26 23:01:08 c2s5636bbff4220 info    Client connected
May 26 23:01:09 c2s5636bbff4220 info    Stream encrypted (TLSv1.2 with ECDHE-RSA-AES256-GCM-SHA384)
May 26 23:01:09 c2s5636bbff4220 info    Authenticated as karcio@crystalhub.duckdns.org
May 26 23:03:34 stanzarouter    warn    Unhandled c2s stream element or stanza: r; xmlns=urn:xmpp:sm:3: <r xmlns='urn:xmpp:sm:3'/>                                                                                                           
May 26 23:03:34 c2s5636bbff4220 info    Client disconnected: connection closed

Bump, same issue, both on 6.4 and in beta 7.0.

@jtmaston provide more info? Was HTTP Upload toggled ON in Settings? Servers are 100% or support XEP-0363 in https://compliance.conversations.im ? Do files work without OMEMO?

@jtmaston provide more info? Was HTTP Upload toggled ON in Settings? Servers are 100% or support XEP-0363 in https://compliance.conversations.im ? Do files work without OMEMO?

Hello! Yes, upload is toggled ON. XEP-0363 is fully supported Server is 66% compliant, as it's a small affair and we don't need all the features. however, 0363 is supported. Files don't work at all, neither with or without omemo. Neither in group chats or private chats, error simply states "upload to http server failed"

Maybe of use, we also use beagleIM on the Mac ( i know it's made by the same company ) and uploads work there without issue.

From your latest comment, it looks like BeagleIM can connect to the HTTP server used for HTTP File Upload while SiskinIM cannot. I suppose that BeagleIM is on the computer connected to your local network and due to that it can access HTTP server, while SiskinIM being on your phone, may not be in the internal network (ie. on cellular connection) and cannot access your HTTP server.

From your latest comment, it looks like BeagleIM can connect to the HTTP server used for HTTP File Upload while SiskinIM cannot. I suppose that BeagleIM is on the computer connected to your local network and due to that it can access HTTP server, while SiskinIM being on your phone, may not be in the internal network (ie. on cellular connection) and cannot access your HTTP server.

That's a negative, we have prosody running on a VPS, not in the same network. Moreso, the other users use Android ( blabber.im ) and Linux ( gajim ) and haven't had any issues.

for further clarification, on siskin I am neither able to receive files ( I get the filename and two dashes for the filesize ) nor to send a file ( fails with that aforementioned error )

It is also possible that iOS rejects to connect due to some other limitations, or ie. due to a different mechanism for validation of SSL certificates. But that is just guessing.

You cannot send or receive files as there is a connection to HTTP server used to do both and it fails not the XMPP connection.

It is also possible that iOS rejects to connect due to some other limitations, or ie. due to a different mechanism for validation of SSL certificates. But that is just guessing.

You cannot send or receive files as there is a connection to HTTP server used to do both and it fails not the XMPP connection.

I see. Would there be a method to test this?

if you have version 7.0, long-tapping on the "downloading image" and then selecting "copy" should copy the URL of the shared file which you could try to open in Safari to check if it will report any issues.

Please also check if you are using any VPN on the iOS device as it could block this connection (just an idea).

if you have version 7.0, long-tapping on the "downloading image" and then selecting "copy" should copy the URL of the shared file which you could try to open in Safari to check if it will report any issues.

Please also check if you are using any VPN on the iOS device as it could block this connection (just an idea).

We've tested, none of us ( neither me on siskin nor my colleagues on their clients ) can open the link to view the file ( despitse being able to see the image itself ).

For reference, this is the link of an image I received ( obtained by the method you suggested, long-pressing on a message ):

aesgcm://upload.[domain]:5281/file_share/[ 16 digit string ]/[filename].jpg#[ long string ]

There's no VPN running on my phone.

Please try this for non-OMEMO encrypted file.

Done. The file opens in safari without issue on the iphone ( but still same behavior inside siskin, image does not render).

Hello. I have returned, after a while of trial and error.

My findings support your theory, that it might be something related to iOS. I managed to pull and compile the project as it is now ( on the master branch ). Running xCode on my M1 machine, I ran siskin "on my mac", the ipad mode. it had no issues sending and receiving files. However, compiling the same source code to be used both in the simulator ( emulating an iphone 11 ) and on real hardware ( iphone 11 ) yielded the same problem as before. I should, however, note something I found. While the project compiles to be used "on my mac" with no issue, it doesn't do that for iphone. ( complaining about webrtc symbols missing for arm64 ). HOWEVER! Putting xCode through rosetta makes it be capable of compiling for iphone without issue. So perhaps the issue is in webrtc? ( I downloaded the necessary framework files, using your script, like I said, on macos the app runs ).

So, in conclusion, it might be something to do with iOS. I'll gladly test any further developments. Thank you for your time today, and goodnight.

There may be some WebRTC issue for M1 in Siskin but as it was not prepared to be run on M1, it was never fixed.

As for the iOS issue with accessing the HTTP server, I think it could be related to the SSL certificate or your server using redirection to the actual HTTP server hosting the file. But those are just ideas.

There may be some WebRTC issue for M1 in Siskin but as it was not prepared to be run on M1, it was never fixed.

As for the iOS issue with accessing the HTTP server, I think it could be related to the SSL certificate or your server using redirection to the actual HTTP server hosting the file. But those are just ideas.

Thank you for your time, we'll mess around with the server and if we fix it I'll return. Cheers!

Update: fixed, issue was on our end. Sorry about that!

@jtmaston Could you share what was the issue?

@jtmaston Could you share what was the issue?

I'm told it was a certificate issue with the http upload server. We fixed it with a reinstall of prosody and with a complete redo of the certificates.

@jtmaston Thank you!