XSF Discussion - 2023-05-24

Hello all! xep-0045 says that both a MUC and the "MUC service" should have identity conference/text and both advertise the muc feature. This feels wrong (since a MUC service neither implements MUC protocol, nor is a conference, nor really needs to technically exist and directory/chatroom exists) but more important for me how can I tell they difference? If I have the jid of a conference/text how can I know if it is joinable or not?

Probably not the answer you're hoping for, but: if there is a node part, it's joinable? :)

Yeah that feels weird to me too if both advertize it. That means implementations rely on other clues and that's where you get in awkward situations like checking that there's a .. node

;)

As author of an implementation which took steps to ensure the bare domain was joinable, I'm nevertheless happy enough for nobody to support it

Because it's just too much trouble

What kind of trouble?

Personally it's not that I want people to support that the bare domain is joinable, it's the other way around, I'd want them to stop enforcing arbitrary rules

Well, it's logically possible only when the operations you perform on the service don't overlap with the operations you can perform on the MUC

pep.: yeah. I kinda hate doing (if node) ever

and it happens that there very little overlap

MattJ: oh, you mean if the domain is also a service. Sure. But the domain could be just a room and not also a service

Then it's a room with no service

Sure

which is logically weird

Is it? The MUC services is basically a historical accident. It's sometimes useful but doesn't feel in any way required

I understand the fact that people want a place ""under which"" they know they can create a new room. But it's the "under which" that annoys me. Why not just ask for a new room to any room of the service one knows and be done? (as an example)

(There may be other ways)

IIRC there are some operations in XEP-0045 defined on the service, such as registration

Registration against the service?

Service-wide nick registration, for example

search maybe?

#items also yeah maybe

Right, so that's why the service advertises muc, because it optionally implements some muc features

With all the edge cases it exposes, I just can't support the idea that it's worth it

pep.: Items is more like directory/chatroom though

The spec could be made clearer in one way or another in this regard (advertizing "muc" everywhere). I guess it's an implicit assumption that there's a node for a room

I guess also because of the long history here we can't remove the identity because even if it's wrong too many things would have it. But nothing prevents us suggesting a second identity also be present (either in there service or the muc or both)

I will use (if node) for now I guess, but under protest :P

Your protest has been noted :P

I'm writing a MUC implementation, and I also protest!!

I just protest!

pep.: right. A muc#service var could also do it. But I think this is the job identity is for

pep.: if you're actually working on this, I would submit that the muc service should be identity conference/text *and* directory/chatroom (the former only for historical reasons as noted)

fwiw I've been close to finishing my scansion impl in Rust, which allows me to do test codegen for my MUC service. Hoping that this helps other MUC (service) impls

I need to take some time and finish it

And then start writing tests.

vote flow for a stricter and tightener ruleset for MUC (and all other protocols)!!111

hah

"The XMPP address (JID) of a MUC room MUST consist of a local-, domain-, and resourcepart."

What can actually be done from a XEP pov? I imagine editing MUC at all is basically verboten except wording changes? So would it have to be a new xep just to suggest a second identity for muc services?

flow, :/

pep., I never said my opinions and belives are generally shared :)

singpolyma, MUC is being edited all the time

singpolyma: can a room be expected to at least contain _some_ disco#info features that are specific to a room (which won't be returned by a service's #info?).

Guus: I will review the spec again, but I don't think any are required

wait, strike the "and resourcepart" in what I wrote above

Still :/

:P

singpolyma: it's not better than checking if there's a node-part, but maybe you can differentiate between 'room' and 'service' by checking for a non-zero amount of `muc_*` features.

flow, there's literally no reason apart from "it's easier" to enforce the node

Guus: if any we're required to be present it would be way better. As it is maybe I can do (if node or (contains muc_*))

pep., yeah, yeah, I know. I hope we still can have a beverage at an future fosdem even if we have different opinions ;)

And get to 98%

flow, as long as you don't bring me MIX stickers :P

pep., I truely believe that the ability to host MUC rooms on domainpart-only XMPP addresses only causes confusion and makes implementation harder

that'd get you to only 98% you think?

Wait, that's it! MIX needs Stickers, otherwise it will never become popular!!!1

flow: agreed

Actual physical stickers, that is ;)

Guus: well, in practise (if node) is probably 99.9% haha

:DD

war of the MUC vs MIX (stickers) incoming?

Vote with your stickers

and your sticker printing equipment!

pep: `is node` can be deduced from the room's address, and doesn't require a disco?

Guus, "if node" and "if other feature" are somewhat equivalent IMO. As you'll disco anyway ✏

