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