Hi folks, We had a brief discussion at the current XMPP London sprint about allowing a user to delete their uploaded files. I know I've been thinking about this for a long time, and I think there have been prior discussions (on this list?) about potential approaches. Today we discussed options, and picked the one that seems feasible to implement in the codebases represented here. The PR for the XEP is at https://github.com/xsf/xeps/pull/1584 The submitted approach uses an iq request to the XMPP server with the GET URL of the file to be deleted. Other approaches discussed in the past include using the HTTP DELETE verb (e.g. on the slot's PUT URL or the service could return a special deletion URL in the slot response). This approach fails because the client requesting the deletion might not be the same client that requested the slot. It therefore won't have access to the secret URLs. The downside is that the XMPP server has to keep track of this, which I know will impact Prosody at least, where we have support for external upload services, and we don't necessarily track files past the initial slot request/response. But I'm confident we can find solutions, and implementing deletion is important. The iq is in a new namespace, so it's easily discoverable and backwards-compatible. I also know that there are other more generic file management proposals/protocols around, and I don't think adding this stanza to XEP-0363 necessarily competes with those. Regards, Matthew
Hi,
allowing a user to delete their uploaded files
I believe we do need that indeed, thank you for working on this. The way I see it, clients would send such deletion requests along retraction (0424)/moderation (0425) requests; this is not something visibly different than those for end-users (most likely they already expect this behaviour). With that in mind, maybe it would be nice if the retraction and moderation XEPs were mentioned somewhere in the PR. Or maybe it is the other way around: 0424 and 0425 should mention that retracting/moderating a message with an attachment should involve sending a deletion request (obviously this is only possible for "local" upload services). This is important for me with my slidge dev hat on: the file deletion requests will never make it to the gateway component, only retraction/moderation requests can reach it. What I would like to avoid is for clients to send the file deletion request only when the intent is to retract/moderate the message containing the file. Best, -- nicoco
Le dimanche 8 novembre 2026, 14:58:37 heure normale d’Europe centrale Matthew Wild a écrit :
Hi folks,
We had a brief discussion at the current XMPP London sprint about allowing a user to delete their uploaded files. I know I've been thinking about this for a long time, and I think there have been prior discussions (on this list?) about potential approaches. Today we discussed options, and picked the one that seems feasible to implement in the codebases represented here.
The PR for the XEP is at https://github.com/xsf/xeps/pull/1584
The submitted approach uses an iq request to the XMPP server with the GET URL of the file to be deleted.
Other approaches discussed in the past include using the HTTP DELETE verb (e.g. on the slot's PUT URL or the service could return a special deletion URL in the slot response). This approach fails because the client requesting the deletion might not be the same client that requested the slot. It therefore won't have access to the secret URLs.
The downside is that the XMPP server has to keep track of this, which I know will impact Prosody at least, where we have support for external upload services, and we don't necessarily track files past the initial slot request/response. But I'm confident we can find solutions, and implementing deletion is important.
The iq is in a new namespace, so it's easily discoverable and backwards-compatible.
I also know that there are other more generic file management proposals/protocols around, and I don't think adding this stanza to XEP-0363 necessarily competes with those.
Regards, Matthew _______________________________________________ Standards mailing list -- standards@xmpp.org To unsubscribe send an email to standards-leave@xmpp.org
Hi Matthew, Are you aware that there is already a way to delete uploaded files with XEP-0498 (https://xmpp.org/extensions/xep-0498.html#well-known)? Please don't duplicate features again, I already implement XEP-0498, it works well, and it notifies all devices of deletion. It's relatively easy to implement for servers, and trivial for clients. And you can see which files have been uploaded. Also, it's not restricted to HTTP (and deletion should not be restricted to HTTP Uploaded files). Regards, Goffi
On Mon, 9 Nov 2026 at 08:13, Goffi <goffi@goffi.org> wrote:
Are you aware that there is already a way to delete uploaded files with XEP-0498 (https://xmpp.org/extensions/xep-0498.html#well-known)?
Yes, I'm aware of XEP-0498, and also XEP-0214 which it partially duplicates (and there are probably others!). The ability to delete uploaded data is effectively a legal requirement in many jurisdictions. On services I host, which currently implement the (practically universal) XEP-0363, that deletion is currently a manual process where the customer has to submit a support request so the file can be manually deleted on the server side. I think that XEP-0363 (or any XEP which allows uploading and storing files somewhere) is incomplete without support for deletion on today's internet. Implementing XEP-0498 was not in my plans. I don't have anything against it existing, but it seems a lot more advanced than what ordinary messengers need, and it depends on pubsub, etc. I don't even know what that would look like. Some Prosody file upload backends don't even support listing files. Even implementing deletion is going to be a hurdle for some of them, requiring changes. As I wrote in my initial email, I don't think the two protocols need to compete. This is just filling a gap in XEP-0363 that should have been filled since the beginning. XEP-0498, XEP-0214 and similar XEPs provide more advanced mechanisms for file management, and I think they have their place. But I don't currently have a need for them and the additional complexity and dependencies they introduce. If all the client devs who currently support XEP-0363 today actually do signal that they would prefer to implement XEP-0498, then I'd look further into that. Regards, Matthew
Hi Matthew, Le lundi 9 novembre 2026, 12:53:53 heure normale d’Europe centrale Matthew Wild a écrit :
On Mon, 9 Nov 2026 at 08:13, Goffi <goffi@goffi.org> wrote:
Are you aware that there is already a way to delete uploaded files with XEP-0498 (https://xmpp.org/extensions/xep-0498.html#well-known)?
Yes, I'm aware of XEP-0498, and also XEP-0214 which it partially duplicates (and there are probably others!).
It's not duplicating it, it's based on other features and fixes the issues with XEP-0214. Yes there are others, you can read the introduction, they are all quoted with their issues.
The ability to delete uploaded data is effectively a legal requirement in many jurisdictions. On services I host, which currently implement the (practically universal) XEP-0363, that deletion is currently a manual process where the customer has to submit a support request so the file can be manually deleted on the server side. I think that XEP-0363 (or any XEP which allows uploading and storing files somewhere) is incomplete without support for deletion on today's internet.
The ability to delete uploaded data is very much required, even if we put legal aside, that's why this problem has been solved already.
Implementing XEP-0498 was not in my plans. I don't have anything against it existing, but it seems a lot more advanced than what ordinary messengers need, and it depends on pubsub, etc. I don't even know what that would look like. Some Prosody file upload backends don't even support listing files. Even implementing deletion is going to be a hurdle for some of them, requiring changes.
Please read it. Most of it is optional. You just need a node, it's re-using existing mechanism (like file-metadata), and you don't even have to show the metadata if it's a problem for your use case (you can either return an empty file-metadata, or simplify not accept get on the node). From a client point of view, all mechanisms are already implemented (needed for PEP, OMEMO, etc). It's a simple item delete, and other devices notification is done automatically following normal pubsub mechanism.
As I wrote in my initial email, I don't think the two protocols need to compete. This is just filling a gap in XEP-0363 that should have been filled since the beginning. XEP-0498, XEP-0214 and similar XEPs provide more advanced mechanisms for file management, and I think they have their place. But I don't currently have a need for them and the additional complexity and dependencies they introduce.
They do compete, XEP-0498 has a dedicated node to delete uploaded file, we'll end-up with another incompatible way, which means another feature to maintain, clients inconsistencies, and also the way you are proposing is only working for HTTP Uploaded files, while XEP-0498 has not such limitation. Sure for the file sharing component I'm maintaining, I can add yet another mechanism for deletion, and convert it (so file deletion events are properly handled), but it an extra feature to maintain. How how can my other devices be even notified of file deletion with your proposal, I haven't seen any mechanism for that, did I miss something ?
If all the client devs who currently support XEP-0363 today actually do signal that they would prefer to implement XEP-0498, then I'd look further into that.
Another issue, it that it's modifying a stable spec for an experimental feature, it will be a mess if there are changes to do on this (following feedback for instance). It should a least be proposed as an alternative spec. Regards, Goffi
Hi Matthew, I've raised my concerns about XEP-0498 duplication, however as the author of this spec, I'm biased, and if other council members don't see a problem here, I won't block (experimentation will tell anyway). But I have a problem with that added to a stable XEP. This is not a correction following feedback, implementation issue, or evolution of technologies, this is a brand new feature, and it would go directly to stable without going though the normal, experimental workflow. That means that if there is anything to change (like problem seen during experimentation), it will be a mess to fix. I think that this should be put in a separated XEP, maybe named "HTTP Upload - Deletion" to make it clear that it's HTTP Upload only (and not able to delete files uploaded with other means). This is a blocking concern to me, I think that we should not add new feature to stable XEP, and in this case it could be easily separated. Would it be possible to convert this to a new protoXEPs ? Thanks. Best, Goffi
On Tue, 10 Nov 2026 at 16:06, Goffi <goffi@goffi.org> wrote:
Hi Matthew,
I've raised my concerns about XEP-0498 duplication, however as the author of this spec, I'm biased, and if other council members don't see a problem here, I won't block (experimentation will tell anyway).
But I have a problem with that added to a stable XEP. This is not a correction following feedback, implementation issue, or evolution of technologies, this is a brand new feature, and it would go directly to stable without going though the normal, experimental workflow. That means that if there is anything to change (like problem seen during experimentation), it will be a mess to fix.
I agree it would have been better if it was included much earlier or from the beginning. But it would not be the first time we have updated a XEP with features which were within the scope of that XEP, and I don't see the harm in it, if done with review. If there are indeed any future changes required in this feature, it is not carved in stone, we have updated Stable XEPs many times before (maybe I set my own trap here by pushing to rename "Draft" to "Stable" years ago!). The downsides of splitting important related functionality across multiple XEPs outweigh any such concerns for me. That said, my objections are not strong and if this is the consensus, I can go with that. I want to see this deployed more than I care what XEP number it has. I shall update or submit a replacement PR. Thanks for your consideration! Regards, Matthew
once this deletion XEP is stable, could it be merged into XEP-0363? Otherwise, it looks like an extension of an extension, which is a bit odd. It’s optional anyway, or we could explicitly note in the document that it’s a new experimental feature, like how a stable release software can still include some experimental features.
On Tue, 10 Nov 2026 at 16:06, Goffi <goffi@goffi.org> wrote:
Hi Matthew,
I've raised my concerns about XEP-0498 duplication, however as the author of this spec, I'm biased, and if other council members don't see a problem here, I won't block (experimentation will tell anyway).
But I have a problem with that added to a stable XEP. This is not a correction following feedback, implementation issue, or evolution of technologies, this is a brand new feature, and it would go directly to stable without going though the normal, experimental workflow. That means that if there is anything to change (like problem seen during experimentation), it will be a mess to fix.
I agree it would have been better if it was included much earlier or from the beginning. But it would not be the first time we have updated a XEP with features which were within the scope of that XEP, and I don't see the harm in it, if done with review. If there are indeed any future changes required in this feature, it is not carved in stone, we have updated Stable XEPs many times before (maybe I set my own trap here by pushing to rename "Draft" to "Stable" years ago!).
The downsides of splitting important related functionality across multiple XEPs outweigh any such concerns for me.
That said, my objections are not strong and if this is the consensus, I can go with that. I want to see this deployed more than I care what XEP number it has. I shall update or submit a replacement PR. Thanks for your consideration!
Regards, Matthew _______________________________________________ Standards mailing list -- standards@xmpp.org To unsubscribe send an email to standards-leave@xmpp.org
On Tue, 10 Nov 2026 at 16:59, Matthew Wild <mwild1@gmail.com> wrote:
On Tue, 10 Nov 2026 at 16:06, Goffi <goffi@goffi.org> wrote:
Hi Matthew,
I've raised my concerns about XEP-0498 duplication, however as the author of this spec, I'm biased, and if other council members don't see a problem here, I won't block (experimentation will tell anyway).
But I have a problem with that added to a stable XEP. This is not a correction following feedback, implementation issue, or evolution of technologies, this is a brand new feature, and it would go directly to stable without going though the normal, experimental workflow. That means that if there is anything to change (like problem seen during experimentation), it will be a mess to fix.
I agree it would have been better if it was included much earlier or from the beginning. But it would not be the first time we have updated a XEP with features which were within the scope of that XEP, and I don't see the harm in it, if done with review. If there are indeed any future changes required in this feature, it is not carved in stone, we have updated Stable XEPs many times before (maybe I set my own trap here by pushing to rename "Draft" to "Stable" years ago!).
The downsides of splitting important related functionality across multiple XEPs outweigh any such concerns for me.
That said, my objections are not strong and if this is the consensus, I can go with that. I want to see this deployed more than I care what XEP number it has. I shall update or submit a replacement PR. Thanks for your consideration!
Goffi's observation that this bypasses process rings true with me. I also note that this is a severable feature. Apologies for the lawyer-speak, but I mean that it can easily be a distinct document without loss. Updating XEP-0363 to point at this document, and - when this new XEP becomes Stable - mandating it with SHOULD, is perfectly fine. Dave.
The upload service MUST verify that the requester is authorized to delete the file before deleting it. For example, a service can record the bare JID that requested each slot and permit deletion by that bare JID, irrespective of the resource used for the deletion request.
Would it make sense to reuse the Authorization and Cookie headers from the upload request to authenticate the deletion request?
On Mon, 9 Nov 2026 at 12:00, yiwei wu <huxiangkun2003@gmail.com> wrote:
The upload service MUST verify that the requester is authorized to delete the file before deleting it. For example, a service can record the bare JID that requested each slot and permit deletion by that bare JID, irrespective of the resource used for the deletion request.
Would it make sense to reuse the Authorization and Cookie headers from the upload request to authenticate the deletion request?
Yes, it was a tempting design to rely on secret information from the initial slot request/response. Unfortunately the client which uploaded the file may not be the same client which deletes the file. The secret information (PUT URL, headers, etc.) is not stored or shared by the uploading client, so is no longer available. The download URL is the main stable identifier we have, and allows e.g. admin deletions as well. Regards, Matthew
I agree that XEP-0363 should add a deletion feature. However, as you pointed out, a file might be uploaded from one device and deleted from another, even when both devices are using the same account. XEP-0363 has no sharing mechanism, so a desktop client might not know what a mobile client has uploaded at all; it would have to rely on sources such as avatars or MAM chat archives. In that case, it does seem better to use XEP-0498 directly. Matthew Wild <mwild1@gmail.com> On Mon, 9 Nov 2026 at 20:00 ：
On Mon, 9 Nov 2026 at 12:00, yiwei wu <huxiangkun2003@gmail.com> wrote:
The upload service MUST verify that the requester is authorized to delete the file before deleting it. For example, a service can record the bare JID that requested each slot and permit deletion by that bare JID, irrespective of the resource used for the deletion request.
Would it make sense to reuse the Authorization and Cookie headers from the upload request to authenticate the deletion request?
Yes, it was a tempting design to rely on secret information from the initial slot request/response.
Unfortunately the client which uploaded the file may not be the same client which deletes the file. The secret information (PUT URL, headers, etc.) is not stored or shared by the uploading client, so is no longer available. The download URL is the main stable identifier we have, and allows e.g. admin deletions as well.
Regards, Matthew _______________________________________________ Standards mailing list -- standards@xmpp.org To unsubscribe send an email to standards-leave@xmpp.org
On Sun, 8 Nov 2026 at 13:59, Matthew Wild <mwild1@gmail.com> wrote:
The PR for the XEP is at https://github.com/xsf/xeps/pull/1584
I like the text, but as noted elsewhere I feel a bit queasy about putting this into a Stable XEP. I think the Security Considerations should note that a server might not actually delete the file; it may be required to retain it for audit etc. Therefore clients cannot rely on the file actually being deleted. If servers do retain the file, it MUST NOT be accessible via the previously published URL. Dave.
participants (5)
-
Dave Cridland -
Goffi -
Matthew Wild -
Nicolas Cedilnik -
yiwei wu