XSF Discussion - 2024-03-08

Sorry for going on and on about the avatar conversation xep... I iterated on my suggestion from yesterday and now both the 'copy' approach that ejabberd uses and the 'inject' approach that prosody uses have their own security considerations https://gultsch.de/files/xep-0398.html

LGTM regarding copy/inject

The third paragraph of the security considerations, I don't understand (also 'Therefor' -> 'Therefore')

I'm not sure why clients would warn users that servers advertising the conversion feature will leak the avatar publicly

> I'm not sure why clients would warn users that servers advertising the conversion feature will leak the avatar publicly Because leaking the avatar was how the xep worked. So it's not necessarily a bug on server but previously allowed behavior

But I guess I can just remove that paragraph entirely

I mean if you look at the currently published xep it has wording wrt the warning

Ah, I see

One can make the argument that it was just an experimental xep and ejabberd is now 'wrong' and we just ignore that part of the history of the xep

Experimental XEP, please let's write how we want it raise the namespace if necessary

This is the old thing again that we don't accept what experimental means

Bumping the namespace is what we are trying to avoid

Otherwise I guess we would just write a new xep that is much closer to how prosody behaves

Is current ejabberd leaking the vcard regardless of access control today?

or is this just an "old servers that haven't updated" thing?

> Is current ejabberd leaking the vcard regardless of access control today? Holger: can probably confirm or deny but I belive so

Why a new XEP, experimental is there to learn and adapt from implementations

For backwards compatibility we could bump the namespace or define an additional feature for servers that implement access control

Bump.

Bumping has a cost

It makes it clear that the other behaviour is not wanted

Additional feature does not

Advertising both the old and new namespaces is even a little weird in this case

I would prefer not to bump

So it would make more sense as just an additional feature

I can just remove the paragraph and we all pretend ejabberd is out of spec

Well, it's a valid security concern I think

It's just awkward, I don't think clients should need to show a warning for servers that support access control

Leave it in until most ejabberds are fixed. It's just a MAY

and there is no way for the client to know if the warning is necessary or not

Even if we bump there is still no way of knowing the server leaks your avatar

Why not?

I don't need to know

Server should never leak private data

It's a bug on the server

I don't care if a XEP may allow it

I'll remove the paragraph. I think that's a valid thing to do in an experimental xep.

In XEP-0343, the `<sctpmap>` elements use `number` attribute for the port in all the examples, but the §4.2 syntax says to use `port` instead. Which one must be used? Is the author (Jens Bavendiek) here?

Also, the schema says `number`.

edhelas: you seems to have done the only implemetation, which one did you use? ^

"number" apparently, (I'm checking Movim code)

OK so I guess section §4.2 needs to be fixed.

What movim has a 343 implementation?

Normative examples strikes again?

Daniel: apparently yes, it's announced in DOAP, and I see some related code.

I've made a PR by the way to fix that: https://github.com/xsf/xeps/pull/1331

We have an implemention of data channels too but it's slightly different (and uses a +1 namespace) because we've found the current xep inadequate

We weren't aware that there are already other implementations

Daniel: I'm working on one, and you can see in the XEP listing that Movim is a declared implementation. Is there some documentation of what you have done? A PR to update XEP-0343 or an other protoXEP somewhere?

Daniel, is the specification of your "+1 namespace" implementation available? I assume "+1 namespace" means you bumped xep343's namespace and implemented that in Conversations?

Yes that's what I meant. No it's not yet available. But the plan is to modify the existing xep instead of creating a new one

ok, so there is only a minimal risk that xep343 also bumps its namespace but uses a different specification than yours

Daniel: there is no any documentation? No wiki or whatever? I'm doing implementation right now, and I need something to work with.

If it's not too far away from current XEP-0343 it's fine, I can adpat later.

adapt*

I always wonder if we should re-introduce ":tmp" like namespaces, but different from the :tmp we did in the past. something like urn:xmpp:jingle:ft:4-NEXT (or urn:xmpp:jingle:ft:4-SNAPSHOT) where it is clear that this is a namespace which may not be interoperable because it is under active development. and once we are pretty sure that the new protocol is sufficiently stable, all implementations switch to urn:xmpp:jingle:4

I can publish an xml dump later

flow: I don't think this solves anything

Because then tmp become the permanent thing

Daniel, right now, don't you make breaking changes to your +1 protocol?

Yes it's a breaking change. Hence the bump

also see the last half-sentence of my statement "all implementations switch to :4"

Otherwise we would probably have done it in the existing one

Daniel, sorry, that is not what I meant: don't you do breaking changes while you already announce the +1 protocol?

it's clear that you bumped the namespace because of a breaking change

flow: as long as we are in experimental, I don't see a problem of increasing number regularly until we're happy.

but while you explore the new protocol version in the new namespace, you may also want to introduce new breaking changings

Numbers are cheap.

goffi, that bit us, IIRC multiple times, in the past

Every time you make a breaking change, you bump.

while numbers are cheap, namespace bumps are expensive, the prime example was MAM ✏

No, breaking change bumps are expensive. That a namespace bump goes with the breaking change is neither here nor there.

We work to avoid breaking changes, rather than working to avoid the namespace bump that goes with a breaking change.

Kev, not sure what that's supposed to tell me. you wouldn't bump a namsepace without a breaking change

Exactly.

So the namespace bump isn't the issue, the breaking change is.

right, sure, but that's not what we are discussing right now

of course if you can avoid the breaking change, then don't do it

but sometimes you have to ✏

> flow > while numbers are cheap, namespace bumps are expensive You can understand why I might think you were talking about namespace bumps, right?

mam:2 was done for a reason, and so was mam:3

experimental is there to make breaking changes. Implementation have to adapt while the spec is in this state.

however, if we had a mechanism to test and experiment with new breaking protocol versions, then we would probably avoided two successive namespace bumps in a realtively short period

Which doesn't buy us anything, because it's the breaking change that's expensive, not the namespace bump.

Kev, two namespace bumps are significantly more expensive than one, especially if you have to support two namespaces simultanously because the bumps where done in a relatively short period

that's the point

But they're not.

The only thing that not bumping changes is that it's no longer possible to reliably interop on the interim namespace because it's mutable. ✏

If you never intend supporting the interim versions, it makes no difference to you. It's no harder to bump your namespace from :0 to :9 than it is from :0 to :1

If you do intend supporting the interim versions, you can only have reliable interop if they're uniquely identified.

I think that isn't remotely the only thing that this changes, I can't argue with your last two points

It's not as if (interim):2 and (interim):3 will interop if they were both called :tmp, just that you would see interop failing because there's two entities doing :tmp with different specs with breaking changes between them.

However, I truely believe that if had better mechanisms to accumulate breaking changes in XEPs *and* also test these changes in the field, then we would have avoided the mam namespace bump mess

and fwiw, -NEXT namespaces aren't supposed to be rolled out to every end user. maybe end-users could opt-in to explore experimental features, but that's it

If all the MAMs had been :tmp, it would simple have meant that nothing would have worked because clients and servers would have implemented different incompatible versions of the specs, without namespaces to distinguish them.

right, that is why this wasn't my proposal in any way

I think you always have those :tmp namespaces in mind when making your statements

those where a terrible idea and abandoned for a good reason

Well, yes, because whether you call them :tmp or :next doesn't make a difference - if you have multiple breaking changes under the same namespace, interop fails.

And if you don't have that, then the :next doesn't have significant value, because they're unique namespaces anyway.

absolutely, but the point is what we need a designated namespace where it is expclitly allowed to make breaking chanings while keeping the namespace stable

And that's then equivalent to :tmp

Breaking changes under the same namespace = can't interop reliably.

Daniel, theoretical question: if a breaking change where to be required today for the protocol in your +1 namespace, would you bump the namespace?

goffi, this is what Conversations does: https://gist.github.com/iNPUTmice/6c56f3e948cca517c5fb129016d99e74

I wasn’t prepared for this or else I would have put this into a more proper xep form

didn’t I talk to you at summit saying I had implemented that and you said you weren’t interested because people should just use HTTP upload?

flow: officially, no experimental xep should be "rolled out to all users" an experimental is the place to do as you say. In practise many of us choose to deploy experimental things to prod, but when we do I guess we take on the burden of deciding what versions to interop with. I don't like breaking changes but they are of course better than committing to the wrong xep just to avoid work. I think sometimes we can make non breaking changes (such as add an element or attribute) without a namespace bump. But truly breaking changes surely benefit from one as was discussed

> I think sometimes we can make non breaking changes (such as add an element or attribute) without a namespace bump And we do.

That's why we end up adding extra elements under different namespaces so we can avoid breaking changes.

Kev, I think you definition of a breaking change is different then mine. Adding an extra element, even under the same namespace, doesn't automatically imply a breaking change in my book

goffi, it seems that movim doesn’t support 0234 (file transfer) or 0261 (ibb) so if they claim they support 0343 I’m not really sure what for?

If an element previously wasn't allowed as part of a namespace, and then is, that would be a breaking change.

(Or attribute, similarly)

singpolyma, I don't think there is a written requirement from the XSF side that experimental XEPs are not rolled out to users. In fact, the XEP status disclaimer just states that " production systems are advised to carefully consider whether it is appropriate to deploy implementations of this" ✏

so I guess when i said "i thought we were the first ones to implement" i guess I was half right

Kev, to be frank, I find this strict interpretion unhelpful and not sensible in practice

I suspect you have different types of customers for your stuff :)

