could be nice for a SFW-preview of NSFW-pictures though
zachhas left
zachhas joined
pdurbinhas left
Nekithas left
Nekithas joined
lorddavidiiihas left
lorddavidiiihas joined
Ge0rG
Again, how's that actually better than a low res jpeg?
zachhas left
zachhas joined
j.rhas left
jabberjockehas left
Daniel
Ge0rG: just from doing some experiments jpegs thumbnails look much bigger
Ge0rG
Daniel: you mean the number of bytes?
Daniel
Yes file size
Ge0rG
Is that really significant, provided that we have XEP-0231 already in place?
waqashas left
chronosx88has joined
jonas’
given the JPEG thing, one could use the same data of JPEG to render a blurhash
mimi89999has left
mukt2has left
mimi89999has joined
Daniel
I'm not able to generate jpeg images smaller than 3K
zachhas left
zachhas joined
Daniel
OK 2.8k if I don't store exif data
mathijshas left
mathijshas joined
chronosx88has left
Ge0rG
what's the "size" of a TLS handshake to HEAD an image URL?
jonas’
Ge0rG had 667 bytes the other day
chronosx88has joined
Dele (Mobile)has joined
lorddavidiiihas left
Ge0rG
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?
jonas’
Ge0rG, something about HSLuv?
jonas’
Ge0rG, BlurHash has the Algorithm.md which enables easy re-implementation.
jonas’
(for certain definitions of easy)
jonas’
(you need to know how to apply a DCT)
lorddavidiiihas joined
Daniel
The question is if the build in upscaler and compression methods in Android (for example) are good enough to provide similar output
jonas’
no.
Daniel
Or if I'm ending up including an external jpeg encoder then
jonas’
even that won’t help
jonas’
you’ll need a custom decoder to render it as nicely as blurhash
jonas’
you’ll have to decode the 8x8 block yourself and render it onto a larger canvas yourself, by evaluating the cosine functions
jonas’
that’s very different from taking the rendered 8x8 block and upscaling it with whatever filter
Daniel
well using convert --thumbnail 8 and then using the gimp upscaller produces images that look nice
Ge0rG
Let's bundle both of ImageMagick and GIMP!
Daniel
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
Dele (Mobile)has left
Ge0rG
Does the blurhash include the actual image resolution?
Dele (Mobile)has joined
Daniel
that's by the way also a good question; because we need at least the aspect ratio
Ge0rG
Daniel: I wouldn't settle with just that, you also often need to know whether to down or up scale.
Ge0rG
Also rounding errors between the ratio and the final resolution
mathijshas left
mathijshas joined
Ge0rG
I think that SIMS is much more needed than blurhash, and that we could add blurhash as an optional field into SIMS
Steve Killehas left
Daniel
I wish we had Sims without the references
zachhas left
zachhas joined
mathijshas left
mathijshas joined
rionimplemented it with references and it works quite well
rion
replacing the referenced text with media content
Ge0rG
yeah, the references part is a bit of overkill
Steve Killehas joined
goffihas joined
derdanielhas left
intosihas joined
Zashhas left
Zashhas joined
mukt2has joined
Dele (Mobile)has left
j.rhas joined
mukt2has left
ajhas left
zachhas left
zachhas joined
jubalhhas joined
adiaholichas left
adiaholichas joined
Dele (Mobile)has joined
winfriedhas left
winfriedhas joined
winfriedhas left
winfriedhas joined
Dele (Mobile)has left
Dele (Mobile)has joined
j.rhas left
zachhas left
zachhas joined
mukt2has joined
debaclehas joined
zachhas left
zachhas joined
jabberjockehas joined
MattJ
I created https://modules.prosody.im/mod_muc_media_metadata.html
MattJ
and someone (jonas’ I think?) suggested it should use SIMS, so I'll probably make that switch
adiaholichas left
MattJ
Essentially the MUC server does a HEAD on the URL, and embeds the data into the stanza
Zash
Does it make sense to reuse https://xmpp.org/extensions/xep-0131.html ?
ajhas joined
larmahas left
MattJ
> 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".
MattJ
We have such a treasure trove
jonas’
*twitch*
Ge0rG
Somebody needs to start axing duplicate functionality, except that it's never a perfect overlap, but always different subsets. This is Venn Diagram Hell
zachhas left
zachhas joined
larmahas joined
mukt2has left
MattJ
Zash, it may be sensible - we can include etag for example
MattJ
I should have used that from the start
Dele (Mobile)has left
Dele (Mobile)has joined
Dele (Mobile)has left
Dele (Mobile)has joined
Dele (Mobile)has left
Dele (Mobile)has joined
eevvoorhas joined
eevvoorhas left
j.rhas joined
zachhas left
zachhas joined
jmpmanhas joined
eevvoorhas joined
debaclehas left
jabberjockehas left
mukt2has joined
zachhas left
zachhas joined
eevvoorhas left
mukt2has left
neshtaxmpphas left
j.rhas left
Steve Killehas left
pdurbinhas joined
Steve Killehas joined
Dele (Mobile)has left
Dele (Mobile)has joined
zachhas left
lskdjfhas joined
zachhas joined
pdurbinhas left
jabberjockehas joined
mukt2has joined
debaclehas joined
Syndacehas left
Syndacehas joined
eevvoorhas joined
mukt2has left
adiaholichas joined
debaclehas left
adiaholichas left
eevvoorhas left
adiaholichas joined
emushas joined
mukt2has joined
zachhas left
zachhas joined
eevvoorhas joined
jubalhhas left
Mikaelahas left
jubalhhas joined
Mikaelahas joined
eevvoorhas left
eevvoorhas joined
jubalhhas left
zachhas left
zachhas joined
j.rhas joined
matlaghas left
matlaghas joined
krauqhas left
krauqhas joined
mukt2has left
zachhas left
zachhas joined
neshtaxmpphas joined
mukt2has joined
zachhas left
zachhas joined
jabberjockehas left
jmpmanhas left
Chobbeshas joined
jabberjockehas joined
adiaholichas left
jabberjockehas left
jabberjockehas joined
adiaholichas joined
Shellhas joined
zachhas left
zachhas joined
davidhas joined
pdurbinhas joined
mukt2has left
mukt2has joined
Steve Killehas left
zachhas left
pdurbinhas left
zachhas joined
Steve Killehas joined
archas left
archas joined
Syndacehas left
Mikaelahas left
Mikaelahas joined
jubalhhas joined
zachhas left
zachhas joined
jubalhhas left
jubalhhas joined
jubalhhas left
jubalhhas joined
jubalhhas left
jubalhhas joined
mukt2has left
chronosx88has left
jubalhhas left
Syndacehas joined
chronosx88has joined
patrickhas joined
zachhas left
zachhas joined
mukt2has joined
ajhas left
Chobbeshas left
zachhas left
zachhas joined
Syndacehas left
mukt2has left
zachhas left
zachhas joined
mukt2has joined
debaclehas joined
Syndacehas joined
Chobbeshas joined
Chobbeshas left
davidhas left
davidhas joined
eevvoorhas left
mukt2has left
Nekithas left
zachhas left
zachhas joined
pdurbinhas joined
mukt2has joined
neshtaxmpphas left
neshtaxmpphas joined
emushas left
Chobbeshas joined
zachhas left
zachhas joined
waqashas joined
pdurbinhas left
mukt2has left
Chobbeshas left
zachhas left
zachhas joined
mukt2has joined
davidhas left
davidhas joined
j.rhas left
jubalhhas joined
j.rhas joined
zachhas left
zachhas joined
emushas joined
mukt2has left
zachhas left
zachhas joined
winfriedhas left
winfriedhas joined
jubalhhas left
jabberjockehas left
mathijshas left
mathijshas joined
mukt2has joined
jonas’
>
Mastodon - The Mastodon decentralised social media network uses BlurHashes both as loading placeholders, as well as for hiding media marked as sensitive.
matlaghas left
zachhas left
zachhas joined
matlaghas joined
mukt2has left
winfriedhas left
winfriedhas joined
lovetoxhas joined
!XSF_Martinhas left
!XSF_Martinhas joined
adiaholichas left
adiaholichas joined
zachhas left
zachhas joined
mukt2has joined
pdurbinhas joined
davidhas left
Steve Killehas left
pdurbinhas left
davidhas joined
Steve Killehas joined
zachhas left
zachhas joined
adiaholichas left
adiaholichas joined
lorddavidiiihas left
lorddavidiiihas joined
mathijshas left
mathijshas joined
!XSF_Martinhas left
neshtaxmpphas left
zachhas left
zachhas joined
jubalhhas joined
jubalhhas left
jubalhhas joined
jubalhhas left
jubalhhas joined
mukt2has left
mukt2has joined
jubalhhas left
jubalhhas joined
zachhas left
zachhas joined
jubalhhas left
Dele (Mobile)has left
zachhas left
zachhas joined
Shellhas left
Shellhas joined
Yagizahas left
jubalhhas joined
jubalhhas left
winfriedhas left
winfriedhas joined
winfriedhas left
winfriedhas joined
!XSF_Martinhas joined
winfriedhas left
winfriedhas joined
zachhas left
zachhas joined
mathijshas left
mathijshas joined
winfriedhas left
winfriedhas joined
mathijshas left
mathijshas joined
xalekhas joined
matlaghas left
matlaghas joined
Nekithas joined
zachhas left
zachhas joined
Dele (Mobile)has joined
pdurbinhas joined
jubalhhas joined
pdurbinhas left
andrey.ghas left
Wojtekhas joined
zachhas left
zachhas joined
rion
MattJ: SIMS would ber perfect for the mod imho.
rion
and with xep-0131 I think it's not that clear how to handle multiple media links in one message
lorddavidiiihas left
jubalhhas left
lorddavidiiihas joined
larma
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
Zash
No sending foto albums?
andrey.ghas joined
larma
Zash, your photo album should be a pubsub node or something so that you can add further images to it
moparisthebest
what clients support *that* ?
Link Mauve
Salut à Toi should.
rion
larma: my client can send multiple SIMSs in one message regardless http or not.
larma
but multiple SIMS is not the same as multiple oob file transfers
larma
I don't think you can translate between the two server-side
Zash
OOB can be mapped to SIMS
larma
yes, but not the other way round
Zash
SIMS -> OOB would be lossy, yes
LNJhas left
larma
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)
patrickhas left
moparisthebest
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
larma
If we don't move to SIMS for file transfer soonish, we should probably write down the oob file transfer "standard"?
larma
"standard" = what most current clients do for sending a file that was uploaded with http file upload
mukt2has left
pep.
Standard !== what is specified? :p
Zash
Serverside OOB to SIMS translation would not be difficult. Ie mapping the URL into SIMS (and maybe description, if anyone ever uses that)
lovetox
what for?
lovetox
why another server translation xep
lorddavidiiihas left
lovetox
SIMS is not implemented because it is unfinished
lovetox
i saw countless emails to standards with discussions
lovetox
no update to the xep whatsoever
lorddavidiiihas joined
larma
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".
balu_der_baerhas joined
pep.
larma, I agree nothing about body==oob url is standardized :)
zachhas left
zachhas joined
larma
So we should make a short informational XEP out of that?
pep.
That'd be a first step
Link Mauve
Should at least be a historical XEP.
balu_der_baerhas left
lovetox
what purpose does this serv
lovetox
documenting things for the sake of documenting or what?
larma
Well apparently there are things not clear about it
moparisthebest
some this get documented for the sake of documenting then the XEP gets rejected https://xmpp.org/extensions/inbox/omemo-media-sharing.html
pep.
lovetox, sure documenting.
moparisthebest
(even though basically all the clients implement it anyway?)
pep.
What about new clients appearing, how do they even know
Link Mauve
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.
chronosx88has left
Zash
Documenting and discussing how to do things is our purpose here.
Link Mauve
moparisthebest, it should probably get resubmitted as historical.
moparisthebest
but it's not historical, all the clients do this
Link Mauve
It still didn’t get through any standardisation process, and is a historical artifact.
lovetox
this all is nonesense for me sorry
Zash
moparisthebest: lots of clients do lots of "historical" things still
Link Mauve
That’s enough for it to be historical.
lovetox
you cannot dictate what to display inline in other clients
Link Mauve
See OTR, see vCard-temp.
larma
> An Historical XEP documents a protocol that was developed before the XSF's standards process was instituted
lovetox
there can never be a standard that forces me as a client to display something inline
lovetox
i see no purpose for this at all
moparisthebest
all clients do this and there isn't even a proposed replacement yet? still historical?
Zash
larma: Maybe we should s/before/outside/ then?
chronosx88has joined
lovetox
you send me a SIMS message, guess what if i feel like it having a option to not display it inline, then thats it
larma
> An Informational XEP typically defines best practices for implementation or deployment of an existing protocol
moparisthebest
ah ok I guess maybe it fits that larma
lovetox
even if the XEP is called Inline media
lovetox
its the responsibility of the client to decide what to display inline and what not
pep.
larma, not that body==oob url is "best practices"
pep.
it's just what's out there :)
chronosx88has left
lovetox
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?
larma
yeah but it says "typically defines best practices" so "bad practices" are also fine 😉
chronosx88has joined
larma
Also XEP-0201 😉
lovetox
also body==url, never meant "display this inline"
lovetox
it meant, this is a filetransfer of a file uploaded with http upload
lovetox
knowing that a client can act on it
larma
lovetox, agree
lovetox
but nobody ever said, you have to display this now inline
larma
but again, this is not written down anywhere
lovetox
why invest the time into changing old XEPs, if we could work on finishing SIMS and migrate
pep.
lovetox, if you can do that, great
pep.
Please change all clients :)
larma
I don't think there is consensus on what the correct SIMS is.
lovetox
no the author should react to the countless standard mails
lovetox
yeah then discuss whats correct
lovetox
no future client should be forced to implement oob
larma
lovetox, "no future client should be forced to implement oob" unrealistic, also it is just about to be part of the CS2020
lovetox
ok if i hear compliance suite im out :D
eevvoorhas joined
j.rhas left
j.rhas joined
lovetox
no sorry go on, im grumpy had a long day, document away :)
lovetox
but please stay away from dictating UI behavior on the receiving side
Nekithas left
jabberjockehas joined
larma
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"
Ge0rG
Because users don't need consistency between different implementations, or between sender and recipient of a message.
larma
Ge0rG, we can still suggest UI outside XEPs
larma
but client consistency outside of protocol does not belong in XEPs IMO
lovetox
and client serv different communitys with different needs
larma
*thumbs up reaction*
Ge0rG
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
moparisthebest
how are they different at all actually?
lovetox
a client may want to react differently
waqashas left
waqashas joined
Ge0rG
moparisthebest: the former could be anything, not just an image
lovetox
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
lovetox
while your contact just pasting links he found somewhere
lovetox
is maybe not something i want to immediatly download
moparisthebest
I'm still not seeing the difference
lovetox
not downloading vs downloading
larma
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...
moparisthebest
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?
lovetox
moparisthebest, its not about what you want
lovetox
you can not want anything for another client
moparisthebest
it is in the sense that not even *my* client can guess what I want
waqashas left
larma
If your client displays external resources inline under certain criteria, that's something completely different
waqashas joined
moparisthebest
so certainly the remote client cannot guess
lovetox
he does not need to guess, if you tell him
lovetox
hence the protocol we are discussing
larma
It's a known attack against clients that show "previews" to fake the preview to lure users into opening shady websites
lovetox
and the difference
moparisthebest
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
lovetox
im not sure what you are trying to say
larma
moparisthebest, it's not about what is possible, but about what makes sense
lovetox
clients react to that differently already
lovetox
and it works just fine
chronosx88has left
chronosx88has joined
waqashas left
waqashas joined
Zash
> 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.
chronosx88has left
Zash
the http upload part, that shouldn't matter
lovetox
but it does
lovetox
it means a user selected a file on his harddrive, and wants to transfer it to you
lovetox
only because thats done via http, does not mean every url i paste into a chat is now a filetransfer
chronosx88has joined
moparisthebest
that's a pretty dumb restriction anyway, I ran into this the other day actually
Zash
wat
lovetox
simple use case, i want to show a gallery of received media from a contact
moparisthebest
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?
waqashas left
waqashas joined
moparisthebest
it sucks the second way changes how it's displayed on wife's end :)
Link Mauve
A simple solution for that would be for your client to have a cache of recently uploaded files.
Link Mauve
No need to change the UI, just it wouldn’t transfer it again and instead reuse the URL it already got.
lovetox
yeah clients could be just smart about that
moparisthebest
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 :)
waqashas left
waqashas joined
lovetox
but it is, you got it backwards
lovetox
as we said, the sending client just tells this is a file from my harddrive
lovetox
the receiving client decides what it does with that information
zachhas left
zachhas joined
moparisthebest
"whether this came from my hardrive or not" is a really dumb distinction though
waqashas left
waqashas joined
Zash
this
moparisthebest
I don't understand why it would matter in any concievable way
Zash
it makes no sense to me
lovetox
because its more trustable
moparisthebest
why???
moparisthebest
why is a http upload link on my server I uploaded 2 seconds ago less trustable than one I'm uploading now
moparisthebest
or, really anything else
Zash
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.
moparisthebest
you can make a client take any pasted http link, and pretend it's an http upload when sending it right?
moparisthebest
like presumably a gajim plugin could do that?
waqashas left
moparisthebest
so how can the recieving client place any trust in that
waqashas joined
Zash
`/embed arbitrary-url-here` in poezio for example, I've done that a bunch of times
lovetox
because you can share a link by accident or unkowing that it causes harm
lovetox
if you select a picture from your harddrive, it will most likely not
lovetox
and as i said above, media gallery of filetransfers
waqashas left
waqashas joined
lovetox
but yeah i know other messengers record every link as media that was sent
larma
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
lovetox
thats why everybody with whatsapp ends up with X memes in his gallery shared by some people in groupchats
moparisthebest
uh sorry but I see people accidentally upload pictures in mucs all the time?
moparisthebest
probably more often than paste links even
moparisthebest
in fact it's pretty easy to open a picture in the android gallery, click share, then mis-click the conversation muc
lovetox
moparisthebest, i think you misunderstood
lovetox
its not about accidently sharing a file
lovetox
a file will never harm your contact
moparisthebest
that doesn't sound like a given
lovetox
a link could that you share further could
moparisthebest
they... are the same though...
lovetox
technially yes nobody argues anything else :)
waqashas left
waqashas joined
moparisthebest
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?
lovetox
but one is a link someone wants you to see, and the other is a file he wanted you to have
lovetox
moparisthebest, its not about security, its about the intentions
jonas’
I tend to agree with lovetox to some extent
moparisthebest
it's about nothing because there is no difference at all
lovetox
if it was about security i could not rust anything that does not come from my server
jonas’
weird things happen for example with Conversations when you OOB-tag arbitrary links
lovetox
i agree its a very subtle difference
jonas’
I have code in JabberCat which simply OOB-tags all URL-only posts
lovetox
and i agree most clients will probably not make it
jonas’
which means that C will render them as file downloads
lovetox
but its still worth to have that hint
jonas’
instead of as links
lovetox
and if its just to sort, link meme shares into another category on harddrive
moparisthebest
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
lovetox
then actuall private files someone uploaded
lovetox
moparisthebest, no nobody says its ok to display inline
lovetox
thats a determination a client can make, but nobody suggest to do it
waqashas left
waqashas joined
moparisthebest
except all clients that have it implemented that way of course
lovetox
as i said simple usecase, i dont want your meme shares from 9gag in my file gallery
larma
write up on things I'd change in SIMS (including the name): https://gist.github.com/mar-v-in/f154b97ddc9869c1132b12bcd9a14f38
moparisthebest
I like how SIMS just assumes e2e doesn't exist lol
moparisthebest
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?
waqashas left
waqashas joined
larma
moparisthebest, does it? I'd say it assumes we have full stanza encryption 😉
moparisthebest
that falls under "un-useable in the real world" I guess :)
moparisthebest
since there aren't any full stanza encryption methods implemented anywhere?
lovetox
yes they are
lovetox
openpgp
Zash
Can't you do E2E encrypted file transfers with Jingle? SIMS can use that.
lovetox
also dont know what that has to do with E2E at all
waqashas left
moparisthebest
OX? there is a XEP, iirc it's not actually implemented anywhere
waqashas joined
larma
moparisthebest, it is
lovetox
it is, Gajim has a plugin :D
moparisthebest
hashes/size/name/type all that private stuff that should probably be encrypted
lovetox
and also its not hard to implement
lovetox
developers just have other stuff to do right now
larma
also smack supports it
lovetox
moparisthebest, what is private about that? these are all things i can get from a oob url if i download the file
lovetox
so oob url is ok
lovetox
but SIMS is not?
moparisthebest
not one of these URLs: https://xmpp.org/extensions/inbox/omemo-media-sharing.html
lovetox
SIMS is just, i tell you the metadata before you have to download the file
lovetox
moparisthebest, we talk about media sharing XEPs, and if i want to share a picutre here in this MUC
lovetox
E2E is out of the question
larma
If you encrypt the file before uploading you should probably also encrypt SIMS
waqashas left
waqashas joined
lovetox
so why should i not be nice and sent metadata with so clients dont have to download to get them
larma
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
lovetox
of course this xep is only to be used with full stanza encryption if your conversation is encrypted
lovetox
that goes without saying
lovetox
but a media sharing XEP must not care if currently full stanza encryption in use or not
larma
lovetox, people for some reason always assume that encryption is a body-only thing and thus complain about SIMS leaking things
waqashas left
waqashas joined
moparisthebest
yes, ie the only encryption that has ever been actually deployed :)
pep.
moparisthebest, in the meantime, if you don't think about it, it's probably never going to become viable
waqashas left
waqashas joined
moparisthebest
I'm also not sure the point of letting clients lie about stuff
moparisthebest
if you duplicate where info is, then you have to have rules about when it doesn't match
waqashas left
waqashas joined
larma
"duplicate where info is" what are you referring to?
waqashas left
waqashas joined
pdurbinhas joined
moparisthebest
if you send me a link to the file, I have it's size, content type, hash etc, after I get it
moparisthebest
what's the point of also sending all that? what if what you send me doesn't match with what I get?
waqashas left
waqashas joined
Alexhas left
waqashas left
waqashas joined
Wojtekhas left
pdurbinhas left
larma
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
zachhas left
zachhas joined
Wojtekhas joined
waqashas left
larma
content type is not part of the file, so it's good you actually get it, size is useful to know before downloading it
waqashas joined
moparisthebest
size would be useful to know before downloading, if you could trust it
moparisthebest
but you can't
waqashas left
waqashas joined
flow
I'd argue that it is still useful
larma
You can, just stop downloading after you reached this amount of bytes, if the link provides you with more data, then it's corrupt
flow
or malicious
larma
which is the same for the user (file transfer failed)
waqashas left
waqashas joined
adiaholichas left
chronosx88has left
adiaholichas joined
!XSF_Martinhas left
!XSF_Martinhas joined
j.rhas left
j.rhas joined
Dele (Mobile)has left
mukt2has joined
larma
Anyone interested in DKIM for XMPP?
zachhas left
zachhas joined
ralphmhas left
ralphmhas joined
Tobiashas left
Zash
The what, why?
Shell
oh dear
Wojtekhas left
pep.
larma, what would you need that
Zash
MUC? .. because DKIM works so well for mailing lists
Zash
But, uh, please don't
pep.
To prove that a message is indeed coming from the server it's saying it's coming from?
eevvoorhas left
pep.
I'd rather do e2ee and verify that identity
Zash
s2s has pretty good security already, with mutual TLS certificate authentication.
pep.
Zash, the idea being that MUC can impersonate anybody, I guess..
Zash
I see no need for DKIM, except possibly in some relay case like MUC, but meh.
mukt2has left
pep.
And you need to trust MUC same as you trust your server. (Note that I'm not especially arguing in favor of DKIM)
j.rhas left
Zash
I'm quite happy leaving crypto stuff to the TLS library, thankyouverymuch.
pep.
:)
j.rhas joined
jubalhhas joined
Zash
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.
jubalhhas left
Zash
I imagine it'd be easier to apply to XMPP tho.
larma
Well, a proper client should ignore the origin information in messages in a private/non-anonymous MUC on an untrusted server right now.
larma
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)
moparisthebest
Dkim works on well configured mailing lists just fine, you are thinking of SPF that they break
Zash
Mailing lists don't break SPf
pep.
moparisthebest, mailing lists break dkim
larma
pep., they don't need to
pep.
They don't need to indeed
pep.
Most do
moparisthebest
Misconfigured ones that mangle the message only
larma
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)
Zash
b) also breaks PGP signatures \o/
Zash
Nice things. Email. Pick one.
zachhas left
zachhas joined
Zash
Email and DANE seems to do okay tho.
larma
Zash, actually it doesn't (or doesn't need to) as you can concat with MIME