XSF Discussion - 2024-06-27

it's communicating while using the client as a transport :)

Looking at XEP-0054 vcard-temp, section 3.3 (http://xmpp.org/rfcs/rfc6121.html#rules-localpart-nosuchuser): > If no vCard exists or the user does not exist, the server MUST return a stanza error, which SHOULD be either <service-unavailable/> or <item-not-found/> (but the server MUST return the same error condition in both cases to help prevent directory harvesting attacks). RFC 6121 section 8.5.1 (https://xmpp.org/rfcs/rfc6121.html#rules-localpart-nosuchuser): > If the user account identified by the 'to' attribute does not exist, how the stanza is processed depends on the stanza type. For an IQ stanza, the server MUST return a <service-unavailable/> stanza error to the sender. Doesn't that mean that `item-not-found` as suggested by 0054 cannot be used?

Traditionally XEPs have been given priority over the RFC, but in this case I would stick with the advice in the RFC (especially since the XEP gives you that option)

Isn't the rationale between both conditions the same anyway (protect against harveting)?

(as in: shouldn't we drop item-not-found from 0054?)

Yes

Would be a breaking change though

I've raised https://github.com/xsf/xeps/pull/1351 with a suggested change.

so at which point will pms work consistently? when muc 2.0 or mix are done i.e. the far future?

or is there hope for a breaking change in muc which straightens this out?

What do you mean by "consistently"?

My understanding is that the problems where a PM send on one device will not appear (carbon?) is due to an inconsistency how messages are replicated in MUC vs 1:1

I.e. some re-intepretation of wether all devices of a user should be joined in a room or so - I forgot the details, but the effects are very prominent

The fix for that is to not use MUC PMs or wait for MUC 2.0 or MIX which remove the ability to use MUC PMs :)

well that's kind of exactly where I started isn't it 😝

MUC joins are per-client, so PMs go to one client

Sure, I'm hoping I answered your question

Well, kind of. The timeframe isn't much clearer to me now, though.

(the educatedly-guessed timeframe, that is)

The majority of the federated XMPP ecosystem is made of open-source projects

I don't know how familiar you are with open-source project scheduling, but wait around long enough and you'll see :)

Or won't.

I'm a very experienced complainer :D

I mean 369 is experimental but I haven't so much as remotely heard that any client tried to support it (or server, for that matter)

Nobody can set a timeline, it will be done when it's done. My personal goal is to have a post-MUC protocol in Prosody by the end of the year.

369 is supported by Tigase XMPP Server, Siskin IM for iOS and Beagle IM on macOS

And M-Link (not open-source) and ejabberd has a MIX prototype

And Kaidan afaik

Ah wow, okay. MattJ that's all I needed, for me it's question of 1 year vs 10 years. So I hope this means we're closer at 1 year

Well I'm not holding my breath for MIX at this point

Well the summit killed MIX

Long live MUX? :)

why is it not Deprecated then?

What why?

Daniel, that time when we all promised to go home and implement MIX? Yeah that definitely killed it

Zash: that was the summit before that

And then we didn't do that

MattJ what's the post-MUC you're referring to then?

I just want us to fix the glaring issues that are baked into MUC (nick-as-resource addressing, implicit presence membership etc.), MIX tried to do that. If there are better ways, we can change MIX. If there's bits that cutting out of MIX makes it more palatable, we can trim them, etc. I am not desperately tied to the protocol that's in MIX. But I also don't think MIX is as far removed from MUC as it appears to people.

ManDay, I'm drafting a proposal here, which I plan to prototype in the very near future: https://pad.nixnet.services/s/7xKNOKxxE

MIX throws everything out and starts from scratch with a very different (and unproven) architecture. This proposal is more about making a bunch of smaller improvements to MUC, without needing to rewrite the world or jump through hoops for backwards compatibility.

MIX really does not do that :)

Or, at the very least, is not trying to do that.

changing nick-as-resource addressing and a few other things will break compatibility anyway…

It doesn't jump through hoops for backwards compatibility? This is true ;)

It's all meant to map cleanly between MUC/MIX (as much as possible) and when I was knocking together prototype code it all seemed to do that.

> changing nick-as-resource addressing and a few other things will break compatibility anyway… I don't think that has to be at all true.

