jdev - 2020-01-13

  1. flow

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

  2. pep.

    if it's a conference or not

  3. flow


  4. pep.

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

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

  6. Ge0rG looks at https://github.com/igniterealtime/Smack/blob/master/smack-extensions/src/main/java/org/jivesoftware/smackx/muc/MultiUserChat.java#L313-L320

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

  8. pep.

    where does the spec actually say that?

  9. flow

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

  10. Ge0rG

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

  11. Ge0rG

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

  12. flow

    I doubt that you can do that

  13. pep.

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

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

  15. 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 :)

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

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

  18. pep.

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

  19. pep.

    s/a bit/a lot/

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

  21. Ge0rG looks at the date of https://github.com/igniterealtime/Smack/pull/329/commits/6d96ae11c6bb251c92c3bb257997b9ceb08d3c9c , shrugs and moves on to important things

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

  23. flow

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

  24. pep.


  25. pep.

    What if I also have users on foo.bar

  26. flow

    Then what?

  27. flow

    An XMPP address can provide multiple services

  28. flow

    There is nothing wrong with that

  29. pep.

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

  30. pep.

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

  31. pep.

    Should I also advertize the muc service on the tld?

  32. flow


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

  34. pep.

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

  35. flow

    pep., what if the room does not exist?

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

  37. pep.

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

  38. flow

    or even, "there is nothing at this address"

  39. pep.

    yeah I'm fine with that tbh

  40. flow

    I am (obviously) not ;)

  41. pep.

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

  42. pep.

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

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

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

  45. pep.

    Ge0rG, hmm

  46. Kev

    (And feature)

  47. pep.

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

  48. lovetox

    thats why you disco a muc before you join

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

  50. pep.

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

  51. lovetox

    why would i need to care if it sometimes replies?

  52. pep.


  53. lovetox

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

  54. lovetox

    > (but something replies)

  55. lovetox

    you just said that

  56. pep.

    something* :)

  57. lovetox

    ah something :d

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

  59. lovetox

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

  60. lovetox

    and then join or dont

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

  62. pep.

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

  63. lovetox

    snd what reason is there to disco the service ?

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

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

  66. lovetox

    Kev you cant request MUC History after join

  67. Kev

    lovetox: That is certainly correct.

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

  69. lovetox

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

  70. lovetox

    especially because you need the disco info anyway at some point

  71. Kev

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

  72. lovetox

    so you can just do it at the beginning

  73. lovetox

    doing MUC on contraint bandwith is going to be shitty anyway

  74. lovetox

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

  75. lovetox

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

  76. lovetox

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

  77. Kev

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

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

  79. Kev

    That said, vanishing now.