XSF Discussion - 2023-03-21

Is is possible to share multiple files in a single <message> with XEP-0447 (Stateless file sharing)? Apparently it's not.

It's possible with SIMS, at least, because Swift does that.

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.

We also need to decide once for all which XEP to utilise for file sharing, but that's one of the eternal XMPP problems.

🙂

Does anyone feel they have sufficient context to write a summary of the current options (pros, cons, implementation status) to standards@?

(I don't)

I'm currently writing something for the multiple files issues, that can be a starting point.

Thanks

To this day I don't understand why 447 came about when it basically duplicates SIMS.

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"

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.

Action items: Rename SIMS, give it a casual mention in the 2023 compliance suite, done

That would work for me.

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.

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.

think*

yeah the newer one has some nice improvements

I've sent a message to standard@, and I can propose a PR in coming days, but I'll need backup from XEP authors.

Kev, also 372?

Re why not SIMS

I think that's one of the reasons?

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.

XEP-0372 is not even quoted.

https://xmpp.org/extensions/xep-0447.html well actually there's a whole list of "Why not SIMS" in the spec

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.

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.

Ah I'm getting the whole isode crew on my back :P

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.

Kev: in XEP-0447 body is explicitely allowed as fallback (it's just said that it should not have additional info, which seems sensible)

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.

I guess as the spec is actually being used in places, maybe starting to remove these TODOs would be nice

> : 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.

Isn't that "just" a UI thing?

larma: ping ^

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.

> 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.

(With all the MAM etc. problems that brings)

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

Message1: "hey the pictures I told you about", Message2: <pictures>

Not saying it shouldn't be done of course, or that I'm gonna try to prevent it from happening (referencing stuff everywhere)

now that I'm thinking about it, XEP-0447 is already used with pubsub in XEP-0471

pep., you lose the semantics, unless you parse the message.

While having a message introducing the pictures, as well as a description for each picture, ties it all together.

This is important for accessibility too.

The current Conversations way of sharing media is completely inaccessible.

@alt is possible with 447

I was talking about abusing XEP-0066 for saying “this URL is actually an embed”.

Yeah I wasn't, I was still taking about 447. I agree accessibility is important

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)

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.

larma, the main reason 0385 never got adopted was that it didn’t play well with body-only e2ee IIRC.

We don't encrypt in public MUCs so it could've been used there at least

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

I almost exclusively use the first set, so hadn't realised the last two didn't.

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?

Ignoring what other messengers are doing. Sending images and text in the same message is a very frequently requested feature

Kev: Feel invited to figure out how to do backwards compatibility with SIMS, because I didn't (except having two bodies)

Note the *s* in images

Daniel: and a single text for all images, or a description per message? ✏

Daniel: and a single text for all images, or a description per image? ✏

nicoco: That's indeed on my to do list (assigning an id to each file-sharing if there are multiple)

> 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?

I think common description + optional alt/caption per image is probably what we ought to aim for

I think this is what I've seen in walled gardens, but for accessibility, alt text per image is actually better, isn't it?

(~ alt text with is orthogonal in my mind)

ok

> : 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.

if alt text is covered separately, I'd say that one overarching text alognside the images should do

> 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>?

> 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

nicoco: yes, but then attaching sources won't work

oh right, in 3.3 <sources> is not a child of <file-sharing>. I get it, thanks.

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.

Because fallbacks won't work properly for multiple files either ✏

Why not?

When I talk about fallback I mean fallback to how we do files today.

Not fallback to "here is a bunch of URLs"

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.

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.

Yeah no an (compressed) archive seems terrible

pep.: would be fine for 3 non image files IMO

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?

larma, I guess if one doesn't have to display thumbnails.. but say I only want to download one of them.. it's weird

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.

goffi: example 2 has the file's desc in the body, no additional information beyond that. ✏

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.

Ok

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've always read it*

And so relatedly, what about 372? ✏

I know some clients use it to do mentions, is there anybody not going to use that for mentions?

Also do we need to define a URI for occupant-id maybe?

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) ✏

pep.: my proposal would be to add mention to 0394

And are they any other uses for 372? Is someone someday going to use my mention-in-a-chatroom as something completly different?

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

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.

larma, you mean that thing that's never gonna replace xhtml-im? :x

my proposal would be to kill 394 with fire

and resurrect '70 ✏

And then people who don't care too much could just not do it.

and resurrect '71 ✏

(Other than the ignoring bit)

For "fallback" parts of body we fallback xep

XHTML-IM 2: This time it's secure, surely?

