A personal, non-editor, non council note. I’m wondering if we should consider SIMS to be dead and should just use stateless file sharing (and simplify the XEP a bit). One criticism we get occasionally is "lack of direction" if we as community or we as council can decide that Message markup and stateless file sharing is what we want to do we can get rid of some unnecessary flexibility. +1 from me :)

-tmolitor

Hi,

This seems backwards to me. SFS is just a shallow clone of SIMS but with less namespace reuse after all. Why would we lend legitimacy to something like that?

I don't want to take part in which one is the best one. What I can say as someone who tries to develop stuff that has a nice UX on all maintained clients is yes, please, pick one and deprecate the other. It is going to feel nice when I push that -500 lines commit. About the emoji markup XEP, I am glad to see it submitted, thanks ♥. Besides the namespace issue Daniel mentioned, I wonder if the XEP should cover how to use these for 0444 reactions too? Maybe it's fine to keep that for another XEP, later, I am not sure. Cheers, -- nicoco

> This seems backwards to me. SFS is just a shallow clone of SIMS but with 
> less namespace reuse after all. Why would we lend legitimacy to something 
> like that?
Are you sure you are talking about the same XEP here?
XEP-0447 says in its introduction:
This is a reiteration on Stateless Inline Media Sharing (XEP-0385) [1] with 
some significant changes:
- No focus on media, generic for every file type.
- Body can be used for fallback.
- Using File metadata element (XEP-0446) [2].
- Using XML for structured data instead of URIs when possible, adding further 
extensibility (like providing proper means of sharing encrypted files on http 
servers).
- Not relying on underspecified usage of References (XEP-0372) [3].

Especially using the file metadata element seems like a better namespace reuse 
to me, no?

It also is generic and can be used for all types of file, not just for media. 
That's a clear advantage compared to SIMS.

-tmolitor

- Source attaching

Sure, I object to this complication as well, but less than the namespace reuse issues.

- Sending of multiple files in a single message (e.g. to send photo galleries), backwards compatible (legacy clients would see this as multiple messages). This is implemented at least in Kaidan, WIP in Dino.

Also supported not just by SIMS but even by OOB.

- Extension for proper E2EE (XEP-0448) when using SCE-alike encryption schemes (OX, OMEMO2), also backwards compatible (it's possible to send a file in a chat where some clients only do siacs-OMEMO such that OMEMO2+XEP-0448 clients see a proper SFS file transfer with metadata and legacy siacs-OMEMO+XEP-0454 clients get the "aesgcm" link, but both download and decrypt the same HTTP upload, so the file doesn't need to be uploaded twice). This is implemented at least in Kaidan.

This seems like it would also be supported by SIMS and OOB once we have SCE.

On Sat, 2026-04-25 at 14:22 +0000, Stephen Paul Weber wrote:

This element was invented for SFS and is my main objection to the XEP. Many equivalent elements exist in other XEP and RFC no need for yet another.

In fact it was invented for SIMS. It makes me wonder if you had read the introduction of XEP-0446. Also, XEP-0234 mandates (MUST) the use of a <hash/> or <hash-used/> inside the <file/> which, while nice to have and useful in some context, might be unnecessary compute work in other context. SFS recommends using hashes, but also has clear rules for when the sending entity decides against using them. This would not be possible when reusing the Jingle File Transfer <file/>. XEP-0446 explicitly defines that any use of its <file/> may impose new rules. The idea is that eventually, a future version of XEP-0234 could use XEP-0446 instead of defining its own element. Same for XEP-0385. If you are referring to other standards for file metadata that would be reasonable to pick up in XMPP context, I'd be happy to hear about them.

So can SIMS. The M in SIMS may stand for "media" but this is as in "medir type" aka all files.

It is your understanding that "inline media" can also be interpreted as "not-inline any-file". A lot of the wording in XEP-0385 indicates it is meant for media in the sense of audio, video and images and that the client is intended to "display the media inline of the chat". It even recommends (SHOULD) specific media codecs and container formats for this (including the patent-encombered, royalty-bearing H.264 codec for video). Anyway, SFS was always intended as a successor to SIMS, not a competitor. It's fully backwards compatible to SIMS and adds new features. The changes over SIMS would not be possible without a namespace bump, so if it makes you happier, consider SFS a namespace bump over SIMS. On Sat, 2026-04-25 at 14:26 +0000, Stephen Paul Weber wrote:

