XSF Discussion - 2019-12-21

If the Server / Client doesn't support XEP-0313 and not XEP-0280. What will happen when Account 1 send a message to Account 2 while Account 2 is offline?

"It depends"

0280 is not actually for offline support

look at 0198

Offline message storage, delivered when they come back online.

Some implementations will return an error saying the recipient is not available also

Unless offline storage has been disabled,

Where is the offline storage defined RFC / XEP?

0013 ?

No

https://xmpp.org/extensions/xep-0160.xml

Altho it's actually not a protocol, it's just a server implementation detail

Ok,.. thanks.

jonas’, your last email regarding char counting

holy smokes that thread blew up

maybe i dont get it, but i dont think it says what you want to say

why?

(I also only sent one mail, or is my MUA confused?)

I think marvin, ralph and all other want to count *before* escaping, for the reasons detailed in this thread

depends on the direction you’re looking at

on the receiving side it’s after (un-)escaping

I totally agree with ralph and marivn

I can’t find my own mail tho

ah, there it is

yeah if you mean that its ok i guess, just saying i dont think many people will read this from your email

okay, I’ll send a follow-up to clarify

that (un-) is essential

thanks for pointing it out

I sent a clarification which should make more sense

looks good !

what are you all thinking about a XEP that lets you manage your uploaded files

getting the list of files currently uploaded, and maybe their expiration date

and having a option to delete them

Link Mauve had plans(tm) to integrate something like that into his account management client thingy, if/when that becomes a thing

iirc

And yeah that'd be great.

I already have it in there I think.

There were mentions of that during the GDPR paranoia period but nobody did anything about did

Only listing and deletion so far.

Link Mauve, what standard?

XEP-0050.

lovetox, maybe if you look on standards@

Link Mauve, what standard on top of 0050?

:x

Not written yet.

adhoc is fine for that

actually there is no need for a standard or? adhoc just returns dataforms

if you can process one adhoc workflow you can process all

though it probably would be good to have a well known command name for that functionality

so we dont have to discover it

yes

on the other hand this could be added to the httpupload disco result

the adhoc command name i mean

but probably easier to just define one name

Yup, just like XEP-0133.

Maybe we could just extend XEP-0133 with that.

also another thing i thought aboujt

some way to discover if a file is already on the server

maybe with sending a hash

and you get back the uri and the expiration date

What about encrypted files

depends on the encryption

if the encryption is always the same you could still check the hash

but thats not so likely

but yeah that would not work for encrypted files, but thats no reason to not do it for unencrypted

If a hash is part of the upload slot request then the server could do integrity verification after the upload is completed, which seems like a nice thing.

hm yeah but is this really a problem worth solving

hm with http does the server know the difference between end of file

Almost every file upload thing I made before HTTP upload was a thing would base the URL on the hash of the content. Would have been nice to use those, but couldn't because the current scheme.

and cancelled transfer?

It knows the size

ah ..

so yeah, i guess this never happens

a full size transfered file where some bytes are what flipped to something else?

TLS (via HTTPS) also does a bunch for integrity

It'd be nice if the rejected http upload encryption xep that every client currently implements anyway was accepted

moparisthebest, the aesgcm:// thing?

meh

What would it take process wise to reboot that? Yep that's it

Yak number one: Fix the encryption scheme to allow encrypting more than just the body.

on what grounds was it rejected, and how would a proper http upload encryption look if not that way?

actually it has nothing to do with httpupload

https+vnd.something.omemo.aesgcm:// at the very least

its just a way to communicate a key and url to another user

or register aesgcm with iana

It was originally just https:// until someone complained I think

i guess all info could be put into the fragment

url#omemo-key=123123123123123

then it does not matter what the scheme is in front

Non-OMEMO clients would just download garbage

MattJ, non omemo clients can not see that message

MattJ, they wouldn't get the URL in the first place tho

No they wouldn't get the link

Yep

Ah right

because it'd be omemo-encrypted <body>

in

but yeah its all a ugly workaround for not having full stanza encryption

Full stanza encryption would be great but that's a separate concern, you'd still need to encrypt the http upload

but even if its ugly, it just works and is easy to implement

so not really a top priority to fix in my opinion

moparisthebest, but you dont need a XEP to encrypt a httpupload

you just need a XEP to communicate to another party, how you encrypted content

Doesn't Jingle have stuff for this?

yes, but we talk about http upload

ahh

Why does it need to matter what transport method you used?

it doesnt

you are right

jingle does it, it sends a key transport omemo message

which is an encrypted message that has a key in it

this is not an encrypted body

its something in the signal protocol layer

then it starts jingle, and you know that keytransport message is the decryption key

or something like that

but you can do this with jingle because you are in some kind of session, and you know where this key transport message belongs to

hard to do with just sending a url

hm its doable ..

you could put 2 encrypted omemo elements into one message

one encrypts the body like always

and the other is inside some <security> element

and is the decryption key transport message

then you just have to write a xep that tells you to look for it and to decrpyt it in the right order