-
pep.
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
-
pep.
https://wiki.xmpp.org/web/XEP-Remarks/XEP-0045:_Multi-User_Chat maybe this should be in here somewhere.
-
pep.
Also are new-ish MUC extensions/improvements referenced somewhere?
-
lovetox
whats a bare domain jid
-
lovetox
mucservice.com?
-
pep.
yeah
-
lovetox
so the whole component can only host a single room?
-
pep.
no, it would still be possible to create room@muc.service
-
lovetox
? why are you not continuing my example
-
lovetox
and use something totally different now
-
pep.
Is it really important?
-
lovetox
you mean room@mucservice.com?
-
pep.
Yes
-
lovetox
so a disco on mucservice.com returns all kind of things
-
Zash
not xmpp:muc.example?join ?
-
lovetox
its a muc component, but also a room
-
lovetox
but also hosts accounts
-
pep.
lovetox, why accounts
-
pep.
Basically I'm asking if the concept of "MUC component" is necessary
-
lovetox
How do you create a room if you dont know the jid of the muc component?
-
pep.
Well you know because you are given the adresse of one, either disco#items from the server, or some other user
-
lovetox
no disco items would not return anything anymore
-
pep.
Why not
-
lovetox
you just said "do we need the concept of a muc component"
-
lovetox
so you are questioning if this should exist
-
lovetox
if something does not exist anymore it cant be in disco info
-
pep.
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✎ -
pep.
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 ✏
-
lovetox
sie and that jid is called "component"
-
lovetox
so yes we need that
-
pep.
But that's the only thing one needs right?
-
pep.
If this jid is actually a room doesn't matter, does it
-
pep.
Because the client is likely to try to create foo@muc.service instead of just joining muc.service
-
Zash
pep., so are you talking about having rooms without nodepart or not?
-
lovetox
depends, last time we discussed this there is no way to differentiate between a room and a muc component
-
pep.
Zash, yeah
-
Zash
I find it very unclear what this is about
-
pep.
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
-
Zash
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"
-
pep.
lovetox, ok then I guess that's settles it?
-
pep.
Zash, hmm
-
lovetox
as i said there is no way to detect a component
-
lovetox
no client would join mucservice.com
-
lovetox
because you returned it in disco items as a component
-
lovetox
i cant join a component
-
lovetox
its not a room
-
pep.
lovetox, well that's just because they haven't been implemented to do so, doesn't mean it's not possible
-
pep.
(And actually poezio does)
-
lovetox
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"
-
lovetox
there is nothing wrong with room@group.service.com
-
lovetox
its clear for everyone, it separates concerns
-
Zash
what if you wanted to build a thing where you have user@host and #group@host ?
-
Zash
(like, say, irc transports)
-
pep.
Zash, please don't do that (differenciating by JID :p)
-
Zash
Biboumi already does, no?
-
pep.
No
-
pep.
Well, yes..
-
pep.
Yes
-
pep.
:(
-
pep.
But it's mapping IRc..✎ -
pep.
But it's mapping IRC.. ✏
-
Link Mauve
“15:41:14 lovetox> ? why are you not continuing my example”, perhaps because this is a porn website. :D
-
Zash
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.
-
Zash
"I only have this dyndns hostname and can't have subdomains" is something that comes up every now and then
-
pep.
So.. in summary, a client still needs a place that tells it "You can create rooms here"?
-
pep.
And that's about it?
-
pep.
It can also be a room though
-
pep.
It would have both roles
-
Zash
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
-
lovetox
yes, if your question is technical nature, yes its possible
-
pep.
Zash, I thought about that also yeah
-
Zash
Then we can get rid of the weirdo locking flow
-
Zash
(but we keep the regular flow ;))
-
pep.
(Yeah we like flow)
-
pep.
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
-
pep.
Because
-
Zash
http://jabber.org/protocol/muc + conference/text or somesuch?
-
pep.
Well yeah but a room would also have that right?
-
Zash
eh, rooms have that too
-
pep.
Ah and /list is also done on the component generally
-
pep.
Does disco#items on a room do anything?
-
pep.
It doesn't look like it
-
pep.
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?
-
MattJ
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
-
pep.
hmm
-
pep.
So this one feature would conflict?
-
Zash
Why would it?
-
Zash
Or, why would it not conflict as much as XMPP does with itself already?
-
Zash
You pretty much have to disco#info each item anyway to find out what it is
-
Zash
It could be commands, it could be rooms, it could be pubsub nodes, who knows‽
-
lovetox
but disco items on the component, lists rooms usually
-
pep.
What lovetox says. If a JID is both a room and a component, that is.. it's a room and it allows room creation
-
lovetox
pep., in general we should avoid any situation where a thing is 2 things at once in my opinion
-
lovetox
it only leads to trouble
-
pep.
lovetox, I agree. And it's sad that this one thing conflicts :/
-
lovetox
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
-
pep.
Are there any others things that would conflict?
-
lovetox
basically everything that you direct at the jid, needs then special handling by the server
-
lovetox
you would need fuse responses with results from both entities
-
lovetox
like adhoc commands for example, probably one of the easier things
-
lovetox
i cant imagine that any server can support this by default or?
-
pep.
can support what?
-
lovetox
room and component as the same jid
-
pep.
Prosody supports room creation on the bare domain jid
-
lovetox
i didnt say nobody supports it
-
lovetox
i said its not supported by default, you probably need to add special handling at many places to make it possible
-
pep.
In prosody, I don't think so no
-
nicoco_
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?
-
lovetox
how would you know? did you design the prosody architecture :D
-
pep.
lovetox, I haven't enabled anything in particular to be able to create the room.
-
pep.
nicoco_, probably one of the identities is used and not the other. Maybe the MUC identity is served first
-
pep.
A client would have to be able to deal with this combination of identities
-
nicoco_
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
-
pep.
Wait so it's possible to get a list of occupants with disco#items? Without running the 4 iqs? :P
-
pep.
Ah, presence not affiliations
-
nicoco_
Anyway it does not alter the functionality at, probably separating ‘MUC services’ from ‘gateways’ is ambiguous in the first place.
-
pep.
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.
-
pep.
And I'd rather have people join to get this kind of information
-
pep.
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.
-
flow
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
-
flow
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
-
flow
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
-
flow
if you don't write everything down, then you are doomed to forget it…
-
lovetox
im not sure the wiki should list whats technical possible, and rather list good practice
-
lovetox
Its good UX that users can see with one look, if a adress is a groupchat or not
-
lovetox
i dont see why anyone would actively take steps to prevent that
-
pep.
"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
-
pep.
And I would very much like not to restrict what a jid should look like either. I'd rather have clients disco
-
lovetox
of course you can
-
lovetox
gajim@conference.gajim.org
-
pep.
That could be a user
-
lovetox
see, one look you did it :)
-
pep.
And that could be a room
-
lovetox
pep., you gould be a GPT3 chatbot
-
lovetox
im still talking to you though
-
pep.
Be serious one second
-
lovetox
think about what argument you want to make
-
pep.
What are you trying to make me say
-
lovetox
mine is, everyone should choose descriptive subdomains so users can easily discover what things are
-
pep.
Yeah I disagree that things should be separated as "subdomains", I disagree that this should even be exposed to users anyway
-
pep.
Some know, (you, me), and that's fine
-
pep.
I think sticking to subdomains is slightly shortsighted
-
lovetox
how so?
-
lovetox
how was it shortsighted of the gajim server, to choose conference as its subdomains for MUCs for the last decade?
-
pep.
Joinjabber doesn't have a user host, and will certainly never have one, it's standalone
-
Link Mauve
lovetox, to most users, this is an email address.
-
Link Mauve
A weird one, since it doesn’t end with @gmail.com though.
-
lovetox
it is not, because if you go out of context, you need to attach schemes
-
lovetox
and because of great forsight, someone added xmpp:
-
Link Mauve
To most users, mailto: is a weird prefix they don’t understand at all.
-
pep.
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
-
Link Mauve
Don’t assume just because a JID has conference. in its domain, that users will understand it’s a MUC.
-
pep.
And you're proably going to disco it anyway because you need to
-
pep.
(for other reasons)
-
Link Mauve
pep., ?join is a good indicator, but not every URL producer manages to add it correctly.
-
lovetox
it does not matter if a client disco or not
-
pep.
Link Mauve, sure. I'm arguing for discoing really :)
-
lovetox
this is not about clients
-
Link Mauve
disco#info on the user-provided JID is the best you can do really.
-
lovetox
its about how you choose your domain
-
lovetox
and maybe we should not chose gajim.org
-
pep.
Who cares about the domains. Why would it matter to users
-
lovetox
because maybe behind gajim.org is in fact something different
-
pep.
(it's fun because I could see you make the exact same argument saying domains don't matter)
-
lovetox
yeah why not use IPs
-
Link Mauve
Ok, I’m out of this discussion.
-
pep.
No I meant, "since domains don't matter, why not to restrict them anyway". Is what I had in mind for you
-
pep.
But yeah I guess I'm also out
-
lovetox
ok haha im looking forward to your next domain
-
pep.
Really is it just UX that you're trying to improve with this?
-
pep.
If so I honestly don't understand
-
lovetox
with what? choosing a fitting domain name
-
lovetox
sorry are you for real?
-
pep.
hmm?
-
lovetox
are you arguing people should not choose fitting domain names anymore
-
lovetox
because we cant trust that befor we click on it, it really is what it says it is
-
pep.
We're not talking about the same thing are we
-
lovetox
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
-
lovetox
a muc service
-
lovetox
and then you tried to argue, we cant trust the name, so why name it
-
lovetox
as i was asking, im not sure where you want to go with that
-
lovetox
every sane person will name its muc service, group.domain.org
-
lovetox
conference.domain.org
-
pep.
Every sane person will know you disco a JID
-
lovetox
and it not a argument, that there exists a person out there, that doesnt know what a conference is
-
lovetox
pep., we are talking about UX for users
-
lovetox
not about clients and what they do
-
lovetox
a client is a computer program
-
lovetox
a domain name means NOTHING to a computer programm
-
lovetox
its a series of bytes
-
pep.
You're trying to much. I doubt your users ever care about this
-
pep.
I certainly wouldn't
-
pep.
I mean, I like it when it looks pretty
-
pep.
It doesn't have to look like a MUC jid because there is no such thing as a MUC jid
-
lovetox
i guess goole should not have used groups.google.com
-
lovetox
im sure people hate it that groups.google.com leads to google groups
-
pep.
Right, too bad it's a mailing list and not a MUC component
-
pep.
(Snikket named their MUC component groups.)
-
lovetox
oh no !
-
lovetox
its simple, if i have the chance to give something a name, i will, and thats the whole story
-
lovetox
you seem to have the opinion, no i want to hide that it even exists
-
pep.
Whether I want to or not, to know if a thing is a thing I need to disco it anyway
-
pep.
So there's that
-
lovetox
no pep. users dont disco anything
-
pep.
Users don't need to know what it is, they give it to their client
-
pep.
They can't use it without a client anyway
-
lovetox
ok, so i guess have fun with having your 10 components on the same domain
-
pep.
Did you not me see trying to list conflicting features earlier.
-
lovetox
tell me how it goes
-
pep.
To try and avoid it
-
lovetox
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
-
pep.
I say there's no need to restrict it arbitrarily if identities don't conflict, yeah
-
lovetox
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
-
pep.
Of course it's an arbitrary restriction. Why a sudomain, why not two. Why not only "muc." why not the "muc" tld
-
lovetox
i think we established that there is no restriction
-
pep.
No, you did on your own
-
lovetox
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
-
lovetox
this discussion feels like it
-
pep.
><
-
pep.
Seriously I should have stopped this chat 1h ago
-
pep.
It feels pointless
-
lovetox
ok then lets stop, i will watch TV now :)
-
lovetox
have a good night