Sure, I object to this complication as well, but less than the namespace reuse issues.

What is a feature to some always is a complication to others. Using source attaching is optional.

Also supported not just by SIMS but even by OOB.

If with OOB as a file transfer method, you're referring to jabber:iq:oob from XEP-0066, that only supports a single file transfer per iq. If with OOB you are referring to the jabber:x:oob from XEP-0066, I need to let you know that this element as per XEP-0066 does not constitute a file transfer request. It's merely "used to communicate a URI to another user or application", which may be a URI pointing to a file, but may just as well be one pointing to a website to be opened in the browser or a sip:-URI to start a SIP call. This is actually made explicit in the XEP itself (section 5). The XEP does not make any claim on the number of jabber:x:oob <x/> element that can be in a message, so I'm happy to assume one can use it to communicate more than one URI (that may or may not be a file download). Where OOB becomes useful as a file transfer it through a non-standard convention that if a message has a single OOB element and the URI in that OOB element matches the content of the body, some clients would interpret that as a file transfer request (and then either display that inline or provide a way to download/save the file). This convention is reasonably backwards compatible to clients not supporting OOB (which will just display the link). While it would be possible to extend this non-standard convention to support multiple files, this would not be possible without breaking backwards compatibility (either by making the additional files invisible to existing clients or by turning the files into just a message of multiple URIs for existing clients). Now for SIMS, the wording in XEP-0385 always uses the singular "a" ("a photo", "a reference to a media-shring"), which I would typically interpret as a single file. Of course other interpretations are possible, but there is definitely no intention to allow for multiple files visible in the XEP. Even if it was allowed, SIMS does not support for any backwards compatibility with the above mentioned oob convention (neither for single files nor for multiple). Now when it comes to existing SIMS implementations, they all are non- compliant with SIMS in various aspects: - They tend to ignore the body when a media-sharing reference is present. Even if not 100% explicit, the example clearly shows that the body in SIMS messages is to be displayed to the user next to the SIMS file. The reason clients don't do this is that otherwise they couldn't send a message that both follows the oob convention and uses SIMS. - They often also don't support multiple references to media-sharing. So even if we interpret the XEP that this is allowed, doing to would not be compatible with existing SIMS implementations. - As I wrote above, SIMS mandates (MUST) a <hash/> element inside Jingle File Transfer <file/>. Guess how many implementations actually do that. - There's also a bunch of other non-standard shenanigans done by existing clients that claim compliance with SIMS, but they're not relevant for this discussion, so I'll keep them out (although they're probably relevant for anyone trying to implement SIMS and be compatible with existing implementations)

This seems like it would also be supported by SIMS and OOB once we have SCE.

Both SIMS and OOB don't have any way to indicate encryption keys. OOB is just a URI and https-URIs don't carry encryption keys. For SIMS, one could in theory do an extension that does support this, which would actually be close to XEP-0448 and thus just emphasizes my point that XEP-0447 is really mostly a continuation of SIMS. So in summary, I consider SIMS dead. The specification document has all kinds of open ends and uncertainties and the implementations in the wild significantly divert from it. It is also not actively developed, last change in 2018. There was a mailing list discussion on the <hash/> element issue in 2021 but no follow-up update. The author of SIMS also didn't extend their XSF membership last year. SFS is a successor, it's being actively developed, is more flexible and by now should have a superset of the features of SIMS and better backwards compatibility. I fail to understand what's so bad about SFS that you reject it and what's so good about SIMS that you want to stick with it (or your non- standard interpretation of it). I'm not saying SFS is perfect, but I would be more than happy to hear what's wrong with it so it can be improved. Marvin

On Sun, 2026-04-26 at 11:44 +0000, Stephen Paul Weber wrote:

...

In fact it was invented for SIMS. It makes me wonder if you had read the introduction of XEP-0446.

I have read it. It says it was written because it disagrees with the design of sims, which is not the same as being used in sims. If sims used it them sim and sfs would be the same, but of course my main objection is to xep0446.

Are we reading the same words? Let me quote the introduction of XEP- 0446 for you.

