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(a)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)a.example wants to send a file to B(a)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(a)xmpp.org
To unsubscribe send an email to standards-leave(a)xmpp.org
--
Andrew Nenakhov
https://redsolution.com <http://www.redsolution.com>