jdev - 2020-11-24

hi there - what's the latest/greatest work on file sending with metadata? https://xmpp.org/extensions/xep-0385.html ?

(interop is not of concern ATM)

sonny, the File Metadata ProtoXEPs currently in the pipeline

wait until tomorrow for them to get numbers

(though there is a chance > 0 that one of them is vetoed)

see https://xmpp.org/extensions/inbox/file-metadata.html for a preview

damn, I need to do something about them.

Ge0rG, yes you do

please don’t let those expire, either

A/B XEPs yeeeeeee

sonny, s/tomorrow/today/, we’re on tuesday alreay

thanks - I don't understand the premise of that XEP - it removes a dependency to add a new one (and fragmention) while still relying on said removed dependency for thumbnails

I'll go with 0385 for now and see if I can contribute my thoughts to the list

sonny, huh?

it does not depend on jingle for thumbnails

and '385 does more than just file sending, it also does markup

> A thumbnail element of the file, using the <thumbnail/> element defined in File Transfer Thumbnails (XEP-0264)

https://xmpp.org/extensions/xep-0264.html

I do not see '264 depending on jingle.

my point is that it shows that depending on an external XEP isn't an issue - so I don't understand the premise of the XEP

oh, it was about which specific XEPs to depend on

if the issue is that Jingle is too big why not taking what's there and splitting

without breaking changes / fragmentation

it’s not possible to do it without breaking changes as it’s in jingle’s namespace

the entire point is to remove it from jingle’s namespace

to avoid tying it in with jingfle

ok I think the problem is that I don't understand how using a subset of the Jingle namespace may be problematic ?

when jingle gets updated, an entire mess starts

the jingle namespace changes

soo ... what now? do we leave the namespace of <file/> on the old "version", creating confusion? do we bump it, rendering the element invisible to everyone and causing massive breakage? do we bump it in jingle itself, but not for the use in '385?

splitting would prevent those issues from arising - XEPs have been split before

no

it is still in jingles namespace

which would then be the confusion part

or we move it into a different namespace -> exactly what file-metadata.html does

I am not sure how splitting would help here. the problem with the namespace would still exists. I guess the lesson here is that namespace should be minimally scoped

that

file-metadata isn't a 1:1 with jingle so no

whatever "namespaces should be minimally scoped" means in practice, there is probably a to fine-grained variant too

ok so the problem is sharing namespace between xeps?

sonny, that is part of the problem

flow, most certainly there is

otoh I can hardly blame people that the <file/> element was designed under the jingle namespace: back then, it was probably not foreseable that other means of file transport would emerge ✏

how would you send File metadata element in a chat message? using reference type=data as well?

sonny, https://xmpp.org/extensions/inbox/sfs.html

thank you

with encryption: https://xmpp.org/extensions/inbox/esfs.html

sonny, file-metadata has been assigned XEP-0446 FYI