jdev - 2022-12-17

Old question: is there any concrete reason why a MUC component shouldn't host a room on a bare domain jid? Apart from historical reasons / "it's more or less like this in the spec" etc.? Maybe there are resources on this? it's definitely not the first time this is asked

https://wiki.xmpp.org/web/XEP-Remarks/XEP-0045:_Multi-User_Chat maybe this should be in here somewhere.

Also are new-ish MUC extensions/improvements referenced somewhere?

whats a bare domain jid

mucservice.com?

yeah

so the whole component can only host a single room?

no, it would still be possible to create room@muc.service

? why are you not continuing my example

and use something totally different now

Is it really important?

you mean room@mucservice.com?

Yes

so a disco on mucservice.com returns all kind of things

not xmpp:muc.example?join ?

its a muc component, but also a room

but also hosts accounts

lovetox, why accounts

Basically I'm asking if the concept of "MUC component" is necessary

How do you create a room if you dont know the jid of the muc component?

Well you know because you are given the adresse of one, either disco#items from the server, or some other user

no disco items would not return anything anymore

Why not

you just said "do we need the concept of a muc component"

so you are questioning if this should exist

if something does not exist anymore it cant be in disco info

Well clients still need something they know they can create rooms out of, so yeah I'm still doing to give them a JID to do so from ✏

sie and that jid is called "component"

so yes we need that

But that's the only thing one needs right?

If this jid is actually a room doesn't matter, does it

Because the client is likely to try to create foo@muc.service instead of just joining muc.service

pep., so are you talking about having rooms without nodepart or not?

depends, last time we discussed this there is no way to differentiate between a room and a muc component

Zash, yeah

I find it very unclear what this is about

I'm wondering if I should make a different in my component project at all between the jid without nodepart and others.. It does look like a pointless distinction from the component PoV

There ought to be a disco#info thing that means "I am a room" and a different disco#info thing that means "I allow creating rooms"

lovetox, ok then I guess that's settles it?

Zash, hmm

as i said there is no way to detect a component

no client would join mucservice.com

because you returned it in disco items as a component

i cant join a component

its not a room

lovetox, well that's just because they haven't been implemented to do so, doesn't mean it's not possible

(And actually poezio does)

yeah you can do anything, the question is, is there a reason beyond "hey im a special snowflake and i want to create rooms that half of the clients cant join"

there is nothing wrong with room@group.service.com

its clear for everyone, it separates concerns

what if you wanted to build a thing where you have user@host and #group@host ?

(like, say, irc transports)

Zash, please don't do that (differenciating by JID :p)

Biboumi already does, no?

No

Well, yes..

Yes

:(

But it's mapping IRC.. ✏

“15:41:14 lovetox> ? why are you not continuing my example”, perhaps because this is a porn website. :D

Doesn't have to encode into JID, could have the server keep track of whether a thing is a user or room. Maybe even both? But best not.

"I only have this dyndns hostname and can't have subdomains" is something that comes up every now and then

So.. in summary, a client still needs a place that tells it "You can create rooms here"?

And that's about it?

It can also be a room though

It would have both roles

Maybe we get rid of that entirely and move to an iq stanza directed at something advertising the corresponding feature, with the room JID returned in the result

yes, if your question is technical nature, yes its possible

Zash, I thought about that also yeah

Then we can get rid of the weirdo locking flow

(but we keep the regular flow ;))

(Yeah we like flow)

0045 doesn't have this thing that says "you can create rooms here" right? It's generally assumed that one can do so on a bare domain JID

Because

http://jabber.org/protocol/muc + conference/text or somesuch?

Well yeah but a room would also have that right?

eh, rooms have that too

Ah and /list is also done on the component generally

Does disco#items on a room do anything?

It doesn't look like it

lovetox, Zash, https://wiki.xmpp.org/web/index.php?title=XEP-Remarks%2FXEP-0045%3A_Multi-User_Chat&type=revision&diff=14249&oldid=13072 does this look correct? Any comment?

