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