Hi Marvin
On 03.07.21 17:01, Marvin W wrote:
Hi,
Remember that URLs are not guaranteed to be globally reachable
(examples: restricted to company network or requiring authentication).
For most users it's not easily understandable if a URL can be reached by
the recipient client or not. Thus sending an URL of funnypics.com
instead of downloading that file and uploading it can lead to unexpected
behavior.
If you're behind a corporate firewall, then you're probably already
aware that certain sites are blocked, so the behavior isn't necessarily
that unexpected.
I'm happy to leave the decision to the user whether they want to share a
URL or a file. Not all servers support HTTP file upload and not all
clients support Jingle, so sharing via 3rd party URL is the only option
some people have.
Given that users already share URLs, I would like to have better
metadata so that I can provide a better UX.
Fetching files from untrusted third-party servers is a privacy
nightmare. We already have this issue with oob file sharing and I
remember a proposal to restrict automatic fetching to known-good servers
or if the domain of the URL matches the domainpart of the JID (or is a
subdomain thereof). This wouldn't work when we want to accept sending
URLs from funnypics.com.
Sounds like configuration, and not something that would ever be universal.
When doing inline sharing, the sending client would want to display the
media inline as well. For this it also needs to fetch the media anyway
and thus calculating the hash would be easy.
I don't see this as simply "inline sharing" and I don't share the
assumption that you'll always show the image to yourself when you're
sharing the URL.
Also, at least in my web client, the images are shown asynchronously
after the message has been sent, and they're shown via <img> tags, so
the browser is responsible for fetching the image and caching it, not my
client.
Also, especially when sharing image files, it would be great to have a
thumbnail so that you don't have to fetch the full (maybe high quality)
image when not explicitly needed, i.e. on mobile. To generate a
thumbnail, the sending client has to first download the image.
Nice to have, but not essential.
Providing the hash of the file is a good way to allow caching. Thus if
you receive the same meme several times, but from different URLs, the
hash will allow you to only download it once. This is not possible via
ETag, due to ETags not following a common generation scheme.
Indeed, I'm however dealing with the case where it's not deemed
desirable to first download the entire file in order to generate a hash.
When receiving a file via SIMS, the URL to the file is typically not
going to be exposed to the end user (instead the inline media or
thumbnail and maybe filename are displayed). Thus when forwarding the
file to another contact, users will typically want to do this directly
instead of through copying the URL. In that case, all the details from
SIMS can be just forwarded as is. I'd also like to mention that it
probably is a rare case (although it may happen from time to time) where
you forward a file without downloading it first.
I read a lot of assumptions in this last paragraph that don't match up
to the use-case that I have and seem to come from the perspective of a
desktop or perhaps mobile client developer.
When sharing video URLs on the web, the browser is not going to download
the entire video before starting to show it to you in a <video> tag.
I don't know any instant messaging client that would have the equivalent
of sharing a URL using SIMS. Some clients do allow sending a URL as a
message and then have the server attach some SIMS-like metadata to that
message.
Yes, and that's another use-case where it might be preferable to simply
do a HEAD request and use the headers rather than downloading the whole
file.
There's also client side generated link previews, but these are
typically not the same as I'd expect SIMS to be used, because links
don't necessarily qualify as media (although I agree media is a very
broad term and thus probably most things that URLs point to are actually
somewhat media).
When they link directly to media they do qualify as media in my opinion.
Currently, when I share an image from my browser on Android, I can just
use the browsers "share image" feature (long press on the image) and
select Conversations. The browser will transfer the image to
Conversations without the need to download it again (might also actually
do another download, but that's another story) and Conversations uploads
it using HTTP file upload as usual.
This works great for me and I wonder what would be wrong with this approach?
Nothing, but I'm working on a web client, not a mobile client.
- JC
On 02.07.21 12:15, JC Brand wrote:
Hi everyone
I've been reading XEP-0385 SIMS with an eye towards potentially
implementing it, when I noticed that a XEP-0300 hash is required, in
order to allow integrity checking and caching.
In the introduction of SIMS, the following is written:
"This proposal aims to provide a protocol that will enable XMPP clients
to implement a great user experience (UX) around the process of sharing
media in conversations."
I think making inclusion of the file hash mandatory is at odds with that
goal, the reason being that a lot of the media being shared in chats is
shared as URLs to 3rd parties where the media is hosted.
In other words, the sharer of the media doesn't necessarily know the
hash of the media because it was never on their own machine to begin with.
Here's the use-case I have in mind:
Romeo sees a funny picture on funnypics.com. He right-clicks on the
picture, copies the URL and sends it to Juliet. Before the message is
sent, Romeo's client does an HTTP HEAD request, to get information on
the URL, and learns that its an image.
Here's the response:
HTTP/2 200
last-modified: Fri, 02 Jul 2021 02:46:55 GMT
etag: "a1d5ea7e796f5da6980bed86a8396664"
content-type: image/jpeg
cache-control: public, max-age=31536000
accept-ranges: bytes
date: Fri, 02 Jul 2021 06:44:39 GMT
access-control-allow-methods: GET, OPTIONS
access-control-allow-origin: *
content-length: 110220
The "content-type" header can be used for the SIMS <media-type> tag and
the "content-length" header for the <size>.
The server also responds with an "etag" header, which can be used for
caching, but unfortunately not for integrity checking, since the method
by which it's generated is not specified.
If the etag is passed along via SIMS (instead of the hash), the
receiving client could also check whether it matches what's returned by
the webserver, although I'm not sure what conclusions can be drawn if
they don't match.
Before someone says that this scenario is not relevant to what SIMS is
trying to do, please note that this problem also occurs when someone
shares a file via HTTP upload and then the receiving party copies and
pastes that URL in a message to someone else. Perhaps an intelligent
enough client might go and get the hash from the original SIMS data and
then add that to the newly sent message, but that seems a bit contrived
to me and might not always be feasible.
So... back to the scenario. After Romeo's client has received the HEAD
headers, it can then construct a SIMS element with it.
<messageto='jul...@shakespeare.lit'from='ro...@montague.lit'><body>Look
at this funny cat
picture</body><referencexmlns='urn:xmpp:reference:0'begin='17'end='20'type='data'><media-sharingxmlns='urn:xmpp:sims:1'><filexmlns='urn:xmpp:jingle:apps:file-transfer:5'><media-type>image/jpeg</media-type><name>icanhazcheeseburger.jpg</name><size>110220</size><headersxmlns='http://jabber.org/protocol/shim'><headername='ETag'>some-long-opaque-string</header></headers><desc>Fat
cat that looks like it wants a
cheeseburger</desc></file><sources><referencexmlns='urn:xmpp:reference:0'type='data'uri='https://funnypics.com/icanhazcheeseburger.jpg'/></sources></media-sharing></reference></message>
Note the inclusion of the ETag header (as defined in "XEP-0150: Use of
Entity Tags in XMPP Extensions") and the omission of a XEP-0300 hash
element.
If, for some reason the content-type and content-length headers can't be
used for the <size> and <media-type> tags, then they can also be
included as XEP-0131 headers (like the Etag).
So, my proposal is that XEP-0385 be updated so that the XEP-0300 hash
requirement gets relaxed to a SHOULD and that the inclusion of the Etag
header be documented as an alternative in case a hash is not feasible.
There might also be cases where neither a hash or an Etag header is
available.
I'd be happy to make the necessary changes and submit a pull request.
Regards
JC
_______________________________________________
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
_______________________________________________
_______________________________________________
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
_______________________________________________