pep. [15:28]: > Does disco#items on a room do anything? It is supposed to list occupants, but most servers/rooms disabled it for privacy

hmm

So this one feature would conflict?

Why would it?

Or, why would it not conflict as much as XMPP does with itself already?

You pretty much have to disco#info each item anyway to find out what it is

It could be commands, it could be rooms, it could be pubsub nodes, who knows‽

but disco items on the component, lists rooms usually

What lovetox says. If a JID is both a room and a component, that is.. it's a room and it allows room creation

pep., in general we should avoid any situation where a thing is 2 things at once in my opinion

it only leads to trouble

lovetox, I agree. And it's sad that this one thing conflicts :/

xmpp has often the problem that without disco info you cant know what a thing is, adding now on top that even if you disco, it is multiple things at once is a new kind of bad

Are there any others things that would conflict?

basically everything that you direct at the jid, needs then special handling by the server

you would need fuse responses with results from both entities

like adhoc commands for example, probably one of the easier things

i cant imagine that any server can support this by default or?

can support what?

room and component as the same jid

Prosody supports room creation on the bare domain jid

i didnt say nobody supports it

i said its not supported by default, you probably need to add special handling at many places to make it possible

In prosody, I don't think so no

Speaking of a thing being two things at once, now that I do MUCs in slidge, gajim lists them under ‘rooms’ and not ‘gateways’ anymore. Is it just a UI thing, or is there anything wrong with a component having both a gateway and a muc service identity?

how would you know? did you design the prosody architecture :D

lovetox, I haven't enabled anything in particular to be able to create the room.

nicoco_, probably one of the identities is used and not the other. Maybe the MUC identity is served first

A client would have to be able to deal with this combination of identities

Biboumi is also in Rooms - which makes more sense because it’s mostly rooms and also it does not require any ‘subscription to the component’ AFAIK

Wait so it's possible to get a list of occupants with disco#items? Without running the 4 iqs? :P

Ah, presence not affiliations

Anyway it does not alter the functionality at, probably separating ‘MUC services’ from ‘gateways’ is ambiguous in the first place.

I guess I'm personally willing to dismiss this one feature (getting an occupant list via disco#items, especially if most servers don't do it) as it's possible to get this list by joining.

And I'd rather have people join to get this kind of information

https://wiki.xmpp.org/web/XEP-Remarks/XEP-0045:_Multi-User_Chat#Why_do_I_need_to_host_my_MUC_component_on_subdomain.example.org%3F ok then, I updated it. It's weird mix of two different but related things I feel, but I think most info is there.

personally I believe that MUC JIDs should always consists of a localpart and a domainpart and no resourcepart. and that a MUC service domainpart should not also be a domainpart that hosts ordinary users

the motivation for the first constrain is that it makes it easy for clients to validate that the entered string is in fact probably a valid MUC address, leading to better UX

and I had a technical reason, not just a philosopical one like "separation of concerns" for the second constraint. Yes I know that it is technical possible to do that, but it IIRC caused me some other technical trouble

if you don't write everything down, then you are doomed to forget it…

im not sure the wiki should list whats technical possible, and rather list good practice

Its good UX that users can see with one look, if a adress is a groupchat or not

i dont see why anyone would actively take steps to prevent that

"Its good UX that users can see with one look, if a adress is a groupchat or not" you can't do that "in one look". You need to disco it anyway, it could be a user account otherwise

And I would very much like not to restrict what a jid should look like either. I'd rather have clients disco

of course you can

gajim@conference.gajim.org

That could be a user

see, one look you did it :)

And that could be a room

pep., you gould be a GPT3 chatbot

im still talking to you though

Be serious one second

think about what argument you want to make

What are you trying to make me say

mine is, everyone should choose descriptive subdomains so users can easily discover what things are

Yeah I disagree that things should be separated as "subdomains", I disagree that this should even be exposed to users anyway