MattJ, I was able to write component that supports both MIX and MUC so compatibility is not an issue in my opinion

Andrzej, it's easier to present the two interfaces of the same room than it is to present MUC and MIX

Yeah, it's not an issue for you if you've already done it, I agree :)

But no other (open-source?) implementation has achieved it

did any tried?

Ejabberd and Openfire implementations never made it to OSS did they?

Yes, I made two attempts, and ejabberd still has an experimental branch

MUC compatibility is a hard requirement for me, because I care a lot more about the federated network than about closed deployments

I don't know if ejabberd's implementation bridges to MUC, maybe Holger knows

yes, it was in oss. We tried a prototype implementation, but have been lazily (guilty for that) waiting for the next steps in case it had to get through significant changes.

Mickaël, do you know if it bridges to MUC, or whether MIX groups are independent?

i.e. can a MIX client and a MUC client transparently join and manage the same room?

> Mickaël, do you know if it bridges to MUC, or whether MIX groups are independent? No bridge, just separate service for now ↺

Right

That's pretty simple to implement, but I didn't even try

That is, if you have a pubsub implementation, which we all do, it makes MIX very easy :)

MattJ the issues you mention all go a bit over my head. From my perspective I'm happy with MUC but for a few small grievances, like PMs, which seem to be solvable by straightening out non-fundamental flaws. But that's just my user perspective.

Same here. But instead of fixing those small issues, MIX invented an entirely new incompatible protocol for group chats :)

If we didn't have to worry about existing implementations and deployments, that would be fine

It's not incompatible, it's really not hard to have MIX and MUC be the same entity.

Well your proposal also contains not so few not so small architectural changes. I'm not saying it's a bad thing in either case; I just can't relate to it.

That's something I disagree on, but I understand that my opinion is based purely on my own experience

ManDay, my proposal is all stuff that we are already doing or can trivially do on top of MUC today

But right now it's spread out across a bunch of different XEPs

I see nothing wrong with that. It grew into several XEPs so what

It makes it harder for developers to know what's what

I think that is at best a formality or remedied by an overview document - nothing which demands redesign of the actual semantics.

It gets messy. We've done similar consolidation with SASL2/Bind2, and it simplifies implementations a lot. Simpler protocol and implementation leads to faster development and fewer bugs.

I risk repeating myself, but MIX, today, as specified, is prone to message loss

The answer is always "we can fix that", whever I point out issues in MIX

and it's not untrue, we could

