pep.note that as I said this wouldn't happen if everybody was using <x/>
sonnyhas joined
goffihas joined
sonnyhas left
lovetoxhas left
lovetoxhas joined
Ge0rGpep.: 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
flowGe0rG, 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.
Ge0rGflow: it doesn't say you MUST NOT host a MUC on a non-MUC-Service
Ge0rGand biboumi is the opposite case, where you have non-MUC entities hosted on a MUC service
flowI 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
Ge0rGI 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
flowpep., 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
flowBut 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
flowThen what?
flowAn XMPP address can provide multiple services
flowThere 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?
flowNo
flowAnd 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
flowpep., what if the room does not exist?
flowIt'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
flowor even, "there is nothing at this address"
pep.yeah I'm fine with that tbh
sonnyhas joined
flowI 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
Ge0rGpep.: 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
KevFrom 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
lovetoxthats 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
lovetoxwhy would i need to care if it sometimes replies?
pep.sometimes?
lovetoxuser wants to join an address, i do a disco info
lovetox> (but something replies)
lovetoxyou just said that
pep.something* :)
lovetoxah something :d
Kevpep.: 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)
lovetoxi dont get the problem, from a disco info i can see if its a muc
lovetoxand 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
lovetoxsnd what reason is there to disco the service ?
KevI 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
lovetoxKev you cant request MUC History after join
Kevlovetox: 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
lovetoxyeah .. so the saved rountrip does not outweigh all the benefits you have from a disco info
lovetoxespecially because you need the disco info anyway at some point
Kevpep.: That's fair. In my world, constrained bandwidth also means (relatively) high latency.
lovetoxso you can just do it at the beginning
lovetoxdoing MUC on contraint bandwith is going to be shitty anyway
lovetoxyou basically join a chat, and you can not control in any way how many requests you get for stuff
lovetoxGajim still instantly querys your disco info if you join a MUC
lovetoxso if you join the Gajim channel on contraint bandwith, prepare to serv 100 disco info requests
KevThere are mechanisms you can use. Not least of which not deploying clients that flood new joiners.
KevBut if you assume that working across constrained networks the servers are trying to help, it's not as desperately bad as all that.