Some know, (you, me), and that's fine

I think sticking to subdomains is slightly shortsighted

how so?

how was it shortsighted of the gajim server, to choose conference as its subdomains for MUCs for the last decade?

Joinjabber doesn't have a user host, and will certainly never have one, it's standalone

lovetox, to most users, this is an email address.

A weird one, since it doesn’t end with @gmail.com though.

it is not, because if you go out of context, you need to attach schemes

and because of great forsight, someone added xmpp:

To most users, mailto: is a weird prefix they don’t understand at all.

Well then if you trust the source you got the address from, xmpp:?join tells you it's a room. What more do you need

Don’t assume just because a JID has conference. in its domain, that users will understand it’s a MUC.

And you're proably going to disco it anyway because you need to

(for other reasons)

pep., ?join is a good indicator, but not every URL producer manages to add it correctly.

it does not matter if a client disco or not

Link Mauve, sure. I'm arguing for discoing really :)

this is not about clients

disco#info on the user-provided JID is the best you can do really.

its about how you choose your domain

and maybe we should not chose gajim.org

Who cares about the domains. Why would it matter to users

because maybe behind gajim.org is in fact something different

(it's fun because I could see you make the exact same argument saying domains don't matter)

yeah why not use IPs

Ok, I’m out of this discussion.

No I meant, "since domains don't matter, why not to restrict them anyway". Is what I had in mind for you

But yeah I guess I'm also out

ok haha im looking forward to your next domain

Really is it just UX that you're trying to improve with this?

If so I honestly don't understand

with what? choosing a fitting domain name

sorry are you for real?

hmm?

are you arguing people should not choose fitting domain names anymore

because we cant trust that befor we click on it, it really is what it says it is

We're not talking about the same thing are we

yes, we are, half of the day you try asking why and how its technical possible to NOT name your component domain after what it is

a muc service

and then you tried to argue, we cant trust the name, so why name it

as i was asking, im not sure where you want to go with that

every sane person will name its muc service, group.domain.org

conference.domain.org

Every sane person will know you disco a JID

and it not a argument, that there exists a person out there, that doesnt know what a conference is

pep., we are talking about UX for users

not about clients and what they do

a client is a computer program

a domain name means NOTHING to a computer programm

its a series of bytes

You're trying to much. I doubt your users ever care about this

I certainly wouldn't

I mean, I like it when it looks pretty

It doesn't have to look like a MUC jid because there is no such thing as a MUC jid

i guess goole should not have used groups.google.com

im sure people hate it that groups.google.com leads to google groups

Right, too bad it's a mailing list and not a MUC component

(Snikket named their MUC component groups.)

oh no !

its simple, if i have the chance to give something a name, i will, and thats the whole story

you seem to have the opinion, no i want to hide that it even exists

Whether I want to or not, to know if a thing is a thing I need to disco it anyway

So there's that

no pep. users dont disco anything

Users don't need to know what it is, they give it to their client

They can't use it without a client anyway

ok, so i guess have fun with having your 10 components on the same domain

Did you not me see trying to list conflicting features earlier.

tell me how it goes

To try and avoid it

ok, so you can give something a name, but rather then just giving it the name what it is, you say, wait i dont want to name it, i rather think a few hours how not nameing it can lead to problems

I say there's no need to restrict it arbitrarily if identities don't conflict, yeah

nobody restricts anything, everyone is just pratical, we can give it a name, it has only benefits if something is named after what it is, just name it and everything is good

Of course it's an arbitrary restriction. Why a sudomain, why not two. Why not only "muc." why not the "muc" tld

i think we established that there is no restriction

No, you did on your own

nobody restricts you to jump of a bridge, but i guess you will not do it because its not very practial for your future plans

this discussion feels like it

><

Seriously I should have stopped this chat 1h ago

It feels pointless

ok then lets stop, i will watch TV now :)

have a good night