XSF Discussion - 2019-10-28

could be nice for a SFW-preview of NSFW-pictures though

Again, how's that actually better than a low res jpeg?

Ge0rG: just from doing some experiments jpegs thumbnails look much bigger

Daniel: you mean the number of bytes?

Yes file size

Is that really significant, provided that we have XEP-0231 already in place?

given the JPEG thing, one could use the same data of JPEG to render a blurhash

I'm not able to generate jpeg images smaller than 3K

OK 2.8k if I don't store exif data

what's the "size" of a TLS handshake to HEAD an image URL?

Ge0rG had 667 bytes the other day

Normally, I'm all in for squeezing the most out of the bytes, and I love all the "42 bytes ELF file" style blog posts, but the question that we need to answer here is: are 2KB spared per image share worth adding a dependency on some third-party's personal pet project that doesn't even have a specification?

Ge0rG, something about HSLuv?

Ge0rG, BlurHash has the Algorithm.md which enables easy re-implementation.

(for certain definitions of easy)

(you need to know how to apply a DCT)

The question is if the build in upscaler and compression methods in Android (for example) are good enough to provide similar output

no.

Or if I'm ending up including an external jpeg encoder then

even that won’t help

you’ll need a custom decoder to render it as nicely as blurhash

you’ll have to decode the 8x8 block yourself and render it onto a larger canvas yourself, by evaluating the cosine functions

that’s very different from taking the rendered 8x8 block and upscaling it with whatever filter

well using convert --thumbnail 8 and then using the gimp upscaller produces images that look nice

Let's bundle both of ImageMagick and GIMP!

with a small enough file size. but then i need an upscaler that is as good as what ever gimp does; and an encoder that can strip all the crap such as imagemagick

Does the blurhash include the actual image resolution?

that's by the way also a good question; because we need at least the aspect ratio

Daniel: I wouldn't settle with just that, you also often need to know whether to down or up scale.

Also rounding errors between the ratio and the final resolution

I think that SIMS is much more needed than blurhash, and that we could add blurhash as an optional field into SIMS

I wish we had Sims without the references

replacing the referenced text with media content

yeah, the references part is a bit of overkill

I created https://modules.prosody.im/mod_muc_media_metadata.html

and someone (jonas’ I think?) suggested it should use SIMS, so I'll probably make that switch

Essentially the MUC server does a HEAD on the URL, and embeds the data into the stanza

Does it make sense to reuse https://xmpp.org/extensions/xep-0131.html ?

> The Store header enables a sender to specify whether the stanza may be stored or archived by the recipient. The allowable values for this header are "true" and "false".

We have such a treasure trove

*twitch*

Somebody needs to start axing duplicate functionality, except that it's never a perfect overlap, but always different subsets. This is Venn Diagram Hell

Zash, it may be sensible - we can include etag for example

I should have used that from the start

> Mastodon - The Mastodon decentralised social media network uses BlurHashes both as loading placeholders, as well as for hiding media marked as sensitive.

MattJ: SIMS would ber perfect for the mod imho.

and with xep-0131 I think it's not that clear how to handle multiple media links in one message

rion, does any client support oob-based http file transfer with multiple links in one message? I don't think it makes a lot of sense to send multiple files in one message

No sending foto albums?

Zash, your photo album should be a pubsub node or something so that you can add further images to it

what clients support *that* ?

Salut à Toi should.

larma: my client can send multiple SIMSs in one message regardless http or not.

but multiple SIMS is not the same as multiple oob file transfers

I don't think you can translate between the two server-side

OOB can be mapped to SIMS

yes, but not the other way round

SIMS -> OOB would be lossy, yes

and rion was bringing up multiple links in one message which I think is not supported by oob file transfer (but isn't properly written down anywhere)

I have ran across use cases for multiple images attached to some text, which as you said no clients really support, say a "refer to the differences in these 2 screenshots" message

If we don't move to SIMS for file transfer soonish, we should probably write down the oob file transfer "standard"?

"standard" = what most current clients do for sending a file that was uploaded with http file upload

Standard !== what is specified? :p

Serverside OOB to SIMS translation would not be difficult. Ie mapping the URL into SIMS (and maybe description, if anyone ever uses that)

what for?

why another server translation xep

SIMS is not implemented because it is unfinished

i saw countless emails to standards with discussions

no update to the xep whatsoever

pep., AFAIK there is no real specification for that. We have oob but nobody understands it as "display this file inline" or "display the link at all". We have http upload to upload files. And now apparently what is done is to put the URL of http uploaded file in both body and oob to indicate "display file inline or as file transfer".

larma, I agree nothing about body==oob url is standardized :)

