26 Apr
2026
26 Apr
'26
7:07 p.m.
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. 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.
On receive of a message including a
<file-sharing/> element, the receiving
entity SHOULD lookup in a local storage, whether the file with any of the
proivded hashes has already been retrieved and is available
I agree, but difficult to do if there are not such hashes...
Interestingly, later:
If no <hash/> is provided or the <hash/>
elements provided use
unsupported algorithms, receiving clients MUST ignore any attached
sources from other senders and only obtain the file from the sources
announced by the original sender
Which now implies that no hashes is kind of ok, but nerfs source attaching.
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.
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?