singpolyma, by inline you mean base64?

pep.: No, I mean text and images intermixed. Probably with xhtml-im but can also use the references for that

XHTML-IM 2: This time, we don't pretend that web issues can be solved in protocol.

So.. what about mentions..

Kev: so I read you don't like the grouping thing?

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.

> : so I read you don't like the grouping thing? Maybe I don't understand it, I'm a bit distracted at the moment.

goffi: multiple files is missing exactly because it wasn't clear what's the best way to do it backwards compatible ;)

> 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

and then your MAM page cuts in the middle and half of it is missing in your display ✏

I think that's a problem for many things, not especially with this spec

jonas’: and then you fetch the next page and it repairs

Or you use that new version of MAM that we discussed at summit

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.

Kev: because that's what we effectively do today

But I also don't really understand why fallback of 'prepend URLS to body' doesn't work.

> : because that's what we effectively do today I think that might depend on which 'we' you mean :)

and as I read on mastodon today: "tradition is just peer pressure exerted by dead people"

Kev: because legacy clients would then be shown a list of random URLs?

just like today?

it's ok, as long as the URLs are there

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'.

Consider that *all* your clients would be legacy clients under this definition

Subtle encouragement for implementing non-legacy things is fine

larma, yes, for a while

and then they're fixed and we're good

and for the case of n==1, it works as good as today, right?

jonas’: except that some platforms will never see the update

Eventual inconsistencies

larma, :sadface:

can't have nice things everywhere

I am a debian user, fwiw ;)

Evolution gonna evolution I guess?

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)

Yeah, old clients gradually getting a worse experience is not a reason to hold back the protocol

(or to make it overly complex)

That's the thing. Backwards compat ok but at which cost

Inbound multiple images I store already, will be displaying them later this year I expect

(oob and sims)

if SIMS handle multiple files, why is that acceptable there, and not for XEP-0447?

Backwards compat in the form of some graceful decay seems okay to me.

> 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.

I don't think sending multiple messages is overly complex or high cost

It's super annoying on several levels for the receiver though

goffi, I guess it could, but larma seems to not want to do this?

And.. what about mentions?!

Decaying into multiple messages does have precedent in IRC gateways... Tho I see no huge problem with decaying into <body>{url}+</body>

What about mentions? That seems unrelated?

If everyone is on a mission now to break compatibility, I wonder why SIMS wasn't popular except for some closed corporate environments

Media wasn't popular back then either

singpolyma: seriously?

Even when Conversations launched it was just jingle FT push right? Before http upload existed

Zash, this can be handled by the IRC gateway, breaking into separate messages

Pull media is still a brave New world

If >5 years in production is new for you ✏

singpolyma, the advantages of SIMS are not enough to warrant the change

if we get media messages (with more than one file) with alt text each, plus accompanying text, that's a different beast

also, I meant to ping larma

jonas’: 90% of cases, people are still going to send a single file without text

great

> 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?

+ metadata which are necessary for accessibility.

larma, have you looked at Mastodon? :x

larma, add an oob tag, and it'll magically work in all exitsing clients then

jonas’: so it shouldn't break for them.

without the ugly splitting part needed for the case when more than one image is attached ✏

description + @alt is pretty standard in my TL

Many clients require the URL to be in oob and body

what pep. says, too, but mastodon isn't the same use case as XMPP is.

larma: that's not true, and other messenging, I see people sharing whole albums.

> 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 ↺

But if new clients display the body (aka the URL) their UX will be bad

Plus hashes are a big deal for me and non http options

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? ✏

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.

We do have different ideas of what reasonable backwards compatibility looks like.

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. ✏

A/B test all the XEPs?

Next Dino release will support 0447, so yes, A/B testing is going to happen anyways

> 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.

Compatibility can only come when we do the work. That's why the transition happens slowly instead of all at once

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. ✏

Do we have a set scope for what we want?

For our side we're starting by slowly introducing text+image now that we have two clients that support it

singpolyma: which clients?

larma: Cheogram Android and Movim

And what about all the other clients?

those clients see fallback in the cases we use text+image

which is why we are doing it slowly and not in every case it makes sense yet ✏

The fallback being text + URL?

yes

So you're planning to severely degrade UX of >90% of active XMPP users

No

Different use-cases and interop yay

Right now we only do it in cases where it would be degraded for those other users anyway

Someday people will realize interop is a fantasy

namely, group text, where we have several fallback in play usually

pep., or, a process?

eventual interoperability?

yes!