So we should make a short informational XEP out of that?

That'd be a first step

Should at least be a historical XEP.

what purpose does this serv

documenting things for the sake of documenting or what?

Well apparently there are things not clear about it

some this get documented for the sake of documenting then the XEP gets rejected https://xmpp.org/extensions/inbox/omemo-media-sharing.html

lovetox, sure documenting.

(even though basically all the clients implement it anyway?)

What about new clients appearing, how do they even know

lovetox, when you write a new client, currently you have to read other clients to understand you have to do that for images to appear.

Documenting and discussing how to do things is our purpose here.

moparisthebest, it should probably get resubmitted as historical.

but it's not historical, all the clients do this

It still didn’t get through any standardisation process, and is a historical artifact.

this all is nonesense for me sorry

moparisthebest: lots of clients do lots of "historical" things still

That’s enough for it to be historical.

you cannot dictate what to display inline in other clients

See OTR, see vCard-temp.

> An Historical XEP documents a protocol that was developed before the XSF's standards process was instituted

there can never be a standard that forces me as a client to display something inline

i see no purpose for this at all

all clients do this and there isn't even a proposed replacement yet? still historical?

larma: Maybe we should s/before/outside/ then?

you send me a SIMS message, guess what if i feel like it having a option to not display it inline, then thats it

> An Informational XEP typically defines best practices for implementation or deployment of an existing protocol

ah ok I guess maybe it fits that larma

even if the XEP is called Inline media

its the responsibility of the client to decide what to display inline and what not

larma, not that body==oob url is "best practices"

it's just what's out there :)

i even display images inline that you send without oob, just paste a url into the chat, what now, are we going to document that also?

yeah but it says "typically defines best practices" so "bad practices" are also fine 😉

Also XEP-0201 😉

also body==url, never meant "display this inline"

it meant, this is a filetransfer of a file uploaded with http upload

knowing that a client can act on it

lovetox, agree

but nobody ever said, you have to display this now inline

but again, this is not written down anywhere

why invest the time into changing old XEPs, if we could work on finishing SIMS and migrate

lovetox, if you can do that, great

Please change all clients :)

I don't think there is consensus on what the correct SIMS is.

no the author should react to the countless standard mails

yeah then discuss whats correct

no future client should be forced to implement oob

lovetox, "no future client should be forced to implement oob" unrealistic, also it is just about to be part of the CS2020

ok if i hear compliance suite im out :D

no sorry go on, im grumpy had a long day, document away :)

but please stay away from dictating UI behavior on the receiving side

I would never want a XEP to dictate UI. But we definitely need a way to indicate "this is a link to a third party resource" vs "this is a file transfer"

Because users don't need consistency between different implementations, or between sender and recipient of a message.

Ge0rG, we can still suggest UI outside XEPs

but client consistency outside of protocol does not belong in XEPs IMO

and client serv different communitys with different needs

*thumbs up reaction*

larma [21:16]: > "this is a link to a third party resource" vs "this is a file transfer" Unfortunately, there is no difference between those from a security point of view

how are they different at all actually?

a client may want to react differently

moparisthebest: the former could be anything, not just an image

if a "file transfer" comes from a contact in my roster he could have a policy that this is trustable enough to just download and display inline

while your contact just pasting links he found somewhere

is maybe not something i want to immediatly download

I'm still not seeing the difference

not downloading vs downloading

A file transfer *should* have a fixed hash and the sender sending that hash (ideally in a cryptographically signed message) thus sends a very specific file, if the downloaded resource does not match, the file transfer failed. A link to an external resource is usually handled by whatever local software is responsible for that uri protocol, thus could also extend beyond the http protocol (like a vnc uri to open your vnc viewer) and the resource behind the URI can change or be non global...

If I'm sharing memes with my wife, why would I want it to display differently if I download and re-upload the meme vs paste the link?

moparisthebest, its not about what you want

you can not want anything for another client

it is in the sense that not even *my* client can guess what I want

