Tedd. Good afternoon. Yes. You are correct. I neglected it. I meant to XEP-0363: HTTP File Upload. Sorry for the confusion. Schimon On Fri, 20 Jun 2025 12:56:04 +0000 Tedd Sterr <teddsterr@outlook.com> wrote:

My client requests the data from your client:

<iq type='get' from='teddsterr@teddste.rr/b21e986c' to='schimon@schim.on/a1c0fcb9' id='213ff41b010008fc04d39795c0cde8b980839dc1'> <data xmlns='urn:xmpp:bob' cid='sha1+4e213cc5338c048171253fa49654b664ae50a6ed@bob.xmpp.org'/> </iq>

This is sent: my client → my server → your server → your client — no IP address is included.

Your client then replies with the requested data:

<iq type='result' from='schimon@schim.on/a1c0fcb9' to='teddsterr@teddste.rr/b21e986c' id='dd3552c1a3d4f05f8f22a8497d5c8a6d59d9bb4c'> <data xmlns='urn:xmpp:bob' cid='sha1+4e213cc5338c048171253fa49654b664ae50a6ed@bob.xmpp.org' type='image/png'> iVBORw0KGgoAAAANSUhEUgAAALQAAAB4AQMAAABhKUq+AAAABlBMVEXHSwoYDRfNXBe9AAACOUlEQVRI x9XTsWsTURwH8N/1AsmWgA4OSkZHCx51KX24uZT+CaFDcXSwrUvgpQ46WDqLiC4dBadOStOrc+hBEAVN L6XDDRIMBnlH8+59HS6X5N29gwSK2jc9Pvz4vd/v994jilcVANCn9LosZ//Uw//J35pdLZhd0ntjXwFZ Rv9BhK7hXvbIMvq7EnGTL5csbrrf1ysWkwaXDyyOjPMhXrgMRym2AIUzninIBjA8YpnGygBOKTugKvD7 jQ2kCwKAjyzjHAA+KEBlTm1CIO0MAISIuO42AAUIAEgXqYDgM9c9fgsIGimPGecNprk98mPS85djjo5J z8NH8U9tLd5C4juaF0fcXNC9nMTbrubVEUvbNvtjPQ9LnNtmr+b4jScAGpm2IgyAqQeUlCmpCEweUNKu kqXn0z9vPIb6ShkA7JCI5FSe+q0aAPhoEFNT5x7SYbzp2gBRmNR5ShHGq0tqPDdLTLxP2En2LjQfJPtP uhvXLO7n+E+zD0XTHB/k5BFz1mM8d4horjzRvHPg8eebOd4HMLyU+c/nYlKuIV7dyfHbZpd5/tDs4UmO +2a/yOnrVY7v5nj5r8/5qvqzxfUgPGGD+07V3avw3QovXDtzKrT0shVc1PivVcdv7bex34YzaF33aPnr OQZrLFx1fHdpEY6Hwt1WoUL1m1HQr/Gos8k6xS8o3MOW6Gx4dPC9F4g1LnsHfme7ja02NkVv27tSc+uv S48bPGzJdo57pjyyE/mmeNlT3x7NVs8fP1tbi8CsEKUAAAAASUVORK5CYII= </data> </iq>

This is sent: your client → your server → my server → my client — no IP address is included.

On Fri, 20 Jun 2025 at 16:58, Goffi <goffi@goffi.org> wrote:

When you get a file though, the HTTP Upload service of your recipient gets your IP. The other issue is when you receive a file/image from some random domain, in this case the simplest option is to use a proxy which will get the file for you.

A specification to indicate to XMPP clients where to find a proxy would be nice, it has already been talked about in the past.

The specification already exists - https://xmpp.org/extensions/xep-0215.html Currently the XEP is well known for being the way to discover STUN/TURN services offered by your server. It's actually generic though, and is the perfect place to advertise a proxy service (with associated credentials). I plan to include such a proxy in Snikket at some point. In the meantime, if any client devs are interested in working on this then I'm happy to set up a test Prosody instance that advertises such a proxy. Regards, Matthew

On Fri, 20 Jun 2025 18:06:55 +0100 Matthew Wild <mwild1@gmail.com> wrote:

On Fri, 20 Jun 2025 at 16:58, Goffi <goffi@goffi.org> wrote:

...

When you get a file though, the HTTP Upload service of your recipient gets your IP. The other issue is when you receive a file/image from some random domain, in this case the simplest option is to use a proxy which will get the file for you.

