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.
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.
Also, XEP-0234 mandates (MUST) the use of a <hash/> or <hash-used/> inside the <file/> which
Since this is most of the purpose of using sims or sfs (to get the hash) it seems reasonable? Though if we really had some actual use case to make it optional I don't see why we could not.
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.
Sure, for example https://datatracker.ietf.org/doc/html/rfc5854 also defines an equivalent element.
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).
Sure, the example in OOB is also of a jpg. Doesn't mean oob is only for pictures.
Anyway, SFS was always intended as a successor to SIMS, not a competitor.
Then why the new XEP number and changed design?
Also supported not just by SIMS but even by OOB.
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).
It's definitely compatible with the hack some clients use for single file, and AFAIK most SIMS implementations indeed follow this hack just for compatibility with such clients. For multi file there is no support in clients whech require the hack but including the fallback urls is still sensible of course so that they see something useful.
- 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.
Indeed. OOB also clearly shows this and I always show both body and atdachments even for just OOB. Snipping out fallbacks of course but that's just a UI choice.
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.
I think I've been pretty clear oves the years that my main objection is the use of xep0446.