If your client displays external resources inline under certain criteria, that's something completely different

so certainly the remote client cannot guess

he does not need to guess, if you tell him

hence the protocol we are discussing

It's a known attack against clients that show "previews" to fake the preview to lure users into opening shady websites

and the difference

and sure you can write up a protocol for "hey the sender wants you to display it like X" but that's still useless because the sender won't do it

im not sure what you are trying to say

moparisthebest, it's not about what is possible, but about what makes sense

clients react to that differently already

and it works just fine

> it (body==oob.url) meant, this is a filetransfer of a file uploaded with http upload really? that doesn't seem like something that needed to be communicated.

the http upload part, that shouldn't matter

but it does

it means a user selected a file on his harddrive, and wants to transfer it to you

only because thats done via http, does not mean every url i paste into a chat is now a filetransfer

that's a pretty dumb restriction anyway, I ran into this the other day actually

wat

simple use case, i want to show a gallery of received media from a contact

take a picture of the kid, want to send it to my Mom and my Wife, http upload to Mom, now do I waste space on the server by http upload'ing it to wife also, or just copy/paste the URL and paste to wife?

it sucks the second way changes how it's displayed on wife's end :)

A simple solution for that would be for your client to have a cache of recently uploaded files.

No need to change the UI, just it wouldn’t transfer it again and instead reuse the URL it already got.

yeah clients could be just smart about that

or you could stop relying on the sending client to decide which images to display inline or not, and have that be a preference of the recieving client as it should be :)

but it is, you got it backwards

as we said, the sending client just tells this is a file from my harddrive

the receiving client decides what it does with that information

"whether this came from my hardrive or not" is a really dumb distinction though

this

I don't understand why it would matter in any concievable way

it makes no sense to me

because its more trustable

why???

why is a http upload link on my server I uploaded 2 seconds ago less trustable than one I'm uploading now

or, really anything else

It's an URL... twice. It means you sent a link to some out of band resource that you can click on if your client doesn't do something with it.

you can make a client take any pasted http link, and pretend it's an http upload when sending it right?

like presumably a gajim plugin could do that?

so how can the recieving client place any trust in that

`/embed arbitrary-url-here` in poezio for example, I've done that a bunch of times

because you can share a link by accident or unkowing that it causes harm

if you select a picture from your harddrive, it will most likely not

and as i said above, media gallery of filetransfers

but yeah i know other messengers record every link as media that was sent

I think it is easier to grasp if you put in the hash of the file. It gives certainty to the recipient that they receive the correct file and it requires the sender to actually have the file before "sending" it, but it doesn't need to upload it if it's already online

thats why everybody with whatsapp ends up with X memes in his gallery shared by some people in groupchats

uh sorry but I see people accidentally upload pictures in mucs all the time?

probably more often than paste links even

in fact it's pretty easy to open a picture in the android gallery, click share, then mis-click the conversation muc

moparisthebest, i think you misunderstood

its not about accidently sharing a file

a file will never harm your contact

that doesn't sound like a given

a link could that you share further could

they... are the same though...

technially yes nobody argues anything else :)

if I paste a link, you have no idea if I uploaded it or if it was already there, if I send you http upload xml, you have no idea if I uploaded it or if it was already there, what's the difference?

but one is a link someone wants you to see, and the other is a file he wanted you to have

moparisthebest, its not about security, its about the intentions

I tend to agree with lovetox to some extent

it's about nothing because there is no difference at all

if it was about security i could not rust anything that does not come from my server

weird things happen for example with Conversations when you OOB-tag arbitrary links

i agree its a very subtle difference

I have code in JabberCat which simply OOB-tags all URL-only posts

and i agree most clients will probably not make it

which means that C will render them as file downloads

but its still worth to have that hint

instead of as links

and if its just to sort, link meme shares into another category on harddrive

which hint though? it seems like we are taking a mostly arbitrary "this is from my hard drive" hint, and interpreting it instead as a "this is ok to display inline" hint

then actuall private files someone uploaded

moparisthebest, no nobody says its ok to display inline

thats a determination a client can make, but nobody suggest to do it

except all clients that have it implemented that way of course

as i said simple usecase, i dont want your meme shares from 9gag in my file gallery

write up on things I'd change in SIMS (including the name): https://gist.github.com/mar-v-in/f154b97ddc9869c1132b12bcd9a14f38