A specification to indicate to XMPP clients where to find a proxy would be nice, it has already been talked about in the past.

The specification already exists - https://xmpp.org/extensions/xep-0215.html

Currently the XEP is well known for being the way to discover STUN/TURN services offered by your server. It's actually generic though, and is the perfect place to advertise a proxy service (with associated credentials).

I plan to include such a proxy in Snikket at some point. In the meantime, if any client devs are interested in working on this then I'm happy to set up a test Prosody instance that advertises such a proxy.

Could XEP-0215 proxify data which was sent via HTTP file upload? Best, Schimon

On Sun, 22 Jun 2025 at 09:46, Guus der Kinderen <guus.der.kinderen@gmail.com> wrote:

I wonder if there is room here for the proxy to cache the data that is transmitted. That way, the total amount of data that is transferred between domains (when more than one person is to receive the data) could be drastically reduced. That is useful in certain scenarios.

Okay, I spent a few hours on this this week. From the experiments, I can report a few things: - Proxies that terminate HTTPS are not really a thing in the HTTP proxy world. This is unsurprising, as such a proxy would have the ability to intercept and modify HTTPS traffic. I can understand why the web ecosystem doesn't want this. However, this means there is no way to do HTTPS *and* implement caching. - To do HTTPS through a proxy, practically all implementations use the CONNECT method to create a TCP tunnel to the remote server:port and then do HTTPS within that tunnel. - The CONNECT method is very open to "abuse" - it would allow the client to connect to any remote server on any port and speak any protocol (it isn't limited to HTTPS). The proxy can filter on the target host/port, and many such proxies restrict outbound connections to port 443 for example. In our ecosystem I know we have a bunch of servers which use other ports (5281, 5443, 7443, ...). - The CONNECT method does not pass through reverse proxies such as nginx. I know that for Snikket, a lot of people run it behind such a reverse proxy, and if it doesn't work in these scenarios, it won't work for a significant number of deployments. For anyone who wants to play with this on their own Prosody, we have a module: https://modules.prosody.im/mod_http_connect - just load it and you'll find it advertised via XEP-0215. I'm not able to provide a test server right now, as the one I would use has a reverse proxy in front... :) So despite my initial enthusiasm for off-the-shelf proxy support, it seems that it might actually be worth considering other options. For example, we could do something similar to Matrix, where you make a normal HTTPS request to your own server, with the remote URL embedded in the path. Your server will then transparently fetch the remote resource and return it. Something like: 'GET https://recipient.example/fetch/share.sender.example/d8c16ada-52b3-11f0-9de6...' This has a number of advantages: - It's "just" HTTPS, so should be easy enough for any client that currently supports fetching HTTPS file shares, including web clients. - The server is able to control the outgoing request, which ensures it can only be used for HTTPS, and headers and methods can be restricted (to GET, etc.). - Caching can be optionally implemented. - The server will see both the request and the response, but this is already exposed to the origin server, and we have OMEMO/aesgcm already taking care of the content encryption and signing. I don't object to us implementing a prototype of this approach if it seems like a route we would want to go down. I'm also open to other suggestions. Regards, Matthew

On Thu, 26 Jun 2025, 20:33 Goffi, <goffi@goffi.org> wrote:

Hi Matthew,

Le jeudi 26 juin 2025, 19:35:55 heure d’été d’Europe centrale Matthew Wild a écrit :

...

[SNIP] So despite my initial enthusiasm for off-the-shelf proxy support, it seems that it might actually be worth considering other options. For example, we could do something similar to Matrix, where you make a normal HTTPS request to your own server, with the remote URL embedded in the path. Your server will then transparently fetch the remote resource and return it. Something like:

'GET https://recipient.example/fetch/share.sender.example/ d8c16ada-52b3-11f0-9de6-1b9c14dcd995/cat.jpg'

This has a number of advantages: [SNIP]

That's actually what I had in mind when thinking about a proxy for this use- case. On my wishlist, I would love it to have a way to get a preview of images/video and/or a resized media to some common resolutions. The benefit would be that :

- we could cache and share preview/resized image/video for huge files at the proxy level.

- devices with restricted resources (connection/CPU), typically mobile devices, could get a small file instead of having to request a huge one then resize on-device.

Of course, and in particular for videos, it could be resource intensive for the server. But at least for images, it would be a useful feature.

For various reasons, such as server load and E2EE, I think such previews need to be provided by the sender. Regards, Matthew