The PM issue though, please refresh my memory (I can't find the debate, unfortunally), it's that PMs issued from one device of user@domain.com do not get replicated to other devices by domain.com, why?

But it doesn't seem worth the effort to me when we can also just fix MUC

ManDay, if you join the room from multiple devices, you wouldn't want to receive duplicates of each message

> It gets messy. We've done similar consolidation with SASL2/Bind2, and it simplifies implementations a lot. Simpler protocol and implementation leads to faster development and fewer bugs. I get it , yeah ↺

> ManDay, if you join the room from multiple devices, you wouldn't want to receive duplicates of each message Yeah that was the catch somewhere, because MUC does message duplication in itself, right? Which is historically designed that way because not every device may be joined in a MUC yaddayadda, right? ↺

Just why does MUC do the replication and not the user's server (as it is the case for 1:1 iirc)?

MUC doesn't - your server is supposed to

(goddamit if I could just find that debate and re-read it again :-/)

or, I'm misremembering

Here we go, here are the rules: https://xmpp.org/extensions/xep-0280.html#recommended-rules

So where again is the problem, device user@domain.com/A sends a PM, why does domain.com not carbon that to /B and /C, the other devices?

Ok, reading...

ah yes, that x... it's coming back to me now

So based on this, the MUC service is responsible for the copying, which it can only do if all your resources are joined to the room

yeah and iirc, that's the part that (I found) inconsistent, but let me catch up... I didn't actually read 280 yet

What happend to KISS 😐

ManDay: MUC PMs existed long before XEP-0280 did. Back then, 'sync all history to all devices' wasn't a thing yet. You'd usually see the current 1:1 conversation on the current device, and the next one on the next device. MUC was invented, and a requirement was to allow several devices to join the same room. If you did that and received a PM, MUC services just copied PMs to all joined devices.

ManDay: Now you keep looking at things from today's perspective, where 'sync all history everywhere' is a thing. From that perspective, you'd obviously design things differently, yes.

Ok my trouble with this is why the MUC would need any notion of multiple devices in the first place. When I try to "keep it simple" in my head, the absolute only entity which must know about "multiple devices" is the user's own server. Why does this reasoning not apply to MUC?

ManDay: And the MUC PM weirdness you mean is specifically due to the old logic not playing well with the new 'sync all history everywhere' idea.

Thank you Holger for that comprehensive explanation (again? 😅)

ManDay: Apart from all that I think MUC PMs have way more serious issues.

ManDay: From today's perspective that question makes sense, it's basically how MIX is designed. Back then, it seemed normal that only a subset of your devices was joined to a room, possibly only temporarily. The user's own server wouldn't easily be able to handle that.

All right, because only the MUC knew which devices where joined? I must say that even with the then-perspective in mind it doesn't seem to make sense to leak a notion of devices to other servers... But okay, that milk is spilled and recomposted by now, I guess.

Anyway, and thanks for making this clear so quickly, that is the inconsistency which I rememberd, MattJ (and I shall copy and backup our conversation just now, just in case...)

ManDay: "Leaking" that notion is core to the XMPP protocol. Unlike email, it allows for addressing individual devices as opposed to accounts. Which allows individual devices to perform service discovery on remote entities, querying room archives, and so on.

ManDay: Gajim supports receiving PMs as carbons, as well as fetching PMs from mam, though the messages you receive from others are sometimes duplicated two or three times (I guess this is the number of online clients at the time) I think client developers don't want to implement those features because they're probably a headache. But the current protocol works

(Message duplication is when fetching PM history from mam)

> ManDay: "Leaking" that notion is core to the XMPP protocol. Unlike email, it allows for addressing individual devices as opposed to accounts. Which allows individual devices to perform service discovery on remote entities, querying room archives, and so on. I see. It seems very strange to me. I would think that, as a communications protocol, the only concern would be addressing "someone" - and never "someone on a specific device". If only a specific device is involved in the communication, the server which "represents" that "someone" would deal with it. ↺

lissine Uhm the "though messages [...] are sometimes duplicated" doesn't actually sound like it works?

ManDay: We don't know whether it's a client bug or a problem with the spec. But you always get your PMs in Gajim (even if duplicated), unlike what you stated in the beginning about it being infeasible because of the protocol

ManDay: You could obviously redesign things to have the user server proxy outgoing requests of individual devices, which would add quite a bit of complexity for no obvious gain. Let alone incoming traffic to individual devices (like OMEMO negotiation or whatnot).

ManDay: But sure, making that part of the spec simpler / easier will result in more clients implementing it

ManDay: I mean yes the "someone" idea makes sense as long as we're only looking at actual IM text messages, given the 'sync everything everywhere' thing. But XMPP does way more than that.

> I see. It seems very strange to me. I would think that, as a communications protocol, the only concern would be addressing "someone" - and never "someone on a specific device". If only a specific device is involved in the communication, the server which "represents" that "someone" would deal with it. In XMPP, you can address devices because they can have different capabilities. They do not have to be a chat client. I had a client streaming music, when sending messages to it, connected under my own account. ↺

Yes, addressing a specific device is relevant when doing an audio / video call, or a P2P file transfer As for PMs, AFAIK they are sent to room@conference.example.org/nick And AFAIK you can join a room with multiple clients using the same nick That's how you get carbons with PMs ✏

lissine, challenge: find where it's defined that multiple clients can join with the same nick ;)

> lissine, challenge: find where it's defined that multiple clients can join with the same nick ;) It's possible or I got this wrong?

It's possible, but it's woefully under-specced, was the point.

I still haven't understood what goes wrong when I **send** a PM on /X and it doesn't show up on /Y - is that by design? Shouldn't it be a carbon going to Y?

Zash: it was pretty easy to find ;) > However, if the bare JID <localpart@domain.tld> of the present occupant matches the bare JID of the user seeking to enter the room, then the service SHOULD allow entry to the user, so that the user has two (or more) in-room "sessions" with the same roomnick, one for each resource. https://xmpp.org/extensions/xep-0045.html#enter-conflict