But it's a trade off between better experience for most of our users vs degraded experience for the few using other clients

and we do walk that line carefully

"most of our users" which reconfirms the bubble thing I was talking about

Well, obviously our service will prioritize the experince of people who use it :)

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.

singpolyma, said matrix.org on IRC :P

pep.: that's sort of the opposite case

Or, maybe it's similar. Since we have to degrade the experince of MMS users due to these limitations in XMPP clients right now

But it's pretty small at this point I think, people don't often ask us why multi file is weird

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

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.

Would it not be easier to say "I'm in the same bundle as <the-previous-message-id>"?

That means that to know if you have the whole message you have to wait on a timer?

"maybe I have the whole message now, oh oops here's another piece"

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.

For what goffi says yes, for what I say, no?

It's fine, you just update your display?

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

pep.: what if my "display" is that I'm sending an MMS message with text+images ?

or an email

Ah well

or any other gateway protocol that supports text+images :)

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.

I find it awkward though what goffi says. You may be waiting on messages that will never come

larma: what do you think about it (grouping to have multiple files + message at the same time)?

pep.: that's implementation to handle, I would put a timeout, and display what I have if nothing happen after X seconds.

vs just using multiple oob and having them all at once

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.

And clients that don't care about backwards compatibility can just put the file sources in the initial message.

putting source aftewards is a great idea, indeed with the upload delay

that looks quite good to me.

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.

OTOH this approach does have benefits beyond backwards compatibility

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.

Source attaching is already a feature in 447 (and a very sensible one IMO) so the nuisance for MAM is already here ;)

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).

Kev: most other messengers announce the file before sending

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.

Wasn't there a XEP like that now?

Extension to chat states?

> : 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? :)

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

Kev: they even do for single files without text

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.

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.

goffi: maybe we should build it and make sure it works before writing yet another XEP draft ;)

> 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?

singpolyma: isn't it about updating XEP-0447?

Build it, take notes, turn notes to XEP? :)

Zash: indeed

Kev: I've seen an file being removed from the chat because the uplaod failed

and yeah, that's what experimental is for.

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...

Zash, you mean like we used to have? Yeah... :)

and implement webtorrent, welcome to XMPPpeertube

MattJ, `uploader http socket | tee storage | downloader http socket` :)

or like, async promise something something waiting for completion

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. ✏

If we did the multi-upload-slot thing (for upload resumption of large files), we could expose that to the recipient somehow

But this is a tangent discussion I think :)

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

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.

larma: thanks much for that fallback revision BTW, it has made several new features possible for us already

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?

Sure, dialback if it's allowed.

(assuming that authentication happens through Dialb... that)

If you allow dialback, unauthenticated TLS is still better than no TLS.

I'm having trouble reading https://www.rfc-editor.org/rfc/rfc6120#section-5.4.3.1 in a way that this is permissible.

Well, 6120 removed Dialback, so under just 6120 TLS auth is the only permitted auth.

