[Standards] SIMS issues

Marvin W xmpp at larma.de
Sat Sep 7 10:50:50 UTC 2019


On 07.09.19 11:55, Daniel Gultsch wrote:
> To cover the use case Sergey is talking about here (stand alone voice
> message, stand alone image, stand alone file) without any description
> wouldn’t it make more sense to be able to put a sims as a direct child
> of a message (and essentially the only child ( + origin-id, 184
> request)?
> 
> I mean it is nice and all that it can _also_ be used within a
> reference but i don’t understand the hard dependency (that the XEP in
> it's current state implies) on references.

I actually think the current way of SIMS is even semantically wrong,
because it puts <media-sharing> into <reference />. However the message
usually does not reference a media sharing, it *is* the media sharing
that maybe has a comment attached (like in the examples in XEP-0385 itself).

Therefor even the case of referencing might even be better realized
using two messages where one is the media sharing and one is a message
with a reference to that media sharing:

<message id=A>
  <media-sharing>[...]</media-sharing>
</message>

and

<message>
  <body>[...]</body>
  <reference uri="xmpp:jid?message=A"/>
</message>.

This has the positive side-effect that SIMS can have a proper fallback body:

<message id=A>

<body>https://download.montague.lit/4a771ac1-f0b2-4a4a-9700-f2a26fa2bb67/summit.jpg
(summit.jpg, 3032449 byte)</body>
  <media-sharing>[...]</media-sharing>
</message>


> As I see it a lot of developers are currently in the market for a
> replacement for the current usage of the x-oob tag and are not
> necessarily looking for anything more complicated like references
> (which involve having to implement an URI parser among other things)
> Therefor I see a danger in essentially forcing those people to
> implement half-assed references that are only an empty, mostly unused
> reference wrapper around the sims element. This has the potential of
> getting us into compatibility trouble if later we will actually use
> references for something more than this.
The clients would still need to implement XEP-0372 (or parts thereof)
for the <reference />s inside the <media-sharing>'s <sources>. I
actually like using the concept of references here, because it seems to
be exactly what XEP-0372 is for: referencing resources, both external
(http url) and internal (jingle).

As we now do have XEP-0420 (even though not realized yet) and XEP-0373,
we don't need to rely on transporting the download link and encryption
information in the only encrypted part of messages, the body (like in
OMEMO Media sharing protoxep), so I feel SIMS might become more
widespread soonish.

In the context of encryption, I'd also like to express my hope that we
also make up some concept for sharing encrypted files with SIMS, so that
we can get rid of `aesgcm://` links longterm and don't need to use them
inside <media-sharing>...

Marvin


More information about the Standards mailing list