Now try to implement it on a server using only that information ;)

There's more in the paragraph: > If a service allows more than one occupant with the same bare JID and the same room nickname, it MUST route in-room messages to all of the user's resources and allow all of the user's resources to send messages to the room; it is up to the implementation whether to route private messages to all resources or only one resource (based on presence priority or some other algorithm); however, it is RECOMMENDED to route to all resources.

ManDay: you see this paragraph above? That RECOMMENDED (instead of REQUIRED / MUST) is probably why ✏

Does "route PMs" refer to routing PMs back to the user themself here?

A resource means a connected client

So if I send a PM with Movim to xsf@muc.xmpp.org/lissine and it doesn't show up on my Conversations, then I should complain to.... xmpp.org? Or monocles.eu (being my server)?

xmpp.org, I suppose?

> Now try to implement it on a server using only that information ;) Isn't the only "hard part" that iq effectively routes randomly? ↺

> > Now try to implement it on a server using only that information ;) > Isn't the only "hard part" that iq effectively routes randomly? Nick changes at least used to be underspecified, too.

(I did not actually mean to complain, just rhetorically speaking, of course)

What motivates the "RECOMMEND", though - it seems a mistake that the user can not rely on their message history being mirrored across all (joined) devices.

Around here it is commonly believed that RECOMMEND means must

But MUST means really really must 😉

MUC PMs go to MAM, so you can even get them without ever joining the room haha

Well it doesn't work for me though. ✏

I actually like that feature :p

But Gajim is the only client that I'm aware of that supports it

I'm strongly considering removing the ability to initiate or send arbitrary MUC PMs entirely

So you are saying if I send a PM in (say) Conversations and it doesn't show up in Movim it's most likely a client bug?

ManDay: wait a few minutes for me to test

Your own outgoing one not showing up you mean?

Yes singpolyma

yes its usually a client bug

That's just carbons. Nothing to do with MUC at all. So yeah, not sure either your server's carbon rules are not triggering for that or it's a client bug

but also all the PM rules are hard, so you most likely will see bugs in various clients

for example i see a ejabberd bug since a few months, it for some reason puts a pm under certain circumstances twice in the mam archive

> That's just carbons. Nothing to do with MUC at all. So yeah, not sure either your server's carbon rules are not triggering for that or it's a client bug Great, so it's a bug in either one of two clients or at my server... That's sounds like fun figuring out ↺

singpolyma it's *my* server though, not the MUC server, or could that also be?

> Great, so it's a bug in either one of two clients or at my server... That's sounds like fun figuring out ManDay, prosody + Gajim don't have this issue. So each time change a piece of your setup to figure out ↺

lissine prosody being MUC and server and two instances of Gajim, I take it?

I'm unfortunally not equipped to walk the entire combinatorics of MUC server, user server, client 1, client 2...

And to be very frank, god beware this happen to a non-techie - how would they possibly get this sorted out...

To be fair most users don't care MUC PMs

ManDay, A prosody account logged in on Gajim will receive PM carbons, regardless what is the other client I think it also doesn't matter if the MUC component is prosody or ejabberd. But test to be sure.

> To be fair most users don't care MUC PMs That's true ↺

> To be fair most users don't care MUC PMs Only those who use public channels do But you're right, that's a small percentage of the overall network ↺

Well... Unless they join a room which says "PM a moderator to ask for voice" :)

I have a prosody account logged in on Conversations and Movim - and neither direction (Movim -> C; C -> Movim) worked

Well okay, I'll figure it out. Thanks for looking into it in any case!

speaking of which, Daniel, maybe you should accept the 'request to speak' PRs to make PMs less important 😇️

> MUC PMs go to MAM, so you can even get them without ever joining the room haha singpolyma, shouldn't that be fixed with unique_occupant_ids, so that another person can't get your history simply by getting your nick? ↺

lissine: no they don't go to MUC mam. They go to *your* MAM

ManDay, Conversations and its forks don't handle carbons for private messages

understood, ty

hello.. is there a place/club/forum to test SIP/xmpp internet video/voice calls with people around the world?