I like how SIMS just assumes e2e doesn't exist lol

makes it easy, don't have to answer any hard questions, also makes it un-useable in the real world but that's just a minor detail right?

moparisthebest, does it? I'd say it assumes we have full stanza encryption 😉

that falls under "un-useable in the real world" I guess :)

since there aren't any full stanza encryption methods implemented anywhere?

yes they are

openpgp

Can't you do E2E encrypted file transfers with Jingle? SIMS can use that.

also dont know what that has to do with E2E at all

OX? there is a XEP, iirc it's not actually implemented anywhere

moparisthebest, it is

it is, Gajim has a plugin :D

hashes/size/name/type all that private stuff that should probably be encrypted

and also its not hard to implement

developers just have other stuff to do right now

also smack supports it

moparisthebest, what is private about that? these are all things i can get from a oob url if i download the file

so oob url is ok

but SIMS is not?

not one of these URLs: https://xmpp.org/extensions/inbox/omemo-media-sharing.html

SIMS is just, i tell you the metadata before you have to download the file

moparisthebest, we talk about media sharing XEPs, and if i want to share a picutre here in this MUC

E2E is out of the question

If you encrypt the file before uploading you should probably also encrypt SIMS

so why should i not be nice and sent metadata with so clients dont have to download to get them

If you don't encrypt the http file upload, it makes little sense to encrypt SIMS data (like hash), but if you do encrypt the http file upload you also should encrypt such

of course this xep is only to be used with full stanza encryption if your conversation is encrypted

that goes without saying

but a media sharing XEP must not care if currently full stanza encryption in use or not

lovetox, people for some reason always assume that encryption is a body-only thing and thus complain about SIMS leaking things

yes, ie the only encryption that has ever been actually deployed :)

moparisthebest, in the meantime, if you don't think about it, it's probably never going to become viable

I'm also not sure the point of letting clients lie about stuff

if you duplicate where info is, then you have to have rules about when it doesn't match

"duplicate where info is" what are you referring to?

if you send me a link to the file, I have it's size, content type, hash etc, after I get it

what's the point of also sending all that? what if what you send me doesn't match with what I get?

if it doesn't match your download failed. You have a corrupt file and shouldn't tell the user "that's what the other person send you" because it's not true

content type is not part of the file, so it's good you actually get it, size is useful to know before downloading it

size would be useful to know before downloading, if you could trust it

but you can't

I'd argue that it is still useful

You can, just stop downloading after you reached this amount of bytes, if the link provides you with more data, then it's corrupt

or malicious

which is the same for the user (file transfer failed)

Anyone interested in DKIM for XMPP?

The what, why?

oh dear

larma, what would you need that

MUC? .. because DKIM works so well for mailing lists

But, uh, please don't

To prove that a message is indeed coming from the server it's saying it's coming from?

I'd rather do e2ee and verify that identity

s2s has pretty good security already, with mutual TLS certificate authentication.

Zash, the idea being that MUC can impersonate anybody, I guess..

I see no need for DKIM, except possibly in some relay case like MUC, but meh.

And you need to trust MUC same as you trust your server. (Note that I'm not especially arguing in favor of DKIM)

I'm quite happy leaving crypto stuff to the TLS library, thankyouverymuch.

:)

And, mailing lists being equivalent to MUC, which is where I encountered enough problems with DKIM to just throw it all out and carry on with my life.

I imagine it'd be easier to apply to XMPP tho.

Well, a proper client should ignore the origin information in messages in a private/non-anonymous MUC on an untrusted server right now.

Zash, that's only because mailing lists modify the mail but claim it's from the original author, which is exactly what DKIM should prevent (for good reason)

Dkim works on well configured mailing lists just fine, you are thinking of SPF that they break

Mailing lists don't break SPf

moparisthebest, mailing lists break dkim

pep., they don't need to

They don't need to indeed

Most do

Misconfigured ones that mangle the message only

it's just because they a) want to display the original author in from and b) want to add a footer to the message (effectively the same as modifying it)

b) also breaks PGP signatures \o/

Nice things. Email. Pick one.

Email and DANE seems to do okay tho.

Zash, actually it doesn't (or doesn't need to) as you can concat with MIME

Picking nice things is a real option?

The nice thing is a lie.