jdev - 2020-01-13


  1. aj has joined

  2. aj has left

  3. sonny has left

  4. debacle has left

  5. sonny has joined

  6. strar has left

  7. strar has joined

  8. sonny has left

  9. sonny has joined

  10. allie has left

  11. allie has joined

  12. paul has joined

  13. asterix has joined

  14. lovetox has joined

  15. lovetox has left

  16. asterix has left

  17. asterix has joined

  18. wurstsalat has joined

  19. asterix has left

  20. asterix has joined

  21. asterix has left

  22. asterix has joined

  23. asterix has left

  24. asterix has joined

  25. lovetox has joined

  26. asterix has left

  27. asterix has joined

  28. asterix has left

  29. asterix has joined

  30. sonny has left

  31. flow

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

  32. pep.

    if it's a conference or not

  33. flow

    ahh

  34. pep.

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

  35. sonny has joined

  36. goffi has joined

  37. sonny has left

  38. lovetox has left

  39. lovetox has joined

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

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

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

  43. pep.

    where does the spec actually say that?

  44. flow

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

  45. Ge0rG

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

  46. Ge0rG

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

  47. flow

    I doubt that you can do that

  48. pep.

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

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

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

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

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

  53. pep.

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

  54. pep.

    s/a bit/a lot/

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

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

  57. sonny has joined

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

  59. sonny has left

  60. flow

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

  61. pep.

    why?

  62. pep.

    What if I also have users on foo.bar

  63. flow

    Then what?

  64. flow

    An XMPP address can provide multiple services

  65. flow

    There is nothing wrong with that

  66. pep.

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

  67. pep.

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

  68. pep.

    Should I also advertize the muc service on the tld?

  69. flow

    No

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

  71. pep.

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

  72. flow

    pep., what if the room does not exist?

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

  74. pep.

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

  75. flow

    or even, "there is nothing at this address"

  76. pep.

    yeah I'm fine with that tbh

  77. sonny has joined

  78. flow

    I am (obviously) not ;)

  79. pep.

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

  80. pep.

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

  81. sonny has left

  82. Zash has left

  83. sonny has joined

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

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

  86. pep.

    Ge0rG, hmm

  87. Kev

    (And feature)

  88. Zash has joined

  89. pep.

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

  90. lovetox

    thats why you disco a muc before you join

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

  92. pep.

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

  93. lovetox

    why would i need to care if it sometimes replies?

  94. pep.

    sometimes?

  95. lovetox

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

  96. lovetox

    > (but something replies)

  97. lovetox

    you just said that

  98. pep.

    something* :)

  99. lovetox

    ah something :d

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

  101. lovetox

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

  102. lovetox

    and then join or dont

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

  104. pep.

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

  105. lovetox

    snd what reason is there to disco the service ?

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

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

  108. lovetox

    Kev you cant request MUC History after join

  109. Kev

    lovetox: That is certainly correct.

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

  111. lovetox

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

  112. lovetox

    especially because you need the disco info anyway at some point

  113. Kev

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

  114. lovetox

    so you can just do it at the beginning

  115. lovetox

    doing MUC on contraint bandwith is going to be shitty anyway

  116. lovetox

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

  117. lovetox

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

  118. lovetox

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

  119. Kev

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

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

  121. Kev

    That said, vanishing now.

  122. pulkomandy has left

  123. pulkomandy has joined

  124. allie has left

  125. allie has joined

  126. aj has joined

  127. pulkomandy has left

  128. pulkomandy has joined

  129. Alex has left

  130. Alex has joined

  131. pulkomandy has left

  132. pulkomandy has joined

  133. pulkomandy has left

  134. aj has left

  135. larma has left

  136. debacle has joined

  137. larma has joined

  138. pulkomandy has joined

  139. sonny has left

  140. Wojtek has joined

  141. debacle has left

  142. sonny has joined

  143. pulkomandy has left

  144. sonny has left

  145. debacle has joined

  146. skyfar has left

  147. lovetox has left

  148. sonny has joined

  149. Tao has joined

  150. lovetox has joined

  151. Tao has left

  152. sonny has left

  153. lovetox has left

  154. lovetox has joined

  155. pulkomandy has joined

  156. sonny has joined

  157. sonny has left

  158. lovetox has left

  159. Bartek has joined

  160. sonny has joined

  161. Bartek has left

  162. sonny has left

  163. lovetox has joined

  164. pulkomandy has left

  165. pulkomandy has joined

  166. Bartek has joined

  167. sonny has joined

  168. Bartek has left

  169. Bartek has joined

  170. sonny has left

  171. kol has joined

  172. sonny has joined

  173. Bartek has left

  174. Tao has joined

  175. sonny has left

  176. Tao has left

  177. Wojtek has left

  178. Wojtek has joined

  179. sonny has joined

  180. sonny has left

  181. sonny has joined

  182. pulkomandy has left

  183. pulkomandy has joined

  184. pulkomandy has left

  185. pulkomandy has joined

  186. pulkomandy has left

  187. pulkomandy has joined

  188. pulkomandy has left

  189. pulkomandy has joined

  190. sonny has left

  191. lovetox has left

  192. asterix has left

  193. asterix has joined

  194. Bartek has joined

  195. sonny has joined

  196. debacle has left

  197. asterix has left

  198. asterix has joined

  199. Bartek has left

  200. Bartek has joined

  201. Bartek has left

  202. sonny has left

  203. Bartek has joined

  204. sonny has joined

  205. paul has left

  206. asterix has left

  207. asterix has joined

  208. sonny has left

  209. Bartek has left

  210. paul has joined

  211. debacle has joined

  212. sonny has joined

  213. wurstsalat has left

  214. Bartek has joined

  215. asterix has left

  216. asterix has joined

  217. Bartek has left

  218. sonny has left

  219. wurstsalat has joined

  220. asterix has left

  221. asterix has joined

  222. sonny has joined

  223. Bartek has joined

  224. sonny has left

  225. sonny has joined

  226. Bartek has left

  227. Bartek has joined

  228. Bartek has left

  229. asterix has left

  230. asterix has joined

  231. sonny has left

  232. sonny has joined

  233. Wojtek has left

  234. lovetox has joined

  235. sonny has left

  236. kol has left

  237. sonny has joined

  238. asterix has left

  239. asterix has joined

  240. sonny has left

  241. sonny has joined

  242. sonny has left

  243. sonny has joined

  244. debacle has left

  245. sonny has left

  246. Bartek has joined

  247. asterix has left

  248. asterix has joined

  249. asterix has left

  250. asterix has joined

  251. Bartek has left

  252. Bartek has joined

  253. Bartek has left

  254. lovetox has left

  255. pulkomandy has left

  256. pulkomandy has joined

  257. sonny has joined

  258. sonny has left

  259. gav has left

  260. gav has joined

  261. sonny has joined

  262. rion has left

  263. rion has joined

  264. debacle has joined

  265. sonny has left

  266. sonny has joined

  267. sonny has left

  268. asterix has left

  269. asterix has joined

  270. asterix has left

  271. sonny has joined

  272. sonny has left

  273. sonny has joined

  274. sonny has left

  275. debacle has left