""" * 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. ✏

Guus: Is that section for s2s? ✏

starttls in general, I believe.

> If the initiating entity presents a certificate Guus: I don't read this as requiring mutual TLS certificate authentication

I'm not talking about mutual authentication (or at least, I didn't intend to be)

The sections are about StartTLS in general (which I assume also apply to direct TLS, but that's another matter)

Direct TLS is just StartTLS squeezed into the TCP port number ;)

excellent compression rate.

I thought security and compression were a scary combo!

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"

Guus, https://www.rfc-editor.org/rfc/rfc7590.html may also be relevant to your interests

> 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

Thanks guys.

larma: could you add an example for multiple files sharing in your update XEP please?

goffi: yes, I will

larma: thx.

> [<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.

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.

Local policy? I.e. configurable

Either you use TLS for authentication, or you don't. If you do, you can't just allow self-signed, expired, etc.

If you use something else for authentication (e.g. dialback), those things don't matter at all

Prosody just has options to require TLS for authentication, and to require TLS for encryption

On top of that we have plugins to e.g. authenticate self-signed certs using fingerprints

or DANE!

or DANE :)

except DANE authenticates the server, not the client / "initiator" unless you do some Dialback dance

or ... 🥁️ ... DANCE

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.

Yes, that's kind of the point

The alternative being having an unencrypted connection that was authenticated using Dialback.

Relevant https://xmpp.org/extensions/xep-0344.html ?

Practically everyone (on the public internet) requires encrypted connections these days

https://github.com/stpeter/manifesto/blob/master/manifesto.txt

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.

Kev, so outgoing and incoming dialback is separate? and/or, policy per remote host?

Yeah, I think we just have dialback enabled or disabled entirely

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?

Guus, yes.

I forget our options offhand, but IIRC we can allow/require/disable TLS, allow/require/disable strong auth, and additionally enable/disable dialback.

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.

Guus: imho dialback is never the correct option, but "same cert" can be if the protocol guarantees it's secure, ie for .onion domains

So we are all moving back to 0447 now? /s

https://bifurcation.github.io/mimi-aim/draft-barnes-mimi-aim.html « ActivityPub for Interoperable Messaging »

Is there a need for such a document for XMPP btw? Or are the RFCs acting as a proposal or sth?

There's also a thing for Matrix

Yes, someone would need to write one for XMPP

Even if it is mostly "see RFC 6120" for most things

Was that a point at summit or sth?

It was touched upon, yes, as part of a broader strategy discussion

https://www.ietf.org/archive/id/draft-rosenberg-mimi-protocol-00.txt

there is also this one

its another http transport. not matrix or xmpp based

TIL https://www.rfc-editor.org/rfc/rfc7702 "Interworking between the Session Initiation Protocol (SIP) and the Extensible Messaging and Presence Protocol (XMPP): Groupchat"

Another groupchat spec?

(t's referenced in the MIMI-AP thing)

MattJ, that means there are people on it?

Nobody actively, that I'm aware of

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"

The deadline is already passed, innit?

I believe so

great

per https://mailarchive.ietf.org/arch/msg/mimi/alm5aSR0e20fuEM6z2RhIwyJuq4/

So we don't have anything there, that settles it no?

Nothing is settled

But we still don't have anything there

Are you volunteering to write the draft?

I would, but I'm really not good with all the blabla that needs to go in these things

I'd rather have the XSF pay someone that's good at this

Who is that, then? (aka "here we go again...") :)

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"

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

I have made multiple posts to members@

fyi we are mentioned on https://datatracker.ietf.org/doc/draft-rosenberg-mimi-arch-options/

Reading through the mails (I'm not on members@ I haven't seen them come through) ✏

there has been two

https://mail.jabber.org/pipermail/members/2022-November/009472.html

https://mail.jabber.org/pipermail/members/2022-July/009417.html

but none of them mention money or a proposal

as i can see

from what i see the consensus is that the xmpp standards that exist within ietf are enough

and matrix and such need to draft proposals because they are not a standard

If that's enough to be considered in MIMI then fine. Also why I asked that question first

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.

And to remind people XMPP exists

Which we're always doing a great job at :P

well no mention that we are looking for such a person has been made outside of this room as i am aware so..

for the person and the proposal i mean

Anyone capable and willing to write it is in this room already

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.

If someone is blocked on working on something due to financial reasons, the XSF is in a position to help

But as usual, I am not aware that such a situation exists

does telegram|whatsapp|facebook|… have some sort of a rfc or draft? To me they seems to be the standard for ordinary users

Are they even involved in this MIMI WG yet?

(Not that I have seen)

MattJ, thanks for the mails they're helpful

Zash, they get a pass, they got the monies

WhatsApp/Facebook have stated they are not interested, I'm not aware that anyone else considered a gatekeeper has made any public statements

MattJ, source?

it was in the meeting recently at the eu day

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

they said they want something with signal based encryption

not MLS

Ah. I should (re?)read the notes from that

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.. ✏

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.

from what i have heard MLS is not that bad

Trung, "Dear gatekeepers, if you want to have interoperability, here's one way you could do it. Best wishes from the IETF"

And that way is XMPP, always has been

As evidenced by the fact they all ran open XMPP until they had sufficient mass for vendor lock-in

I have a 0060 related question there https://github.com/processone/ejabberd/issues/3044#issuecomment-1478572573

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 ?

moparisthebest: "all" is a bit strong since only google has ever done that at scale

Hey all: should https://xmpp.org/registrar/querytypes.html#register list the preauth query param?

singpolyma: Facebook did too right?

And WhatsApp started out as XMPP, but as far as I know not federated

edhelas: I think the intent is really all

moparisthebest, facebook only ever did c2s

All the server supports

And can plausibly use in this auto create mode

> 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 ↺

Zash is it how it is done in Prosody ?

Okay thanks :)

Knee deep in other things atm, no idea

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

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

Smart indeed

I might also do that

Zash: yea still that's XMPP for interop

Interop with clients isn't super interesting IMO

Especially the barely works degenerate way that Facebook did it 😅