jdev - 2020-01-13

pep., looking for what in that disco#info?

if it's a conference or not

ahh

note that as I said this wouldn't happen if everybody was using <x/>

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

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.

where does the spec actually say that?

pep., https://xmpp.org/extensions/xep-0045.html#disco-service-features

flow: it doesn't say you MUST NOT host a MUC on a non-MUC-Service

and biboumi is the opposite case, where you have non-MUC entities hosted on a MUC service

I doubt that you can do that

"MUC service's JID", is that defined anywhere else

"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?

flow, I think this is pretty workaround-able tbh, I'm sure Smacks could be a bit more loose than this in this regard :)

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

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

Ge0rG, that's maybe a shortcoming of your client. (I'd like poezio to be a bit smarter in this regard)

s/a bit/a lot/

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

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.

But then again if you have chat@foo.bar, then please announce that in the disco#info response of foo.bar

why?

What if I also have users on foo.bar

Then what?

An XMPP address can provide multiple services

There is nothing wrong with that

Do we have an identity that says "this is a user host"?

flow, what about "foo.bar" as my room?

Should I also advertize the muc service on the tld?

No

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

Well the room itself announces that it's a MUC room

pep., what if the room does not exist?

It's: Hey the domainpart of the address you gave me, does not even provide MUC, vs. there is no MUC at this address

Then it does not exist.. like any other entity that doesn't exist

or even, "there is nothing at this address"

yeah I'm fine with that tbh

I am (obviously) not ;)

You can't find anything at this address and that's it

The user gives you garbage you're not going to deduce stuff from that garbage

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

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.

Ge0rG, hmm

(And feature)

Kev, does it say explicitely that the service hosting MUCs and the MUC (singular) have to be at different addresses

thats why you disco a muc before you join

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.

If the disco returns "doesn't exist" (but something replies), then you can try to join anyway and see what error you get

why would i need to care if it sometimes replies?

sometimes?

user wants to join an address, i do a disco info

> (but something replies)

you just said that

something* :)

ah something :d

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)

i dont get the problem, from a disco info i can see if its a muc

and then join or dont

> 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.

Kev, you need to disco#info before joining nowadays with MAM

snd what reason is there to disco the service ?

I don't believe that to be true - we implement MAM on MUCs in the server, and joining them without a disco works fine.

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

Kev you cant request MUC History after join

lovetox: That is certainly correct.

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

yeah .. so the saved rountrip does not outweigh all the benefits you have from a disco info

especially because you need the disco info anyway at some point

pep.: That's fair. In my world, constrained bandwidth also means (relatively) high latency.

so you can just do it at the beginning

doing MUC on contraint bandwith is going to be shitty anyway

you basically join a chat, and you can not control in any way how many requests you get for stuff

Gajim still instantly querys your disco info if you join a MUC

so if you join the Gajim channel on contraint bandwith, prepare to serv 100 disco info requests

There are mechanisms you can use. Not least of which not deploying clients that flood new joiners.

But if you assume that working across constrained networks the servers are trying to help, it's not as desperately bad as all that.

That said, vanishing now.