Several existing specification have the need to provide metadata on a file. The only specification of an element that contains file metadata so far is provided as part of Jingle File Transfer (XEP- 0234) [1]. This resulted in the situation that XEPs like Stateless Inline Media Sharing (XEP-0385) [2] depend on the mostly unrelated Jingle (XEP-0166) [3] just for the metadata element. The motiviation of this XEP is to get rid of such dependencies and have a dedicated place to define a file metadata element.

Nowhere does it say it doesn't like the design of SIMS.

Since this is most of the purpose of using sims or sfs (to get the hash) it seems reasonable?

I didn't know that was the main purpose of SIMS or SFS. Also surprises me, given that some implementation neither send nor process the hash. I'm pretty sure the main reason so far for people to implement SIMS or SFS is to get thumbnails.

Sure, the example in OOB is also of a jpg.

I think there is a huge difference between a jpg being mentioned in a non-normative example without any indication if it is meant to be displayed inline or just as a savable file (as in OOB) and a normative text saying to display files inline with a "RECOMMENDED" (=SHOULD) to support decoding H.264. YMMV.

Then why the new XEP number and changed design?

XEP numbers are cheap. It's an easier process to create a new XEP than to bring a XEP back to life. Further, keeping the document alive that describes what some clients implement just makes sense (look at OMEMO where most clients implement something that people have to find in the attic). The design wasn't changed hugely, ideas and motivation remained the same. The introduction of XEP-0447 even says its an reiteration of SIMS with some changes and lists them. The acknowledgement section also mentions SIMS and it has descriptions on how to best be backwards compatible with existing SIMS implementations.

For multi file there is no support in clients

Most clients can receive more than one file, they just can't group them together. I think that the most reasonable fallback to sending a group of 3 files is to send 3 messages with 1 file each rather than a message with 3 URLs. Needless to say that this is all a mute argument, because when you send 3 files in a single message using SIMS, it will break existing implementations (that often only take the first or last occurrence of a SIMS in each message).

Snipping out fallbacks of course but that's just a UI choice.

Have fun doing that UI choice when the fallback is more than just one URI. Are those URIs separated by commas, spaces, newlines? Will someone potentially put "URI and URI" with literal "and" in the body. And then translate that to the users preferred language. Even if you call it a UI choice, what we provide as protocols should allow for such reasonable UI choices to be made. If our protocols prevent you from doing the choices you want to do for your UI, the protocol becomes unfit for the purpose.

I think I've been pretty clear oves the years that my main objection is the use of xep0446.

I get that now. Though it makes me wonder why you prefer the <file/> from Jingle File Transfer that puts restrictions and rules in place that are not required for the generic case of file metadata and also means everyone has to suddenly implement Jingle File Transfer only because they want to do file metadata?

Sure, for example https://datatracker.ietf.org/doc/html/rfc5854 also defines an equivalent element.

First, the purpose of Metalink is to allow to link to multiple instances of the same file (e.g. different mirrors or protocols). The way it refers to files (by URI) does not allow for encryption to be added or more complex file retrieval instructions that don't fit a URI, but let's ignore that and say we would only use the file metadata aspects of it (which is the same 0446 provides and what SIMS takes from Jingle). The metadata elements provided by Metalink are largely mismatching the ones people look for in messaging context. There is no metadata specific to media files at all (dimensions, length) or that are useful for clients to discover if they want to automatically download the file or try to display it inline (media type). However it has a lot of fields specific to software publishing (which is what it was designed for) like "identity" and "version" (which refer to the file being downloaded, with the example being "Firefox" and "3.5" for Firefox 3.5) that we likely won't use. With the overlap being essentially file name, file size and description, it feels weird to pull in a dependency on a largely unrelated specification for just those 3 file properties. (Metalink also specifies a hash property, but we do have one that is also stable for a while in XMPP so I didn't count that). So yeah, if the options are: 1. Create an RFC to extend Metalink so it can be used for our purpose + create a XEP that says how to use Metalink with that extension so such XEP can be referenced elsewhere (like Jingle File Transfer or SIMS/SFS) 2. Create a XEP that goes without Metalink and requires me to specify 3 undercomplex file properties (name, size and description) that Metalink could have given me for free I definitely opt for the second. It's less work to write, easier to handle for developers and doesn't depend on any external parties with a completely different usecase. YMMV.

On Sun, 2026-04-26 at 15:13 +0000, Stephen Paul Weber wrote:

...

Are we reading the same words? Let me quote the introduction of XEP- 0446 for you.

...

This resulted in the situation that XEPs like Stateless Inline Media Sharing (XEP-0385) [2] depend on the mostly unrelated Jingle (XEP-0166) [3] just for the metadata element. The motiviation of this XEP is to get rid of such dependencies and have a dedicated place to define a file metadata element.

This is the quote right here. Says it doesn't like what was done in SIMS and so this XEP exists to change that.

Uhm. SIMS took the element from Jingle File Transfer because that was the one that available. I don't think the authors wanted to say "it makes sense to depend on jingle file transfer for this metadata element" but I think it was rather "unfortunately I have to reference Jingle File Transfer here, as the metadata that is largely unrelated to Jingle is specified there". Having the concept of file metadata specified in something related to Jingle, a specific transfer method, for me is pretty obvious to be a bad design, but it's not an issue of SIMS, but rather an issue of Jingle File Transfer, SIMS is just the victim of that earlier bad design.

I didn't know anyone was really doing thumbnails but sure that's another very visible use if so.

Isn't Cheogram the client sending those `image/thumbhash` thumbnails? (which is not registered with IANA and thus rather should be `image/vnd.<name>.thumbhash`)

No one has to implement Jingle File Transfer

XEP-0385 says "a client supporting this XEP MUST implement Jingle File Transfer (XEP-0234)". I'm not sure how to not read that as a MUST.  Also, XEP-0234 is still Experimental (or Deferred to be precise), meaning that SIMS can't be turned stable without turning Jingle File Transfer stable first. It also shows again why having the metadata element in its own XEP is a good idea, as it reduces dependencies on protocols that are not strictly needed.

Name, size, description, mime

Metalink doesn't even have mime type as a property, you can only specify the mediatype of metaurl (like torrent) and signatures, but not for the file itself. And if I look at existing implementations of both SIMS and SFS, they seem to be interested in at least width and height (as those can be used to prepare a "hole" of the correct size within the user interface while still fetching the image). Marvin

...

...

No one has to implement Jingle File Transfer

XEP-0385 says "a client supporting this XEP MUST implement Jingle File Transfer (XEP-0234)". I'm not sure how to not read that as a MUST. 

Right but we're not talking about supporting that XEP, but rather a totally different XEP (sims) which uses part of the same vocabulary.

I missed the context of this quote and that it was from SIMS. The full quote is:

Thus a client supporting this XEP MUST implement Jingle File Transfer (XEP-0234) [2] and HTTP File Upload (XEP-0363) [4].

I thought the argument being made was that because it uses a metadata element in the jingle namespace it must implement jingle, which clearly would not be true. But in fact it's simply that the XEP actually says "MUST implement jingle" in a totally different section that we were discussing, which is what confused me. I agree it's silly for this to be a MUST and the XEP should be transport-method agnostic and not require any particular transport method (http, jingle, or anything else) to work at all. Though I can see the reasoning was probably simlar to the suggested codecs section on "wouldn't it be nice if all the apps always worked together" but I think it's well known I oppose that kind of view so I'd be quite happy to drop this MUST. I don't think this is related to the XEP-0446 discussion, though.

On Sun, 2026-04-26 at 20:07 -0500, Stephen Paul Weber wrote:

...

It is RECOMMENDED that the file metadata specifies name, media- type, size and one or multiple hash elements

If I'm not mistaked RECOMMENDED means SHOULD which means implementations are permitted to break if a hash is not present. This is very close to a MUST.

