+1 from me :) -tmolitor

Hi, 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

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

Sure, I object to this complication as well, but less than the namespace reuse issues. Also supported not just by SIMS but even by OOB. 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: 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. 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: What is a feature to some always is a complication to others. Using source attaching is optional. 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) 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: Are we reading the same words? Let me quote the introduction of XEP- 0446 for you. Nowhere does it say it doesn't like the design of SIMS. 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. 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. 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. 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). 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 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? 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: 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. 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`) 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. 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

I missed the context of this quote and that it was from SIMS. The full quote is: 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: 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). 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). 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: