XSF Discussion - 2023-01-07

I have an idea: implement JMI 0.4 in Conversations...

thilo.molitor: we still have the PR for 0.5.0 pending, so that would be kind of wasted IMO.

And the mandating uuid thing?

Daniel: that's really a minor thing compared to the 0.5.0 update.

larma: BTW I added notes about storage / reliability https://codeberg.org/iNPUTmice/up/src/branch/master/README.md

What's the status of Entitiy Capabilities 2.0? Anyone using it in production already? Are there any known issues?

define 'production'. Babbler has an implemenation…

I was thinking that Conversations 3.0 might be a good opportunity to switch (I was going to overhaul the caching anyway)

"babbler" heh

slight animosity or typo?

https://github.com/sco0ter/babbler

oh, right, literally

qy, babbler is an xmpp client library written in java

so i see

Daniel, I was thinking of "the state where it's used by so many people that if there were any major issues, someone would know about them"

yeah I don’t think that applies to babbler. I’m actually not sure if someone uses that because I keep running into the weirdest issues

on the other hand development is relatively steady so someone must be using it

larma, we use it in xmpp-rs, and I also deployed a Prosody module adding it to all presences from JabberFR users, for ease of testing.

I’m not aware of any real client though.

(Please remind GSoC contributors are beginners in many topics, most likely xmpp) ✏

larma, are you expecting any issues though? it seems pretty straight forward

larma: there are no issues I know of ✏

not much is actually changing; it's just incompatible

the only thing worth considering is that this pins us on xml 1.0

I'm not sure if that is a problem, as we are likely pinned on that in other ways already

(in xml 1.1, the separators used are all valid in CData)

I don't think XML 1.1 is really relevant for us, so I wouldn't know why we'd change to it

I also don't expect any issues. I was rather wondering if it's a good candidate for last call

(also I was just drafting some disco form that allows multiple values and was thinking that this is totally going to cause problems with caps 1.0)

from my perspective we can LC it ✏

larma: I don't know if 0.5 will be merged any time soon...you should bring it to the list...

thilo.molitor: I would opt to merge this as soon as possible. I know of at least three clients that started implementing it and a major feature (multi party calls) is relying on it.

I know that multi party calls wasn't initially the goal of the authors of this XEP, but somehow it was decided it should go in there, so we now have to take care of that decision.

Is 2023 the year of multiparty jingle?

With replies, and reactions?

Not sure what you mean, multiparty jingle is already a thing for long time.

It's just that we fail to standardize it properly 😀

And that story seems to be repeating (thinking of Jitsi)

The last part is mostly on jitsi for not wanting to ✏

not today anymore, but they were interested back then when they were still mostly compliant with what is out there ✏

a classic "XSF was too slow" story

Dunno. I wasn't around back then

thilo.molitor, you're author on '353, what's blocking you?

jonas’: I'm not the only author of '353 that's blocking

A kind reminder to XMPP project leads and responsibles to check if GSoC is a thing for you and come up with ideas https://wiki.xmpp.org/web/Google_Summer_of_Code_2023

Can <{muc#user}x><item@jid/></> take anything else than a fulljid?

In theory? Why?

Try it

I was wondering about what was discussed the other day, having MUC provide a barejid from a side-burner-jid component or the like. I'm still trying to see what this would allow though

Is there any client actually using extended addressing ofrom for anything?

Zash, "In theory", as in that's allowed by the spec? Or rather not disallowed? Because there's not reason to put anything else than a fulljid in there with current MUC right?

§7.2.3 "If the room is non-anonymous, the service MUST send the new occupant's full JID to all occupants using extended presence information in an <x/> element qualified by the 'http://jabber.org/protocol/muc#user' namespace and containing an <item/> child with a 'jid' attribute specifying the occupant's full JID:"

It's the set of JIDs that has is part of the participant, no? And normally only full JIDs join MUCs, hence

Ah, sorry I got your message the other way around

Yeah ok

If you were to join from a bare JID, it'll be a bare JID there. Like with that mini-mix hack I made.

Well I haven't gathered ideas from that chat yet but from what I got, you'd still join from a fulljid, just that a barejid would be exposed as your session, not yours but something the MUC would manage as well. Something to combine anonymity/MUC PMs?

Is it possible to give two domains to a component btw?

What if you're joined from multiple fulljids to a muc? Does it show multiple items?

Dunno, it could, but I'm not sure that's interesting if you're doing MSN

If you have different nicks it's probably important not to disclose that it's the same barejid so yeah ✏

PSA: Running upgrades on the xmpp.org web and chat server, there might be some brief disruptions