if a new elememt/attribute can be ignored by the receiver, while still being compliant to the protocol, then it is not a breaking change

Making sure data that are sent are valid is a big thing for some people.

Kev, definetly

Daniel: I see, thanks.

Kev, however, I am not sure how introducing a new optional element to an existing namespace hinders validation in any way

the validating entity must be aware of the new element, of course

Daniel: another issue with this XEP, is that I'm not sure if the author is still around. Did you try to contact they by any chance? What is the policy if we can't reach them?

I was on my mobile earlier. I guess now I have some more time to elaborate. I met up with larma for a sprint in December to implement that. so when I say "we" I meant him and myself. so the modifcations we did (essentially making this xep a wrapper arount ice-udp transport instead of an extension to ice-udp transport) was mostly due to feedback from larma. I personally didn’t care and would have implemented the current one

however i was faster with my implementation while Dinos implementation is still in the works

so i guess we were somewhat waiting on dino to finish their prototype (to double check we did it right) and then adopt the Xep accordingly

But there is the one is Movim too. Anyway it doesn't seem a big hassle to switch to your version once all the rest is working.

goffi, if the author is no longer around conucil can add a new author

> But there is the one is Movim too. Anyway it doesn't seem a big hassle to switch to your version once all the rest is working. but is there?

like i said it's mostly used for file transfer and movim doesn’t have it?

at least according to their doap file

Daniel: it's announced there, and I've seen some code to handle the XEP elements, so I guess there is. Waiting for edhelas to confirm.

yeah but what does it do

(where there is the XEP/DOAP)

I assume they maybe have some sdp<->jingle code for that

> If an element previously wasn't allowed as part of a namespace, and then is, that would be a breaking change. You can add elements to a namespace and it's not breaking if they're not required ↺

but if it's not weirded up to anything

like I assume that you goffi are currently trying to implement jingle ft, no?

you can’t use that with movim I don’t think

singpolyma, Kev thinks otherwise (if I understand him correctly)

Daniel: I'm not at pc but reading between lines this is about ice-tcp?

singpolyma, no about datachannels

Oh, data channel specifically ok

which can work on ice-tcp (but that's a different story)

Daniel: Jingle FT is already implemented in Libervia for long, but I want to add WebRTC data channel at transport to be able to do P2P transfert with web frontend. Also it's part of my current grant.

> Daniel: it's announced there, and I've seen some code to handle the XEP elements, so I guess there is. Waiting for edhelas to confirm. Travelling right now, will check tonight ↺

goffi, yeah generally good idea. like i said we did this too (in an attempt to slowly fade out socks proxies)

because users generally make sure their turn servers work (because they need this for a/v calls) and then forget about their proxy65

plus slightly higher chance to get actual p2p working

Once done, it will open the door of neat things, like transfering huge file from desktop to any browser.

yeah, and works with browser.

yeah or device 2 device MAM (which is the project I have been working on)

and file transfer was just a side benefit

Also e2ee which socks usually isn't since xtls never happened

yeah... I mean for files you just do omemo. but yes

Libervia does e2ee with socks (with Jingle FT)

using JET

Omemo with socks?

yes

I wasn't aware that was even possible

XEP-0395/XEP-0396

jet is indepentent of transport

XEP-0391 sorry, not 395

Well, indeed I didn't know anyone had done jet either

technically with data channels files are encrypted twice

we can skip JET for data channels.

yes. but then you need to verify your dtls

Sure, like for calls

but that method is not a xep and sortof relies on message init

but yes Conversations will probably support both eventually

for now it's just JET though for files

SCE over the jingle handshake would do it, no?

oh sure. we can also role out sce first

Or do SCE only for calls/ft temporarily if that's easier, since it's "new" so no compatibility issue as much

Libervia does SCE too.

anyway. glad other people are interested in FT over datachannels

but no JET or SCE with web frontend so far (doable, but very complicated with the architecture), so data channel is a win there too.

moparisthebest, there you go: https://xmppbl.org/stats

MattJ: and these aren't the rtbl (muc only) numbers?

this is 1:1 only

No, I decided not to publish stats on that (it could easily turn into a bad incentive to get on the scoreboard :) )

It's just reports of direct 1:1 spam

Ah I didn't even know this existed https://modules.prosody.im/mod_report_forward

The module nor the submit@reports.xmppbl.org

MattJ: "5 contributors" is that servers or individual JIDs?

Servers

The number of reporting users is higher

So 141 jids sending 682 spam messages in 30 days, hard to say, and I'm sure it's underreported, but as a percentage of total messages that's gotta be very small right?

This is a small fraction

But it depends what you mean by "small" - it's obviously going to be less spam in a day than email sees in a minute :)

and lots of it is filtered already, so it depends if you count before or after filtering