I'm pretty sure that "SHOULD" does not mean implementations are permitted to break if not followed. That would make "SHOULD" effectively equivalent to "MUST" and thus useless. It is also not an uncommon pattern in RFCs to have "SHOULD do X. MAY not do X if Y", which semantically wouldn't work if "SHOULD" is similar to "MUST". Instead, "SHOULD" means you could be not doing that under circumstances and not doing so has implications. You already found some of the implications listed in the XEP itself (no hash means that none of the provided hashes is available in the local storage, source attaching can't be used), but there may be others (e.g. the recipient might not be able to cache the file at all and thus unable to display inline).

BTW, would it make sense to give source attaching its own XEP? It takes up quite a lot of the space in this one for an advanced feature.

I think all current implementations of SFS do support source attaching at least incoming from the same sender and many also use it outgoing when they are the original sender. Also note that the backwards compatibility for sharing multiple files (as described in §4.2) relies on source attaching (as this allows for good backwards compatibility with previous file sharing implementations that only support a single file per message). If source attaching was an optional feature to support incoming, there would be no means for the original sending clients to discover it's supported, so they can't know if they can make use of the "attaching the primary source later" usecase described in §3.3. It would also be weird to not have it in there, because some of the normative language elsewhere only makes sense because there is source attaching (notably that it is optional to provide <sources/> in the <file-sharing/> itself).

...

If the disposition attribute is set to attachment, no <media-type/> is provided or the <media-type/> indicates that the file can not be displayed inline, i.e. when the media type is application/octet-stream, the receiving entity SHOULD NOT display the file inline and instead offer to download it or save it on the user's file system.

Does "display inline" here just mean "show a preview"? So if disposition is attachment I'm (almost) forbidden to show a preview of the file?

I guess inline display and preview/thumbnail display are not exactly the same, but the idea of disposition attachment is the same as the Content-Disposition header in HTTP [1]. In fact the behavior described in the XEP pretty much matches the behavior you see in browsers (if Content-Type indicates that it can't be displayed in the browser or of Content-Disposition is set to attachment, browsers don't display the file inline and instead download / show save file dialog). Now your user interface implementation could for example show a download button for the file and display a file type icon next to it, which it replaces with a preview for image files. Similar to the behavior that some desktop file explorers have. But that's an implementation detail of how you realize the offer to download or save the file that is displayed instead of the inline image. And of course you can always ignore this if you have good reason (hence it's a SHOULD and not a MUST). Just like browsers can ignore the Content-Disposition header. However, just like with servers setting Content-Disposition, the assumption by the sender when they set disposition attachment is that the recipient probably doesn't want the file to be displayed inline. An example here could be audio files: if I send you a voice messages, that likely should have disposition inline, but if I send you an 16 hours audiobook file, you're probably better off not to listen to it with your XMPP client and be stuck on the chat for 16 hours, so I will use disposition attachment. As the sender may have some extra context that not always can be reasonable represented using metadata, they are in a better position to make that decision than the receiving client. Marvin [1] https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Headers/Content-...

If SFS does get a seperate namespace to support this disposition value, then I'd like to incorporate it into my XEP and drop the SIMS compatibility entirely I wouldn't like clients that support SIMS/regular SFS but not support Emoji Markup to misinterpret and display the attached emoji files as regular attachments (for the sake of UX/UI) On 4/25/26 2:35 PM, Marvin W. via Standards wrote:

Hi,

I had already added the same note on the PR with the ProtoXEP before it got merged. [1] My suggestion would be to add an additional value for disposition that indicates that the file should not be provided as downloadable attachment or displayed directly in the chat, but is only used as a reference. That way still all of the logic of SFS remains intact (like source attaching), which would potentially be broken or with increased complexity if the <file-sharing> became a sub-element.

The problem of course being that SFS doesn't have this disposition yet and there is no obvious compatible way to introduce it without a namespace bump, so I haven't actually done it yet. Maybe this would be a good point to ask for feedback or issue a last call, so we only have to do a single namespace bump?

Marvin

[1] https://github.com/xsf/xeps/pull/1525#issuecomment-4201452130

On Sat, 2026-04-25 at 15:01 +0200, Philipp Hörist wrote:

...

Hi

With this syntax, a client which does not understand <markup> or does not want to implement it, but understands File Transfers, cannot differentiate that these files are only useful if markup is supported, and belong to the markup.

So i think this would not be desirable. Somehow the SFS stuff needs to be inside a markup namespaced  element.

Regards Philipp

On Fri, Apr 24, 2026, at 12:26, Daniel Gultsch wrote:

...

The XMPP Extensions Editor has received a proposal for a new XEP.

Title: Emoji Markup Abstract: This specification leverages and (or ) to send custom emojis

URL: https://xmpp.org/extensions/inbox/emoji-markup.html

The Council will decide in the next two weeks whether to accept this proposal as an official XEP. _______________________________________________ Standards mailing list -- standards@xmpp.org To unsubscribe send an email to standards-leave@xmpp.org

---

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

---

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