well we created a media gallery that does an improved file management, has quotas, makes image previews, etc, and among other things can work as a proxy to fetch incoming files, and is also planned to have an option to copy files by url, so 
a@a sends file (even to legacy http upload)
b@b receives link,
b@b fetches file via proxy, proxy optionally retains this file 

this retaining feature is not yet done, but it is rather trivialto do (we're constantly thinking about it, like it is a nice thing to have, BUT for some reason no-one really needs it among our users, everyone is ok with file being stored on the server).
I can give you a link to a working gallery and api doc if interested. 

Regarding http upload, we ditched it because it completely omits the problem of managing uploaded files. 

On Thu, 30 Apr 2026 at 15:53, Dave Cridland <dave@cridland.net> wrote:
Hi all,

Some of the work I'm dealing with has the requirement that clients belonging to their organisation shouldn't access arbitrary HTTP endpoints outside their administrative boundary. I think this is a reasonable requirement.

As an example, if A@a.example wants to send a file to B@b.example, A uploads to their own server, which:
* Might (or might not) perform virus scanning, and
* Might (or might not) log IP addresses and other activity, and
* Might (or might not) expire the file sooner than B's organisation's retention policy.

Some of these "might (or might not)" cases are probably specific to enterprise cases, but others are more general and apply to consumer/private messaging too.

What I'd like to explore therefore is whether we could have B's server pull a copy of the file for B to access, processing and retaining it as B's organisation requires.

But, and here lies my problem, I have literally no idea how to go about this without disruption to the generally working case of HTTP upload.

Anyone got any ideas?

Dave.
_______________________________________________
Standards mailing list -- standards@xmpp.org
To unsubscribe send an email to standards-leave@xmpp.org


--