The solution is obvious, only allow messages from people with verified non-voip phone numbers, right singpolyma ? 🤣💀

Probably want to do the opposite on XMPP. You're only a real user if you have a JMP account....

Seriously though the simplest thing we could do is just standardize a account setting for "block messages from people not on my roster" ? Could make it work for whole domains too (so that if you had, say, cheogram.com in your roster *@cheogram.com is allowed)

That is something I have wanted to do for a long time

Then the next nicest step would be to standardize something like a "dashboard" for messages blocked by the filter

So like, once a week or whatever you can go there and allow some through or block or report others etc

(ie *not* a pop-up everytime someone adds you as a contact or tries to send you a message, at least by default)

> Seriously though the simplest thing we could do is just standardize a account setting for "block messages from people not on my roster" ? Could make it work for whole domains too (so that if you had, say, cheogram.com in your roster *@cheogram.com is allowed) Also I think this is all of what is needed for MSavoritias fae.ve 's f2f thing ↺

two things: 1. f2f is not really what i want (was thinking about this). Because i want also people you dont have in your roster or that dont directly know you to contact you. also people in the group chats should be able to participate even if they dont know you. I would say its consent network and leave it at that. 2. a big part of what i want i want is capabilities on every stanza in the xmpp protocol. but its too early to disclose more details. I want to have a more concrete proposal first.

that said i would welcome to be able to block domains easily on xmpp. as a short term solution

it would be a major improvement

XEP-0191 already supports domain blocking

https://xmpp.org/extensions/#xep-0191-implementations <3

ah nice

> I was on my mobile earlier. I guess now I have some more time to elaborate. I met up with larma for a sprint in December to implement that. so when I say "we" I meant him and myself. so the modifcations we did (essentially making this xep a wrapper arount ice-udp transport instead of an extension to ice-udp transport) was mostly due to feedback from larma. I personally didn’t care and would have implemented the current one Just in case anyone wonders about the rationale here: XEP-0166§12.2 specifies that any transport method must specify if they are streaming (like TCP) or datagram (like UDP) transport. Jingle FT can be used with any streaming transport, Jingle RTP can be used with any datagram transport. ICE-UDP is obviously a datagram transport and XEP-0176§4 explicitly states so in its Jingle compliance section. The current XEP-0343 also has a Jingle compliance section, but that section is incomplete as it doesn't follow all the requirements of XEP-0166§12.2 - and this is because it is not compliant with XEP-0166, as it changes the transport type of an existing transport method (ICE-UDP), which was not considered something that can happen as per XEP-0166. ↺

By turning things the other way round - encapsulating ICE-UDP information inside the datachannel transport instead of encapsulating datachannel information inside the ICE-UDP transport (as I proposed and Daniel implemented in Conversations) it can be made compliant with XEP-0166.

Now this is an IMO, but I think the design of Jingle has a flaw there, in that it is based around the idea that there is a single transport protocol, any amount of security protocols (called preconditions) and a single application data per content. Today we have the situation that a) multiple contents share the underlying transport and b) transport protocols may appear at any location in the stack, not strictly before security protocols.

thanks, larma. Please consider to add the rationale you just elaborated to the updated version of the XEP

> Then the next nicest step would be to standardize something like a "dashboard" for messages blocked by the filter Yeah I'd rather built this kind of client feature than actually block such a big blanket server side, if that's a direction users are interested in (and based on the UI in most other messengers I expect there would be interest) ↺

I think such things are best done as per-server stuff in a browser, personally.

So the thing to standardise, to my mind, would be a way for the client to redirect to such a page. ✏

singpolyma, didn't you make the editor triage script actually tag github issues? would you care to join xmpp:editor@muc.xmpp.org?join to share/discuss ?

moparisthebest: yes it's in a PR

singpolyma, would you like to take a shot at making that auto-apply them in github actions ?

Yes, if people have tried the script and it works well I'm happy to write the yaml should be trivial

Just do it, if people are unhappy we'll fix the script, if we wait for blessings it'll never happen :)

sure, I can write the yaml soon and put in another pr

"good now is better than perfect never" or somesuch

> "good now is better than perfect never" or somesuch 💯 ↺

I'm gonna steal that...

(terms and conditions apply, random paraphrased quotes on the internet are not suitable in every situation, think about it for five minutes before applying to sensitive areas)

with jingle, is it mandatory that'transport-info come only after session-initiate?

Hmm, I think sort of else how would you know the sid?

But maybe not

transport info also specifies sid

it would be mean to start sending them before session-initiate and expect the peer to remember it for the specific content until he gets session-initiate (which from his pov he may not even get, so probably store it with a timeout? oof) just wondering if that's something I can count on NOT happening

I think so

I think you can count on them coming after the session init. But maybe before you have accepted the session