Yeah but you can't know if node@server is a MUC or a person or something else

So you need to disco

BTW, maybe this is better for jdev, but is anyone else aware of clients that try to detect MUC generally vs having the user declare what is a MUC and what is not? I observed today the XEP even says presence sub to MUC is allowed, but in most clients MUC in roster is a UX disaster

oh, I'm definitely not arguing that this is a good idea. I was just trying to find a way in which you could distinguish between service and room based on disco#info data.

Guus: yeah, I'm not sure it is perfect but I will definitely add your idea to what I am doing

We _could_ improve the specs, but what's the cost/benefit ratio?

^

Well, improving the specs means the next person who wants to do this has something telling them what to do ✏

I am willing to come in here and be like "uhhh..." But GP doesn't love that mode of finding out usually

isn't that quite clear? It's awkward maybe, but it's pretty evident that the XEP assumes that rooms are node-based JIDs under a domain-only service address.

Clarifying is good

Guus: I think this discussion is an existence proof it's not clear. I have a published client in the wild now that tries to join MUC services, heh

+1, I'd rather update XEP-0045 to state what is common (universal) practice explicitly, over trying to change the protocol to satisfy theoretical use cases

MattJ: you mean just say MUST node?

(fwiw: I wasn't arguing against clarifying the XEP - but I do wonder if there's much benefit in introducing something like a new feature to make the disction between room and service more distinct)

singpolyma, yep

I don't love that, but if it's in the spec then (if node) stops being a hack ✏

So I prefer it to nothing

Room JID The <room@service> address of a room.

This is from XEP-0045 currently

Could add more words, but it doesn't seem that ambiguous

> Room ID > The localpart of a Room JID, which might be opaque and thus lack meaning for human users

also in the XEP currently.

> Each room is identified as a "room JID" <room@service> (e.g., <jdev@conference.jabber.org>), where "room" is the name of the room and "service" is the hostname at which the multi-user chat service is running.

Hmm. Ok, you win.

Could the problem be the that the XEP is simply so large that you can't possibly read the whole thing at once, thus you miss bits?

> BTW, maybe this is better for jdev, but is anyone else aware of clients that try to detect MUC generally Gajim does. afair, the internal "open chat" API is even agnostic to the jid being a muc or not

I guess so many xmpp things assume node when they shouldn't that it's easy for me to miss is such statements are requirements, but the weight is there

(or did those quoted parts appear just now?)

Zash, want me to find another bit of XEP-0045 you've never seen before? :)

Zash: that's probably true for many XEPs - many specifications in general even, maybe.

mjk: oh yeah? Nice. I haven't tried gajim past 1.3 yet but glad to hear newer versions also doing this

Mattj: as someone who has direct write access to the webserver that hosts them, one might suspect foul play!

> Could the problem be the that the XEP is simply so large that you can't possibly read the whole thing at once, thus you miss bits? everytime i look at a xep, i have to go lay down for bit. just saying.

Most xeps are very small and easy to digest, but there are a few famous exceptions of course. 45, 60

Both could be broken up but 🤷‍♂️

Breaking them up isn't a magic bullet either...

Zash: no, but it could make for example a partial implemetation much easier to reason about

But reorganization in general can probably help, if done well.

I don't think it's worth it for historical xeps like this, we can write seperate docs if needed etc. But new xeps being more broken down I think is good and that does seem to be the trend ✏

Ultimately I'd like to get to the point where lots of people do productive xmpp work without even reading a xep. Not because reading specs is bad but because many people won't

But that's a different goal, heh

singpolyma: > I haven't tried gajim past 1.3 yet you might find out it's now _more_ broken wrt to calls :(

somewhere around libsoup 2->3 transition, iirc

one might ask what has http to do with rtp. one would be correct in asking ✏

> singpolyma: >> I haven't tried gajim past 1.3 yet > you might find out it's now _more_ broken wrt to calls :( Yes, I'm aware of that. Though I think it got slightly unbroken again? Not sure. Anyway, I don't do calls myself but of course I need to be aware of these things for customers ↺

👍

> > you might find out it's now _more_ broken wrt to calls :( > Yes, I'm aware of that. Though I think it got slightly unbroken again? Not sure. Anyway, I don't do calls myself but of course I need to be aware of these things for customers the jingle parts suffer from severe bit rot. at some point this needs to be rewritten (same for jingle ft)

GSoC rewrite from scratch? :)

I know Gajim participated in earlier years, but it seems the effort which goes into mentoring does not pay off