note that as I said this wouldn't happen if everybody was using <x/>
sonnyhas joined
goffihas joined
sonnyhas left
lovetoxhas left
lovetoxhas joined
Ge0rG
pep.: it wasn't done because you can more easily cache disco#info of the domain, as opposed to the bare JID, and in sane setups, MUCs are hosted on a MUC domain, and nothing else is
Ge0rGlooks at https://github.com/igniterealtime/Smack/blob/master/smack-extensions/src/main/java/org/jivesoftware/smackx/muc/MultiUserChat.java#L313-L320
flow
Ge0rG, that doesn't say that "nothing else is". It just just says that if foo@bar.org returns muc as disco#info response, then bar.org must do so to. Just as the spec states it.
flow: it doesn't say you MUST NOT host a MUC on a non-MUC-Service
Ge0rG
and biboumi is the opposite case, where you have non-MUC entities hosted on a MUC service
flow
I doubt that you can do that
pep.
"MUC service's JID", is that defined anywhere else
pep.
"An entity often discovers a MUC service by sending a Service Discovery items ("disco#items") request to its own server.", so anything that appears in disco#items declaring itself as a MUC service (with the identity?) is a MUC Service?
pep.
flow, I think this is pretty workaround-able tbh, I'm sure Smacks could be a bit more loose than this in this regard :)
pep.
The idea of using chat@foo.bar also occured to me, it does look a lot better than chat@chat.foo.bar, or foo@chat.foo.bar
Ge0rG
I actually think that calling it `chat@foo.bar` is bad and it should be `foo@foo.bar` so that you can tab-complete it
pep.
Ge0rG, that's maybe a shortcoming of your client. (I'd like poezio to be a bit smarter in this regard)
pep.
s/a bit/a lot/
pep.
But the issue in poezio is that I don't currently have any way to show suggestions, and so it has to stay deterministic, so it's hard to come up with suggestions like this that change depending on $foo
Ge0rGlooks at the date of https://github.com/igniterealtime/Smack/pull/329/commits/6d96ae11c6bb251c92c3bb257997b9ceb08d3c9c , shrugs and moves on to important things
sonnyhas joined
flow
pep., I think it is great to have chat@foo.bar, we do not need a subdomain for most services. For some it is sensible, for others may not. Subdomains is that makes XMPP service configuration more complicated as you probably need additional TLS certs. A good example which does not strictly have to be a subdomain is http upload.
sonnyhas left
flow
But then again if you have chat@foo.bar, then please announce that in the disco#info response of foo.bar
pep.
why?
pep.
What if I also have users on foo.bar
flow
Then what?
flow
An XMPP address can provide multiple services
flow
There is nothing wrong with that
pep.
Do we have an identity that says "this is a user host"?
pep.
flow, what about "foo.bar" as my room?
pep.
Should I also advertize the muc service on the tld?
flow
No
flow
And regarding the question 'why': The code in Smack is there for a reasons. I found many users over the years struggling with where to put which xmpp address. If entities announce the services they provide, then I can provide the library user with better error messages explaining what is likely gone wrong
pep.
Well the room itself announces that it's a MUC room
flow
pep., what if the room does not exist?
flow
It's: Hey the domainpart of the address you gave me, does not even provide MUC, vs. there is no MUC at this address
pep.
Then it does not exist.. like any other entity that doesn't exist
flow
or even, "there is nothing at this address"
pep.
yeah I'm fine with that tbh
sonnyhas joined
flow
I am (obviously) not ;)
pep.
You can't find anything at this address and that's it
pep.
The user gives you garbage you're not going to deduce stuff from that garbage
sonnyhas left
Zashhas left
sonnyhas joined
Ge0rG
pep.: Speaking of which, if you try to enter a non-existing MUC, you won't get a disco#info on that MUC JID telling you that it's a MUC
Kev
From my reading of '45, a service hosting MUCs is a MUC service, and a MUC service has to have an identity that says so.
pep.
Ge0rG, hmm
Kev
(And feature)
Zashhas joined
pep.
Kev, does it say explicitely that the service hosting MUCs and the MUC (singular) have to be at different addresses
lovetox
thats why you disco a muc before you join
pep.
Ge0rG, though, arguably, there is an intent behind joining a MUC, either started by the user or you the client. So there are things you can assume.
pep.
If the disco returns "doesn't exist" (but something replies), then you can try to join anyway and see what error you get
lovetox
why would i need to care if it sometimes replies?
pep.
sometimes?
lovetox
user wants to join an address, i do a disco info
lovetox
> (but something replies)
lovetox
you just said that
pep.
something* :)
lovetox
ah something :d
Kev
pep.: A service is a domain, rather than JID-with-localpart in this context (6120 talks about services rather than domains, I think pretty much exclusively)
lovetox
i dont get the problem, from a disco info i can see if its a muc
lovetox
and then join or dont
Kev
> lovetox
> thats why you disco a muc before you join
There's lots of cases that won't be a bad idea, but if you're working on constrained bandwidth, blocking a join on an extra round trip wouldn't be good.
pep.
Kev, you need to disco#info before joining nowadays with MAM
lovetox
snd what reason is there to disco the service ?
Kev
I don't believe that to be true - we implement MAM on MUCs in the server, and joining them without a disco works fine.
pep.
Or you just do MAM anyway, you also request legacy history, and then you do deduplication, but that's also quite a waste of bandwidth
lovetox
Kev you cant request MUC History after join
Kev
lovetox: That is certainly correct.
pep.
So if you talk about constrained bandwidth you certainly need that disco. If you talk about latency, I can see why you'd request both instead of doing the disco first
lovetox
yeah .. so the saved rountrip does not outweigh all the benefits you have from a disco info
lovetox
especially because you need the disco info anyway at some point
Kev
pep.: That's fair. In my world, constrained bandwidth also means (relatively) high latency.
lovetox
so you can just do it at the beginning
lovetox
doing MUC on contraint bandwith is going to be shitty anyway
lovetox
you basically join a chat, and you can not control in any way how many requests you get for stuff
lovetox
Gajim still instantly querys your disco info if you join a MUC
lovetox
so if you join the Gajim channel on contraint bandwith, prepare to serv 100 disco info requests
Kev
There are mechanisms you can use. Not least of which not deploying clients that flood new joiners.
Kev
But if you assume that working across constrained networks the servers are trying to help, it's not as desperately bad as all that.