Is is possible to share multiple files in a single <message> with XEP-0447 (Stateless file sharing)? Apparently it's not.
mjkhas left
mjkhas joined
775857429has left
millesimushas left
oshnhas joined
Kev
It's possible with SIMS, at least, because Swift does that.
millesimushas joined
stphas joined
belovehas left
belovehas joined
petrescatraianhas left
belovehas left
belovehas joined
goffi
I see. I've gone the XEP-0447 way as it is supposed to be a reiteration of XEP-0385. However the issue I see is easily fixable, we need to add on `id` attribute on the `<file-sharing>` element, and rewrite §3.3 "Attaching a source" to use it. Then nothing prevent to use multiple `<file-sharing>` elements in he same `<message>` stanza.
davidhas joined
davidhas left
Menelhas left
goffi
We also need to decide once for all which XEP to utilise for file sharing, but that's one of the eternal XMPP problems.
Chadhas joined
MattJ
🙂
Menelhas joined
MattJ
Does anyone feel they have sufficient context to write a summary of the current options (pros, cons, implementation status) to standards@?
MattJ
(I don't)
goffi
I'm currently writing something for the multiple files issues, that can be a starting point.
MattJ
Thanks
Kev
To this day I don't understand why 447 came about when it basically duplicates SIMS.
nicoco
I don't either, and in fact they so much look alike that I just support both with little effort. I think the main issue is philosophical: "namespace reuse bad vs namespace reuse good"
Kev
I know someone once said "Because SIMS has 'media' in the name and I don't want to share media", but I think that's both an insufficient reason and a difference in understanding of the term media.
MattJ
Action items: Rename SIMS, give it a casual mention in the 2023 compliance suite, done
Kev
That would work for me.
con3has joined
Andrzejhas joined
Andrzejhas left
goffi
XEP-0385 depends on reference, and while it may be nice to have a reference, it should be optional (it should be possible to have files available just as attachments). Also file-metadata has been split instead of realying on jingle stuff. It has source attachment, which is a neat feature, and XEP-0447 is not tied to message, which make it usable with pubsub. But all that could have been fixed directly on XEP-0385.
kurisuhas left
goffi
However, now that we have both, I personnaly thing that XEP-0447 should be used as basis, XEP-0385 deprecated (with authors probably transfered to XEP-0447), and maybe add references as an optional feature.
goffi
think*
Wojtekhas joined
goldbeardphas joined
kurisuhas joined
antranigvhas joined
papatutuwawahas joined
praveenhas left
stphas left
MSavoritias (fae,ve)
yeah the newer one has some nice improvements
Steve Killehas left
goffi
I've sent a message to standard@, and I can propose a PR in coming days, but I'll need backup from XEP authors.
adiaholichas left
adiaholichas joined
Steve Killehas joined
Steve Killehas left
pep.
Kev, also 372?
pep.
Re why not SIMS
pep.
I think that's one of the reasons?
goffi
yes I've mentioned it in the email. It's really weird because it's in example, but not explained at all in the text.
goffi
XEP-0372 is not even quoted.
pep.
https://xmpp.org/extensions/xep-0447.html well actually there's a whole list of "Why not SIMS" in the spec
Kev
Right, one of which (not allowing body) seems to be show-stopping, "has media in the title" seems like a bad reason, and not using references is to its detriment rather than benefit.
Tobi
pep. , yup..some weird list. 1. "No focus on media, generic for every file type." <--- probably different understanding of the term "media", 2. Using File metadata element (XEP-0446) [2]. <--- File metadata element didn't exist yet back then. If you look it's from the same author. 3. "Using XML for structured data instead of URIs when possible, adding further extensibility" <-- I think URIs can provide great extensibility as well. I'm sure there are URI schemes for encrypted keys and what not.
pep.
Ah I'm getting the whole isode crew on my back :P
Tobi
I'm not against File metadata element, but it's a weird reason for duplicating a XEP. I mean SIMS was experimental and can be changed easily.
goffi
Kev: in XEP-0447 body is explicitely allowed as fallback (it's just said that it should not have additional info, which seems sensible)
Tobi
pep. , heh :) but I agree..references is a bit out of place in SIMS. It was not meant to depend on it, more as an example of how the SIMS element can be used with other XEPs in mind.
pep.
I guess as the spec is actually being used in places, maybe starting to remove these TODOs would be nice
goldbeardphas left
Kev
> : in XEP-0447 body is explicitely allowed as fallback (it's just said that it should not have additional info, which seems sensible)
But that doesn't seem sensible at all, it seems terrible. I can't immediately think of any other platform that requires sending files independent of messages. In all the ones I use, you attach (multiple) file(s) to a message that has all the normal properties.
pep.
Isn't that "just" a UI thing?
wurstsalat
larma: ping ^
Wojtekhas left
Steve Killehas joined
goffi
I don't get what prevents the message to have normal properties. The way I understand it, is don't use metadata in the body which are not present in the <file-sharing> element. Also I want and plan to transmit files outside of message, notably with pubsub.
Kev
> Isn't that "just" a UI thing?
I don't see how, unless you then use extra XEPs to tie together these messages into one conceptual message.
marc0shas left
marc0shas joined
Kev
(With all the MAM etc. problems that brings)
pep.
I often find it weird that people feel like they need to refer to everything everywhere, but that's me. It's not like there was often 43 different topics going on at the same time
pep.
Message1: "hey the pictures I told you about", Message2: <pictures>
pep.
Not saying it shouldn't be done of course, or that I'm gonna try to prevent it from happening (referencing stuff everywhere)
Steve Killehas left
gooyahas left
gooyahas joined
belovehas left
Steve Killehas joined
goffi
now that I'm thinking about it, XEP-0447 is already used with pubsub in XEP-0471
belovehas joined
Yagizahas joined
Steve Killehas left
Martinhas left
Martinhas joined
Martinhas left
Martinhas joined
goldbeardphas joined
Steve Killehas joined
Wojtekhas joined
con3has left
marc0shas left
marc0shas joined
Wojtekhas left
goldbeardphas left
oshnhas left
oshnhas joined
florettahas joined
adiaholichas left
adiaholichas joined
Maranda[x]has left
Maranda[x]has joined
marc0shas left
marc0shas joined
goldbeardphas joined
Link Mauve
pep., you lose the semantics, unless you parse the message.
Link Mauve
While having a message introducing the pictures, as well as a description for each picture, ties it all together.
xnamedhas left
Link Mauve
This is important for accessibility too.
Link Mauve
The current Conversations way of sharing media is completely inaccessible.
pep.
@alt is possible with 447
Link Mauve
I was talking about abusing XEP-0066 for saying “this URL is actually an embed”.
pep.
Yeah I wasn't, I was still taking about 447. I agree accessibility is important
xnamedhas joined
tbm16has joined
intosihas left
intosihas joined
Andrzejhas joined
TheCoffeMakerhas joined
tbm16has left
Menelhas left
Menelhas joined
Hugohas joined
Wojtekhas joined
belovehas left
Calvinhas joined
carloshas left
carloshas joined
Calvinhas left
belovehas joined
larma
The motivation of 447 is to get things going. One of the reasons why 385 was never really adopted even though everyone agrees it would be nice to have, is it's lack of backwards compatibility. 447 file transfers are fully compatible with legacy oob based http file transfers. This requires that the body remains unused (because the body is needed for backwards compatibility)
marc0shas left
marc0shas joined
Hugohas left
Hugohas joined
larma
Mixed content (as proposed with SIMS) is somewhat contradicting 0226. I do know that some messengers (hardly all, but Slack does and apparently that became the baseline for many) allow sending messages that have both a text body and files in the same message. That's not a primary objective for 0447.
belovehas left
Link Mauve
larma, the main reason 0385 never got adopted was that it didn’t play well with body-only e2ee IIRC.
goldbeardphas left
TheCoffeMakerhas left
larma
We don't encrypt in public MUCs so it could've been used there at least
Tim Rhas left
Tim Rhas joined
belovehas joined
Tim Rhas left
TheCoffeMakerhas joined
florettahas left
Andrzejhas left
Kev
You're right, this might not be as widespread as I thought, but it's still a thing I very much want to support. A quick test of what's immediately available to me seems to suggest:
Same Message: Apple Messages, Google, Slack, Discord, Guilded
Not: Whatsapp, Facebook Messenger
xnamedhas left
Kev
I almost exclusively use the first set, so hadn't realised the last two didn't.
nicoco
I'm trying to understand something: because of <sources>, we can't have several <file>s in a <file-sharing>. what prevents us from having several <file-sharing>s?
belovehas left
xnamedhas joined
Daniel
Ignoring what other messengers are doing. Sending images and text in the same message is a very frequently requested feature
larma
Kev: Feel invited to figure out how to do backwards compatibility with SIMS, because I didn't (except having two bodies)
adiaholichas left
Daniel
Note the *s* in images
Chadhas left
nicoco
Daniel: and a single text for all images, or a description per messagE?✎
nicoco
Daniel: and a single text for all images, or a description per message? ✏
nicoco
Daniel: and a single text for all images, or a description per image? ✏
larma
nicoco: That's indeed on my to do list (assigning an id to each file-sharing if there are multiple)
Daniel
> Daniel: and a single text for all images, or a description per image?
Not sure tbh. But I think one common description would probably be fine?
neoxhas left
adiaholichas joined
MattJ
I think common description + optional alt/caption per image is probably what we ought to aim for
nicoco
I think this is what I've seen in walled gardens, but for accessibility, alt text per image is actually better, isn't it?
Daniel
(~ alt text with is orthogonal in my mind)
Hugohas left
neoxhas joined
nicoco
ok
Kev
> : Feel invited to figure out how to do backwards compatibility with SIMS, because I didn't (except having two bodies)
I thought we'd sorted that in Swift, maybe Tobi can remember what our rule was? I think it was to trim the start of the message if it matches the file URL, and to prepend the URL.
jonas’
if alt text is covered separately, I'd say that one overarching text alognside the images should do
belovehas joined
nicoco
> assigning an id to each file-sharing if there are multiple
larma: but isn't it already possible to have several <file-sharing> elements, each with their own <sources>?
florettahas joined
MattJ
> I thought we'd sorted that in Swift [...]
I think if it comes down to matching like this (which probably it will), we should specify the recommended fallback format in the XEP too
larma
nicoco: yes, but then attaching sources won't work
TheCoffeMakerhas left
775857429has joined
TheCoffeMakerhas joined
nicoco
oh right, in 3.3 <sources> is not a child of <file-sharing>. I get it, thanks.
Calvinhas joined
larma
An alternative would be to have some <message-group id=x /> which can be added to multiple messages to have the recipient client group them. So if you send five files with text, you send 6 messages and group them. Legacy clients would still display 5 files and a message without any weirdness.
Calvinhas left
larma
Because fallbacks won't work for multiple files either✎
larma
Because fallbacks won't work properly for multiple files either ✏
Kev
Why not?
larma
When I talk about fallback I mean fallback to how we do files today.
larma
Not fallback to "here is a bunch of URLs"
goldbeardphas joined
marc0shas left
marc0shas joined
larma
Alternatively the fallback for multiple files can be that legacy users get a zip file, but that's pretty bad UX for legacy users if we send images.
catchyhas joined
larma
Having legacy users display 3 images and a body ungrouped is the best fallback we can possibly have, so we should try to reach that somehow.
pep.
Yeah no an (compressed) archive seems terrible
Calvinhas joined
larma
pep.: would be fine for 3 non image files IMO
goffi
Wait, I'm reading back the logs, I think that there is a misunderstanding, maybe on my side. When I read "No mixed content, body is used for fallback only and not to transmit additional information.", I read no additional information ABOUT THE FILE (i.e. don't put encryption key or something like that in the body), but I don't read it as it's impossible to put a message in the body at the same time as the file. Example 2 is doing exactly that. I've missed something or what?
pep.
larma, I guess if one doesn't have to display thumbnails.. but say I only want to download one of them.. it's weird
goffi
otherwise, I agress that we need to have text in the body at the same time as images, and I've understood XEP-0477 like that.
belovehas left
larma
goffi: example 2 has the file's desc in the body, no text beyond that.✎
larma
goffi: example 2 has the file's desc in the body, no additional information beyond that. ✏
larma
pep.: with uncompressed archives you could just download the header (or footer) and the do a ranged http request. Anyway, not saying it's my favourite solution either.
pep.
Ok
goffi
Damn, I've already read it like information about the file, that why I wasn't understanding kev point, in which case I agree that it's a show stopper (and I haven't implemented it like that).
I know some clients use it to do mentions, is there anybody not going to use that for mentions?
pep.
Also do we need to define a URI for occupant-id maybe?
larma
Last resort (if people don't like the grouping) could be messages sent exclusively as a fallback (you send one message with text body and file-sharings and then follow-up messages that have the files in legacy mode plus a tag to ignore them if you supported the file-sharing element of the first message)✎
larma
Last resort (if people don't like the grouping) could be messages sent exclusively as a fallback (you send one message with text body and <file-sharing>s and then follow-up messages that have the files in legacy mode plus a tag to ignore them if you supported the <file-sharing> element of the first message) ✏
L29Ahhas left
larma
pep.: my proposal would be to add mention to 0394
pep.
And are they any other uses for 372? Is someone someday going to use my mention-in-a-chatroom as something completly different?
singpolyma
Good morning. My reasons to prefer SIMS:
* Mixed text+files is a must for us
* Reuses existing namespaces instead of the NiH file element
* Can do both attachments and inline media, both of which we need
Kev
If that's what has to happen (If I understand correctly, you're sending multiple <message><body>URL</body><ignore-if-you-do-sims/></message>), then that seems better (although horrid) than not being able to use the message body.
L29Ahhas joined
pep.
larma, you mean that thing that's never gonna replace xhtml-im? :x
pep.: No, I mean text and images intermixed. Probably with xhtml-im but can also use the references for that
jonas’
XHTML-IM 2: This time, we don't pretend that web issues can be solved in protocol.
pep.
So.. what about mentions..
larma
Kev: so I read you don't like the grouping thing?
goffi
I don't get why the XEP-0447 should have a restricted body. If we want to support multiple files, we can't support legacy anyway.
Kev
> : so I read you don't like the grouping thing?
Maybe I don't understand it, I'm a bit distracted at the moment.
larma
goffi: multiple files is missing exactly because it wasn't clear what's the best way to do it backwards compatible ;)
larma
> An alternative would be to have some <message-group id=x /> which can be added to multiple messages to have the recipient client group them. So if you send five files with text, you send 6 messages and group them. Legacy clients would still display 5 files and a message without any weirdness.
Kev
Calvinhas left
jonas’
and then your MAM page cuts in the middle and half of it is missing in your dipslay✎
jonas’
and then your MAM page cuts in the middle and half of it is missing in your display ✏
pep.
I think that's a problem for many things, not especially with this spec
larma
jonas’: and then you fetch the next page and it repairs
775857429has left
larma
Or you use that new version of MAM that we discussed at summit
Kev
larma I guess don't understand why splitting one logical message across six message stanzas which clients and MAM archives then need to merge is a positive thing.
larma
Kev: because that's what we effectively do today
Kev
But I also don't really understand why fallback of 'prepend URLS to body' doesn't work.
Kev
> : because that's what we effectively do today
I think that might depend on which 'we' you mean :)
jonas’
and as I read on mastodon today: "tradition is just peer pressure exerted by dead people"
larma
Kev: because legacy clients would then be shown a list of random URLs?
jonas’
just like today?
jonas’
it's ok, as long as the URLs are there
Kev
Together with the rest of the message body, yes. I'm not sure how that's different to legacy clients receiving six messages, one of which is a body and the others are 'random URLs'.
larma
Consider that *all* your clients would be legacy clients under this definition
Zash
Subtle encouragement for implementing non-legacy things is fine
jonas’
larma, yes, for a while
jonas’
and then they're fixed and we're good
MattJ
and for the case of n==1, it works as good as today, right?
larma
jonas’: except that some platforms will never see the update
pep.
Eventual inconsistencies
jonas’
larma, :sadface:
jonas’
can't have nice things everywhere
jonas’
I am a debian user, fwiw ;)
Zash
Evolution gonna evolution I guess?
jonas’
I also don't see the issue with a list of URLs followed by a text. in e.g. conversations it'll look exactly the same as it does now (if you don't send OOB)
MattJ
Yeah, old clients gradually getting a worse experience is not a reason to hold back the protocol
MattJ
(or to make it overly complex)
pep.
That's the thing. Backwards compat ok but at which cost
singpolyma
Inbound multiple images I store already, will be displaying them later this year I expect
singpolyma
(oob and sims)
goffi
if SIMS handle multiple files, why is that acceptable there, and not for XEP-0447?
Zash
Backwards compat in the form of some graceful decay seems okay to me.
Kev
> That's the thing. Backwards compat ok but at which cost
I note that what I'm suggesting *does* have baseline backwards compat, at pretty low cost.
larma
I don't think sending multiple messages is overly complex or high cost
singpolyma
It's super annoying on several levels for the receiver though
pep.
goffi, I guess it could, but larma seems to not want to do this?
pep.
And.. what about mentions?!
Zash
Decaying into multiple messages does have precedent in IRC gateways... Tho I see no huge problem with decaying into <body>{url}+</body>
singpolyma
What about mentions? That seems unrelated?
larma
If everyone is on a mission now to break compatibility, I wonder why SIMS wasn't popular except for some closed corporate environments
singpolyma
Media wasn't popular back then either
lskdjfhas joined
larma
singpolyma: seriously?
singpolyma
Even when Conversations launched it was just jingle FT push right? Before http upload existed
marc0shas left
marc0shas joined
pep.
Zash, this can be handled by the IRC gateway, breaking into separate messages
singpolyma, the advantages of SIMS are not enough to warrant the change
jonas’
if we get media messages (with more than one file) with alt text each, plus accompanying text, that's a different beast
jonas’
also, I meant to ping larma
Fishbowlerhas left
Fishbowlerhas joined
marc0shas left
marc0shas joined
larma
jonas’: 90% of cases, people are still going to send a single file without text
jonas’
great
Kev
> if we get media messages (with more than one file) with alt text each, plus accompanying text, that's a different beast
But...that's what SIMS gives you?
goffi
+ metadata which are necessary for accessibility.
pep.
larma, have you looked at Mastodon? :x
jonas’
larma, add an oob tag, and it'll magically work in all exitsing clients then
without the ugly splitting part needed for the case when more than one image is attached ✏
pep.
description + @alt is pretty standard in my TL
larma
Many clients require the URL to be in oob and body
jonas’
what pep. says, too, but mastodon isn't the same use case as XMPP is.
goffi
larma: that's not true, and other messenging, I see people sharing whole albums.
singpolyma
> if we get media messages (with more than one file) with alt text each, plus accompanying text, that's a different beast
Yes, this is why I use sims ↺
larma
But if new clients display the body (aka the URL) their UX will be bad
singpolyma
Plus hashes are a big deal for me and non http options
775857429has joined
larma
So summary: we have 0447 for backwards compatible sending of a single file and SIMS for mixed content, multiple files and so on?✎
larma
So summary: we have 0447 for backwards compatible sending of a single file and SIMS for mixed content, multiple files and so on without proper backwards compatibility? ✏
Kev
Except for SIMS backwards compatibility being fine? If you do something that's supported by the old clients, it's fine, and if you do something new that they didn't support, you expect them to need a fallback.
larma
We do have different ideas of what reasonable backwards compatibility looks like.
goldbeardphas left
goldbeardphas joined
larma
I also don't mind if we get rid of 0447 entirely. I just remember vaguely about all the issues people told me they had with SIMS and then I was told that there is no intent to change those things in SIMS and if I wanted to change then I should create a new XEP and now apparently SIMS was all great.✎
larma
I also don't mind if we get rid of 0447 entirely. I just remember vaguely about all the issues people told me they had with SIMS and then I was told that there is no intent to change those things in SIMS and if I wanted to change then I should create a new XEP and now apparently SIMS was all great and nobody remembers why they didn't use it. ✏
Zash
A/B test all the XEPs?
singpolymahas left
singpolymahas joined
larma
Next Dino release will support 0447, so yes, A/B testing is going to happen anyways
nicoco
> larma: that's not true, and other messenging, I see people sharing whole albums.
absolutely. the non-techies I bring to XMPP IM really miss "sharing a whole (smallish) album in a message", à la whatsapp. I agree that there are better tools to share albums, but this usage of IM has "won" among non-techies. possibly this is only a UI problem though.
adiaholichas left
Chadhas joined
L29Ahhas left
L29Ahhas joined
adiaholichas joined
larma
FWIW, I totally understand all those use cases people have in mind and are looking to support, but it's also sad to see that everyone is just thinking inside their bubble and not caring about compatibility outside of it.✎
singpolyma
Compatibility can only come when we do the work. That's why the transition happens slowly instead of all at once
larma
FWIW, I totally understand all those use cases people have in mind and are looking to support, but it's also sad to see that everyone is just thinking inside their bubble and not caring about good compatibility outside of it. ✏
Zash
Do we have a set scope for what we want?
singpolyma
For our side we're starting by slowly introducing text+image now that we have two clients that support it
larma
singpolyma: which clients?
singpolyma
larma: Cheogram Android and Movim
larma
And what about all the other clients?
singpolyma
those clients see fallback in the cases we use text+image
singpolyma
which is why we are doing it slowly and not in every case it makes sense ye✎
singpolyma
which is why we are doing it slowly and not in every case it makes sense yet ✏
larma
The fallback being text + URL?
singpolyma
yes
larma
So you're planning to severely degrade UX of >90% of active XMPP users
singpolyma
No
pep.
Different use-cases and interop yay
singpolyma
Right now we only do it in cases where it would be degraded for those other users anyway
pep.
Someday people will realize interop is a fantasy
singpolyma
namely, group text, where we have several fallback in play usually
Zash
pep., or, a process?
pep.
eventual interoperability?
L29Ahhas left
Zash
yes!
singpolyma
But it's a trade off between better experience for most of our users vs degraded experience for the few using other clients
singpolyma
and we do walk that line carefully
L29Ahhas joined
Tim Rhas joined
larma
"most of our users" which reconfirms the bubble thing I was talking about
singpolyma
Well, obviously our service will prioritize the experince of people who use it :)
Kev
Are far as I can see, we should be able to do SIMS (or an update to something else) such that it supports multifile, and supports bodies, and that if you continue to do what the reference current clients do (not allowing multifile and not allowing bodies), those will behave as they already do. So if that's the only case that matters for your users, they won't see any different, but those users who do want those features in 'new' clients get them.
pep.
singpolyma, said matrix.org on IRC :P
florettahas left
florettahas joined
singpolyma
pep.: that's sort of the opposite case
singpolyma
Or, maybe it's similar. Since we have to degrade the experince of MMS users due to these limitations in XMPP clients right now
singpolyma
But it's pretty small at this point I think, people don't often ask us why multi file is weird
singpolyma
But yeah, IMO these changes happen slowly and because of ecosystem evolution. Big bang it is too much incompatibility, but doing nothing is stagnation. It's a balance to walk
775857429has left
goffi
I think we were talking about grouping earlier. Would not it be possible to use XEP-0477 with a flag like "the 5 next <message> I send are next files + body message"? We would keep backward compatibility + having multiple files and text message at the same time, at the expanse of a little bit of bandwith.
pep.
Would it not be easier to say "I'm in the same bundle as <the-previous-message-id>"?
singpolyma
That means that to know if you have the whole message you have to wait on a timer?
singpolyma
"maybe I have the whole message now, oh oops here's another piece"
goffi
pep.: I want to know that I will have to show a specific widget for several files at once, so I need to know from the start.
pep.
For what goffi says yes, for what I say, no?
marc0shas left
marc0shas joined
pep.
It's fine, you just update your display?
pep.
That happens all the time with chat bubbles that include or don't include incoming messages because they appear in the same minute, on Conversations for example
singpolyma
pep.: what if my "display" is that I'm sending an MMS message with text+images ?
singpolyma
or an email
pep.
Ah well
singpolyma
or any other gateway protocol that supports text+images :)
goffi
Can be, but it may be weird for the user to have files being added (oh there were 10 files, I only saw 4). Also updating is more difficult in some cases.
pep.
I find it awkward though what goffi says. You may be waiting on messages that will never come
goffi
larma: what do you think about it (grouping to have multiple files + message at the same time)?
antranigvhas left
goffi
pep.: that's implementation to handle, I would put a timeout, and display what I have if nothing happen after X seconds.
marc0shas left
marc0shas joined
marc0shas left
marc0shas joined
singpolyma
vs just using multiple oob and having them all at once
marc0shas left
marc0shas joined
marc0shas left
marc0shas joined
marc0shas left
marc0shas joined
larma
I'm thinking right now about the following:
- Have a single message with the metadata for all files and a body that's displayed, but without the file sources.
- Attach the file sources with follow up messages (one for each file) where the fallback of the follow up messages is a valid http file share in the legacy protocol
This would be fully backwards compatible, allow for body, have all metatdata in the first message (allowing for generation of a nice widget) and even solve the issue of the delay caused by uploading the file we'd see if the HTTP source was directly in the metadata message.
larma
And clients that don't care about backwards compatibility can just put the file sources in the initial message.
goffi
putting source aftewards is a great idea, indeed with the upload delay
goffi
that looks quite good to me.
jgarthas joined
Kev
I don't see why you'd want to be delaying the information and forcing more work on modern clients for the sake of legacy clients. Surely the main priority should be the modern clients.
MattJ
OTOH this approach does have benefits beyond backwards compatibility
Kev
As long as you *can* include the sources in the first message, and don't rely on the rest of them, I can probably live with this. It's a nuisance for MAM servers having to collate all this stuff, but I guess it's not the first bit of nuisance for MAM servers.
larma
Source attaching is already a feature in 447 (and a very sensible one IMO) so the nuisance for MAM is already here ;)
Kev
But, from when we implemented this stuff, we deliberately want to delay sending the body message until the files are uploaded, because sending a message "Here are the files" ... *silence because the upload failed* seemed less helpful than the sender being able to choose not to send the message (or update the files first, e.g. to smaller ones).
larma
Kev: most other messengers announce the file before sending
goffi
If you encode a video or other large stuff, it would be great to send a message and receiving client can show "upload in progress" until it's done.
Zash
Wasn't there a XEP like that now?
Zash
Extension to chat states?
Andrzejhas left
Kev
> : most other messengers announce the file before sending
I thought you were arguing earlier that most other messengers didn't send messages and files at the same time? :)
larma
It's relevant because you want the files to be displayed in the chat at the time they're sent, not the time when they arrive
larma
Kev: they even do for single files without text
goffi
larma: do you have some room to work on something like that in coming weeks? I really like this idea and it would help me to solve my issue with the AP gateway. I can help you if you want.
mentos124has joined
Kev
I can't remember ever seeing on another service "Someone sent a file, but the upload failed, but you've got this message saying you've got a file and if you try to download it you'll get an error". Maybe I'm exceptionally lucky, but I don't think I've seen it.
singpolyma
goffi: maybe we should build it and make sure it works before writing yet another XEP draft ;)
mdosch
> It's relevant because you want the files to be displayed in the chat at the time they're sent, not the time when they arrive
How do they do this? Show a dummy/placeholder before the image/file arrives?
goffi
singpolyma: isn't it about updating XEP-0447?
Zash
Build it, take notes, turn notes to XEP? :)
singpolyma
Zash: indeed
larma
Kev: I've seen an file being removed from the chat because the uplaod failed
goffi
and yeah, that's what experimental is for.
Zash
An interesting thing would be to allow downloading a file at the same time as it's being uploaded, sorta streamed trough the http upload service...
larma
The changes to 0447 are actually rather small:
- change such that the body is displayed
- change the fallback example to use file attaching rather than the body of the metadata message.✎
or like, async promise something something waiting for completion
larma
The changes to 0447 are actually rather small:
- change such that the body is displayed (except if the updated fallback XEP is used to indicate the body is a fallback for 447)
- change the fallback example to use file attaching rather than the body of the metadata message. ✏
MattJ
If we did the multi-upload-slot thing (for upload resumption of large files), we could expose that to the recipient somehow
MattJ
But this is a tangent discussion I think :)
neoxhas left
neoxhas joined
papatutuwawahas left
larma
Kev (or any other editor): mind merging https://github.com/xsf/xeps/pull/1188 soonish so I can properly use it in the updated 0447 and other places? Thanks
nicolahas left
Kev
I don't think Peter's active, so I think I'm the only one. I'm in the middle of time sensitive stuff for a couple of days, I'm really hoping to have an Editor blitz at the end of the week.
Menelhas left
SteveFhas left
nicolahas joined
stphas joined
singpolyma
larma: thanks much for that fallback revision BTW, it has made several new features possible for us already
Guus
If, on an outbound S2S connection, an initiating server obtains a certificate from the receiving server that the initiating server cannot validate under local configuration settings, is there any way it is permissible to continue to use TLS for encryption (but not authentication) of that connection?
Kev
Sure, dialback if it's allowed.
Guus
(assuming that authentication happens through Dialb... that)
Kev
If you allow dialback, unauthenticated TLS is still better than no TLS.
Guus
I'm having trouble reading https://www.rfc-editor.org/rfc/rfc6120#section-5.4.3.1 in a way that this is permissible.
Kev
Well, 6120 removed Dialback, so under just 6120 TLS auth is the only permitted auth.
Menelhas joined
Kev
"""
* Interoperability Note: At the time of writing, most deployed
servers still use the Server Dialback protocol [XEP-0220] to
provide weak identity verification instead of using SASL with PKIX
certificates to provide strong authentication, especially in cases
where SASL negotiation would not result in strong authentication
anyway (e.g., because TLS negotiation was not mandated by the peer
server, or because the PKIX certificate presented by the peer
server during TLS negotiation is self-signed and has not been
previously accepted); for details, see [XEP-0220]. The solutions
specified in this document offer a significantly stronger level of
security (see also Section 13.6).
"""
but it does mention that dialback for exactly this case.✎
"""
* Interoperability Note: At the time of writing, most deployed
servers still use the Server Dialback protocol [XEP-0220] to
provide weak identity verification instead of using SASL with PKIX
certificates to provide strong authentication, especially in cases
where SASL negotiation would not result in strong authentication
anyway (e.g., because TLS negotiation was not mandated by the peer
server, or because the PKIX certificate presented by the peer
server during TLS negotiation is self-signed and has not been
previously accepted); for details, see [XEP-0220]. The solutions
specified in this document offer a significantly stronger level of
security (see also Section 13.6).
"""
but it does mention that dialback allows for exactly this case. ✏
> If the initiating entity presents a certificate
Guus: I don't read this as requiring mutual TLS certificate authentication
Guus
I'm not talking about mutual authentication (or at least, I didn't intend to be)
Guus
The sections are about StartTLS in general (which I assume also apply to direct TLS, but that's another matter)
Zash
Direct TLS is just StartTLS squeezed into the TCP port number ;)
Guus
excellent compression rate.
Zash
I thought security and compression were a scary combo!
Guus
Kev: that interoperability note does mention dialback, but is that ment t be a permissive statement? I could also read this as: "we used to do this differently, but with this spec, you must now use TLS"
Zash
Guus, https://www.rfc-editor.org/rfc/rfc7590.html may also be relevant to your interests
Guus
> In particular for XMPP server-to-server
interactions, it can be reasonable for XMPP server implementations to
accept encrypted but unauthenticated connections when Server Dialback
keys [XEP-0220] are used
Guus
Thanks guys.
belovehas left
goffi
larma: could you add an example for multiple files sharing in your update XEP please?
belovehas joined
Rebeldhas joined
larma
goffi: yes, I will
florettahas left
florettahas joined
goffi
larma: thx.
Zash
> [<starttls/>] stream feature might be stripped out by an attacker [...]
> Therefore, the initiating entity MUST NOT be deterred from attempting
> TLS negotiation even if the receiving entity does not advertise
> support for TLS.
belovehas left
deimoshas joined
belovehas joined
papatutuwawahas joined
mentos124has left
Guus
Zash: I was more thinking around the configuration of TLS, not the availability of it. As an example: do we allow self-signed certs? expired certs? etc.
Zash
Local policy? I.e. configurable
florettahas left
florettahas joined
TheCoffeMakerhas left
TheCoffeMakerhas joined
MattJ
Either you use TLS for authentication, or you don't. If you do, you can't just allow self-signed, expired, etc.
MattJ
If you use something else for authentication (e.g. dialback), those things don't matter at all
Kevhas left
Steve Killehas left
Kevhas joined
MattJ
Prosody just has options to require TLS for authentication, and to require TLS for encryption
MattJ
On top of that we have plugins to e.g. authenticate self-signed certs using fingerprints
Zash
or DANE!
Stevehas joined
MattJ
or DANE :)
Zash
except DANE authenticates the server, not the client / "initiator" unless you do some Dialback dance
Zash
or ... 🥁️ ... DANCE
Guus
MattJ, I am very much not suggesting to _authenticate_ based on an expired cert. I was asking if it would be permissible to continue using TLS for encryption, if the peer presents an invalid certificate - assuming that some other form of authentication mechanism is used.
MattJ
Yes, that's kind of the point
Guus
The alternative being having an unencrypted connection that was authenticated using Dialback.
Sounds like Prosody does similar things to M-Link. Although we have an additional option for whether we allow a remote to authenticate us with dialback.
Zash
Kev, so outgoing and incoming dialback is separate? and/or, policy per remote host?
MattJ
Yeah, I think we just have dialback enabled or disabled entirely
Guus
I'm not quite sure what the distinction is that MattJ might be trying to communicate. I've got a feeling that we're all agreeing with each-other?
Zash
Guus, yes.
Kev
I forget our options offhand, but IIRC we can allow/require/disable TLS, allow/require/disable strong auth, and additionally enable/disable dialback.
florettahas left
Kev
So it's possible for us to require the other end to present a cert we trust, but for it to use dialback to authenticate us rather than trusting our cert.
sonnyhas left
govanifyhas left
SteveFhas joined
snowhas joined
sonnyhas joined
govanifyhas joined
florettahas joined
antranigvhas joined
neoxhas left
Chadhas left
pablohas joined
neoxhas joined
Calvinhas joined
daagshas left
petrescatraianhas joined
con3has joined
mentos124has joined
marc0shas left
marc0shas joined
moparisthebest
Guus: imho dialback is never the correct option, but "same cert" can be if the protocol guarantees it's secure, ie for .onion domains
MSavoritias (fae,ve)
So we are all moving back to 0447 now? /s
con3has left
jgarthas left
pablohas left
Hugohas joined
neshtaxmpphas left
neshtaxmpphas joined
Hugohas left
Hugohas joined
marc0shas left
marc0shas joined
TheCoffeMakerhas left
TheCoffeMakerhas joined
konstantinoshas left
daagshas joined
konstantinoshas joined
Hugohas left
marc0shas left
marc0shas joined
davidhas joined
davidhas left
TheCoffeMakerhas left
TheCoffeMakerhas joined
SteveFhas left
davidhas joined
davidhas left
konstantinoshas left
TheCoffeMakerhas left
catchyhas left
catchyhas joined
TheCoffeMakerhas joined
djorzhas joined
marc0shas left
marc0shas joined
Menelhas left
Menelhas joined
marc0shas left
marc0shas joined
uhoreghas left
Half-Shothas left
Matthewhas left
homebeachhas left
Half-Shothas joined
Matthewhas joined
homebeachhas joined
uhoreghas joined
marc0shas left
marc0shas joined
Maranda[x]has left
Maranda[x]has joined
neshtaxmpphas left
neshtaxmpphas joined
papatutuwawahas left
praveenhas joined
goldbeardphas left
davidhas joined
davidhas left
marc0shas left
marc0shas joined
inkyhas left
marc0shas left
marc0shas joined
marc0shas left
marc0shas joined
Tim Rhas left
marc0shas left
davidhas joined
davidhas left
marc0shas joined
marc0shas left
marc0shas joined
Maranda[x]has left
Maranda[x]has joined
775857429has joined
marc0shas left
marc0shas joined
marc0shas left
marc0shas joined
florettahas left
marc0shas left
marc0shas joined
inkyhas joined
konstantinoshas joined
Fishbowlerhas left
Fishbowlerhas joined
marc0shas left
644043has joined
neshtaxmpphas left
atomicwatchhas left
marc0shas joined
catchyhas left
catchyhas joined
florettahas joined
djorzhas left
davidhas joined
davidhas left
Vaulorhas left
wladmishas left
wladmishas joined
goldbeardphas joined
sonnyhas left
neshtaxmpphas joined
goldbeardphas left
goldbeardphas joined
sonnyhas joined
antranigvhas left
Andrzejhas joined
miruxhas left
miruxhas joined
marc0shas left
marc0shas joined
djorzhas joined
konstantinoshas left
neshtaxmpphas left
neshtaxmpphas joined
praveenhas left
florettahas left
sonnyhas left
pep.
https://bifurcation.github.io/mimi-aim/draft-barnes-mimi-aim.html « ActivityPub for Interoperable Messaging »
pep.
Is there a need for such a document for XMPP btw? Or are the RFCs acting as a proposal or sth?
pep.
There's also a thing for Matrix
MattJ
Yes, someone would need to write one for XMPP
MattJ
Even if it is mostly "see RFC 6120" for most things
pep.
Was that a point at summit or sth?
sonnyhas joined
MattJ
It was touched upon, yes, as part of a broader strategy discussion
its another http transport. not matrix or xmpp based
pep.
TIL https://www.rfc-editor.org/rfc/rfc7702 "Interworking between the Session Initiation Protocol (SIP) and the Extensible Messaging and Presence Protocol (XMPP): Groupchat"
pep.
Another groupchat spec?
florettahas joined
pep.
(t's referenced in the MIMI-AP thing)
neoxhas left
neoxhas joined
pep.
MattJ, that means there are people on it?
MattJ
Nobody actively, that I'm aware of
pep.
Ok. Right now I wonder if we're gonna miss a deadline again because "there's nobody to do it" / "no money on the table"
Zash
The deadline is already passed, innit?
MattJ
I believe so
pep.
great
mentos124has left
Zash
per https://mailarchive.ietf.org/arch/msg/mimi/alm5aSR0e20fuEM6z2RhIwyJuq4/
pep.
So we don't have anything there, that settles it no?
MattJ
Nothing is settled
pep.
But we still don't have anything there
raucaohas left
raucaohas joined
MattJ
Are you volunteering to write the draft?
pep.
I would, but I'm really not good with all the blabla that needs to go in these things
BASSGODhas left
pep.
I'd rather have the XSF pay someone that's good at this
MattJ
Who is that, then? (aka "here we go again...") :)
snowhas left
pep.
Apart from the fact that this could have been done months ago, "I don't know, send something on members@ and ask if anyone is interested against compensation"
Wojtekhas left
pep.
Looks like it's important enough that it was mentioned at Summit and is part of a broader "strategy discussion". Hopefully for this one getting money out won't be this complicated
MattJ
I have made multiple posts to members@
MSavoritias (fae,ve)
fyi we are mentioned on https://datatracker.ietf.org/doc/draft-rosenberg-mimi-arch-options/
pep.
Reading through the mails (I'm not on member I haven't seen them come through)✎
pep.
Reading through the mails (I'm not on members@ I haven't seen them come through) ✏
from what i see the consensus is that the xmpp standards that exist within ietf are enough
MSavoritias (fae,ve)
and matrix and such need to draft proposals because they are not a standard
marc0shas left
pep.
If that's enough to be considered in MIMI then fine. Also why I asked that question first
MattJ
Whatever your definition of "standard" may be, that's not enough. Even if you think RFC 6120 satisfies all the MIMI requirements, a document stating and demonstrating this would still be beneficial.
Zash
And to remind people XMPP exists
pablohas joined
pep.
Which we're always doing a great job at :P
MSavoritias (fae,ve)
well no mention that we are looking for such a person has been made outside of this room as i am aware so..
MSavoritias (fae,ve)
for the person and the proposal i mean
neshtaxmpphas left
moparisthebest
Anyone capable and willing to write it is in this room already
MattJ
I'm not engaging in this cyclic discussion about money and proposals again, we've had it too many times with the same participants, and nothing has changed since last time. I'm working on other stuff right now.
papatutuwawahas joined
MattJ
If someone is blocked on working on something due to financial reasons, the XSF is in a position to help
marc0shas joined
MattJ
But as usual, I am not aware that such a situation exists
neshtaxmpphas joined
Trung
does telegram|whatsapp|facebook|… have some sort of a rfc or draft? To me they seems to be the standard for ordinary users
mentos124has joined
Menelhas left
Zash
Are they even involved in this MIMI WG yet?
snowhas joined
Zash
(Not that I have seen)
pep.
MattJ, thanks for the mails they're helpful
pep.
Zash, they get a pass, they got the monies
MattJ
WhatsApp/Facebook have stated they are not interested, I'm not aware that anyone else considered a gatekeeper has made any public statements
Zash
MattJ, source?
MSavoritias (fae,ve)
it was in the meeting recently at the eu day
Zash
Plus IETF isn't an EU standards org, so there's some uncertainty at whether any of this will really go anywhere in the end
MSavoritias (fae,ve)
they said they want something with signal based encryption
MSavoritias (fae,ve)
not MLS
farenrhas joined
Zash
Ah. I should (re?)read the notes from that
Menelhas joined
Wojtekhas joined
inkyhas left
BASSGODhas joined
daagshas left
neshtaxmpphas left
neshtaxmpphas joined
Vidakhas left
inkyhas joined
Vidakhas joined
wladmishas left
wladmishas joined
davidhas joined
davidhas left
sonnyhas left
sonnyhas joined
pablohas left
farenrhas left
pep.
Ok, I guess count me out of the MIMI stuff. Thinking about it I don't know why I am affected by it. It looks like the only thing that it may bring that I care about is "Hey look XMPP isn't dead". And maybe make it more easy on XMPP devs because we wouldn't have to write the bridging parts.. Entities to which it would bridge (bigtech) I don't want anything to do with them..✎
pep.
Ok, I guess count me out of the MIMI stuff. Thinking about it I don't know why I am affected by it. It looks like the only thing that it may bring that I care about is "Hey look XMPP isn't dead". And maybe make it more easy on XMPP devs because we wouldn't have to write the bridging parts.. Entities to which it would bridge (bigtech) I don't want anything to do with.. ✏
pablohas joined
775857429has left
belovehas left
belovehas joined
Vidakhas left
belovehas left
davidhas joined
davidhas left
Andrzejhas left
daagshas joined
belovehas joined
Vaulorhas joined
florettahas left
775857429has joined
775857429has left
mentos124has left
belovehas left
Yagizahas left
konstantinoshas joined
sonnyhas left
Trung
Thank you for the the report MattJ. I was busy messing with your software (and Zashs') at that time. I'm going to throw my own opinion in here now that I know these things exists:
1) MLS looks like it is short for a 'Messy Layer of Security' in the similar fashion as Android is stucked on top of Linux. (Why don't you just use Linux in the first place and save the hassle of vendor restricting security updates?)
2) MIMI looks like the description of Slidge and this very XSF|XEP stuff that we have.
Most importantly, both look very much like patches for closed source software to talk to each other. Please notice that I am *not* saying the people who are behind them are working for 'gate-keepers' here.
So best I say to all devs is to ignore both of these things and focus on writing great open source software.
As I understand how all these eXempt-Pee-Pee to work together, all you need for interoperability is to throw a XEP out when your stuff are working so everyone else knows how to do the same dance.
belovehas joined
MSavoritias (fae,ve)
from what i have heard MLS is not that bad
Zash
Trung, "Dear gatekeepers, if you want to have interoperability, here's one way you could do it. Best wishes from the IETF"
beanhas joined
pablohas left
moparisthebest
And that way is XMPP, always has been
moparisthebest
As evidenced by the fact they all ran open XMPP until they had sufficient mass for vendor lock-in
sonnyhas joined
belovehas left
belovehas joined
inkyhas left
pablohas joined
Vidakhas joined
emushas left
davidhas joined
davidhas left
tbm16has joined
Dele Olajidehas left
belovehas left
belovehas joined
florettahas joined
pablohas left
snowhas left
oshnhas left
Mikaelahas left
oshnhas joined
pablohas joined
mentos124has joined
pablohas left
pablohas joined
pablohas left
davidhas joined
davidhas left
petrescatraianhas left
catchyhas left
pablohas joined
antranigvhas joined
chipmnkhas left
chipmnkhas joined
jgarthas joined
775857429has joined
*IM*has left
xengineeringhas left
*IM*has joined
xengineeringhas joined
beanhas left
Andrzejhas joined
catchyhas joined
edhelas
I have a 0060 related question there https://github.com/processone/ejabberd/issues/3044#issuecomment-1478572573
belovehas left
edhelas
When pubsub#publish_options is available, are all the fields defined in https://xmpp.org/extensions/xep-0060.html#registrar-formtypes-config supported ? Or can the server only support a whitelist of it ? If its the case how can I know which fields I can set ?
belovehas joined
singpolyma
moparisthebest: "all" is a bit strong since only google has ever done that at scale
singpolyma
Hey all: should https://xmpp.org/registrar/querytypes.html#register list the preauth query param?
moparisthebest
singpolyma: Facebook did too right?
moparisthebest
And WhatsApp started out as XMPP, but as far as I know not federated
Daniel
edhelas: I think the intent is really all
775857429has left
Zash
moparisthebest, facebook only ever did c2s
Daniel
All the server supports
Daniel
And can plausibly use in this auto create mode
edhelas
> edhelas: I think the intent is really all
So basically the same fields as when I'm doing a complete Pubsub node configuration ? https://xmpp.org/extensions/xep-0060.html#registrar-formtypes-config ↺
edhelas
Zash is it how it is done in Prosody ?
edhelas
Okay thanks :)
Andrzejhas left
Zash
Knee deep in other things atm, no idea
Trunghas left
Trunghas joined
Daniel
If someone finds an edge case of when or why this wouldn't work on the server side I'm happy to hear it and we can figure something else out
Daniel
But the way I'm implementing it in the client is that if the publish options fail due to conflict I'm feeding the exact same form data into a node reconfiguration
edhelas
Smart indeed
edhelas
I might also do that
BASSGODhas left
Martinhas left
Trunghas left
BASSGODhas joined
Trunghas joined
flashcorehas left
inkyhas joined
Trunghas left
Trunghas joined
BASSGODhas left
Trunghas left
Trunghas joined
daagshas left
davidhas joined
davidhas left
644043has left
snowhas joined
Trunghas left
Trunghas joined
Vaulorhas left
Vaulorhas joined
Sevehas left
Axel R.has left
goffihas left
daagshas joined
konstantinoshas left
emushas joined
Sevehas joined
moparisthebest
Zash: yea still that's XMPP for interop
atomicwatchhas joined
atomicwatchhas left
singpolyma
Interop with clients isn't super interesting IMO
pablohas left
singpolyma
Especially the barely works degenerate way that Facebook did it 😅