XSF Discussion - 2017-09-21


  1. matlag has left
  2. lskdjf has left
  3. SamWhited has left
  4. mimi89999 has joined
  5. daniel has left
  6. daniel has joined
  7. Vaulor has joined
  8. waqas has joined
  9. lumi has left
  10. Tobias has joined
  11. la|r|ma has joined
  12. lskdjf has joined
  13. peter has joined
  14. peter has left
  15. Tobias has joined
  16. winfried has left
  17. tux has left
  18. tux has joined
  19. Lance has joined
  20. Lance has left
  21. Vaulor has left
  22. waqas has left
  23. tim@boese-ban.de has left
  24. efrit has left
  25. Zash has left
  26. Guus has left
  27. sonny has left
  28. daniel has left
  29. daniel has joined
  30. tim@boese-ban.de has joined
  31. mimi89999 has joined
  32. sonny has joined
  33. Guus has joined
  34. Guus has left
  35. moparisthebest has joined
  36. moparisthebest has joined
  37. Guus has joined
  38. Guus has left
  39. Guus has joined
  40. uc has joined
  41. jere has joined
  42. Guus has left
  43. Guus has joined
  44. mimi89999 has joined
  45. Valerian has joined
  46. tim@boese-ban.de has joined
  47. waqas has joined
  48. Valerian has left
  49. Guus has left
  50. Guus has joined
  51. Valerian has joined
  52. waqas has left
  53. emxp has joined
  54. ralphm has joined
  55. daniel has left
  56. daniel has joined
  57. Valerian has left
  58. Guus has left
  59. Guus has joined
  60. tim@boese-ban.de has joined
  61. zinid has joined
  62. tim@boese-ban.de has joined
  63. Flow has joined
  64. jcbrand has joined
  65. Guus has left
  66. daniel has left
  67. daniel has joined
  68. Guus has joined
  69. Guus has left
  70. Guus has joined
  71. jcbrand has left
  72. jonasw Zash, mhm thanks
  73. jonasw not sure what you expect me to do with it though
  74. Zash jonasw: me neither
  75. jonasw okay :)
  76. jonasw then I’m just going to ignore that for now
  77. Steve Kille has left
  78. goffi has joined
  79. Steve Kille has left
  80. Flow has left
  81. la|r|ma has joined
  82. jcbrand has joined
  83. Flow has joined
  84. jubalh has joined
  85. tim@boese-ban.de has joined
  86. tim@boese-ban.de has joined
  87. Alex has joined
  88. ralphm has joined
  89. ralphm has joined
  90. ralphm has joined
  91. Martin has joined
  92. Martin has left
  93. daniel has left
  94. daniel has joined
  95. jubalh has left
  96. efrit has joined
  97. ralphm has joined
  98. la|r|ma has joined
  99. la|r|ma has joined
  100. jubalh has joined
  101. Alex has left
  102. stefandxm has left
  103. sonny has joined
  104. sonny has joined
  105. Alex has joined
  106. stefandxm has joined
  107. jonasw has left
  108. Steve Kille has left
  109. Steve Kille has joined
  110. stefandxm has left
  111. stefandxm has joined
  112. stefandxm has left
  113. stefandxm has joined
  114. jubalh has left
  115. efrit has left
  116. efrit has joined
  117. lskdjf has joined
  118. daniel has left
  119. daniel has joined
  120. efrit has left
  121. efrit has joined
  122. lskdjf has left
  123. lskdjf has joined
  124. jcbrand has left
  125. stefandxm has left
  126. stefandxm has joined
  127. jcbrand has joined
  128. Vaulor has joined
  129. lumi has joined
  130. Guus has left
  131. efrit has left
  132. jubalh has joined
  133. efrit has joined
  134. Guus has left
  135. ralphm has joined
  136. Guus has left
  137. Tobias has joined
  138. tim@boese-ban.de has joined
  139. tim@boese-ban.de has joined
  140. Wiktor has joined
  141. blabla has left
  142. blabla has joined
  143. stefandxm has left
  144. stefandxm has joined
  145. efrit has left
  146. jubalh has left
  147. Zash has left
  148. Tobias has joined
  149. jcbrand has left
  150. nyco has left
  151. tim@boese-ban.de has joined
  152. tim@boese-ban.de has joined
  153. nyco has joined
  154. ralphm has joined
  155. fp-tester has left
  156. fp-tester has left
  157. fp-tester has joined
  158. jcbrand has joined
  159. jubalh has left
  160. daniel has left
  161. daniel has joined
  162. daniel has left
  163. daniel has joined
  164. Guus has left
  165. jcbrand has left
  166. ralphm has left
  167. stefandxm has left
  168. stefandxm has joined
  169. jere has joined
  170. Yagiza has joined
  171. Guus has left
  172. Wiktor has joined
  173. daniel has left
  174. daniel has joined
  175. jcbrand has joined
  176. dwd has left
  177. ralphm has joined
  178. jjrh has left
  179. stefandxm has left
  180. stefandxm has joined
  181. uc has left
  182. jjrh has left
  183. jjrh has left
  184. jjrh has left
  185. Flow has left
  186. jjrh has left
  187. jjrh has left
  188. jjrh has left
  189. jjrh has left
  190. ralphm has joined
  191. waqas has joined
  192. Ge0rG Is there any way to mark a message as related to some other message, without specifying the exact type of relation? We have 0372 for explicit references, <thread>s, LMC, but they all imply a certain relationship
  193. jonasw what is the use-case?
  194. Ge0rG jonasw: MAM - when a given message is asked for, it is useful to provide all the related messages as well.
  195. lovetox has joined
  196. jonasw I’m not convinced
  197. jonasw at least not as default behaviour
  198. Ge0rG jonasw: some messages only make sense on top of others, e.g. reactions or LMC
  199. jonasw sure
  200. Ge0rG jonasw: it would be impractical to deliver only the addon message but not the original one
  201. jonasw for reactions, I’d simply omit those
  202. jonasw (in the view that is)
  203. Ge0rG jonasw: if your client receives a reaction message with a dangling reference, you need to store the XML and process it later when the actual message is obtained.
  204. jonasw yes.
  205. jonasw I don’t necessarily see an issue with that
  206. jonasw while handling out-of-order messages is more annoying
  207. edhelas the new CSS breaks horizontal scrolling on some XEPs https://xmpp.org/extensions/xep-0385.html
  208. jonasw scrolling works, but indeed it’s an issue that it’s required
  209. jonasw edhelas, can you make an issue on the xeps repository?
  210. Ge0rG 385 is just too wide.
  211. emxp has joined
  212. edhelas jonasw done
  213. jonasw edhelas, thanks
  214. jonasw Ge0rG, we can’t go over all XEPs to fix that
  215. Ge0rG jonasw: we could define a common mechanism to cross-reference messages and use that?
  216. jonasw well, we could, but ...
  217. Ge0rG but.
  218. jonasw Ge0rG, sure, yet-another-standard? :)
  219. Ge0rG jonasw: stop spoiling the fun!
  220. edhelas it's possible in CSS to break lines properly
  221. jonasw edhelas, auto-breaking of lines in code examples sounds like a bad idea
  222. edhelas I also have a question
  223. jonasw Ge0rG, you’d want to rebase the existing use-cases (LMC etc.) on that, and especially with LMC I see a lot of breakage from that...
  224. edhelas I'm planning to use MAM to retrieve MUC histories, is it possible to disable the default messages pushed by the server on login ?
  225. daniel edhelas: yes
  226. edhelas oh ?
  227. jonasw edhelas, https://xmpp.org/extensions/xep-0045.html#enter-managehistory
  228. jonasw maxchars='0' is one example
  229. daniel has left
  230. daniel has joined
  231. jonasw (I’d set maxchars='0' *and* maxstanzas='0' to be sure; I guess not all services support maxchars)
  232. edhelas oh, so I should explicitely disable them
  233. jjrh has left
  234. edhelas thanks jonasw :)
  235. jonasw np :)
  236. daniel jonasw: I think I only set maxchars and I never had problems
  237. SamWhited Ge0rG: https://xmpp.org/extensions/xep-0367.html
  238. SamWhited That was meant for things like that
  239. jonasw daniel, "never", not even biboumi? ;)
  240. jere has joined
  241. jere has joined
  242. daniel Even though maxchar is a very weird metric now that I think about it. I guess back in the day is just copy pasted that from somewhere
  243. daniel This will probably break if you set something other than 0
  244. jonasw agreed
  245. daniel jonasw: didn't know that biboumi was a problem. Never got reported to me
  246. Ge0rG SamWhited: is there a reason for using message ID and not unique ID?
  247. jonasw odd, I had something about that in the back of my head. maybe it was about MAM instead
  248. daniel jonasw: yes. Mam did break the stanza queue for sm
  249. SamWhited Ge0rG: no, I don't think anyone supports unique ID
  250. Ge0rG XEP-0045 is full of quirks
  251. SamWhited But it doesn't matter to me
  252. Ge0rG I'd really love to fix message IDs instead of inventing new unique IDs. But backward compatibility!1!
  253. stefandxm has left
  254. stefandxm has joined
  255. daniel has left
  256. daniel has joined
  257. SamWhited Oh, am I mixing those up? Whichever. I would be fine coupling it to the unique stable message ID thing, whichever that is
  258. jonasw XEP-0359 (<https://xmpp.org/extensions/xep-0359.html>)
  259. Vaulor has left
  260. Vaulor has joined
  261. SamWhited Right, that.
  262. SamWhited Yah, in that case the real reason this doesn't support it is that HipChat doesn't support it and I was never going to be able to convince them to let me ad even more stuff.
  263. SamWhited Ge0rG: Do you think you'd want to use it for something? If so I wouldn't mind updating it to use the unique ID stuff
  264. Ge0rG SamWhited: some weeks ago, the topic of grouping messages when delivering MAM data came up here
  265. moparisthebest just curious, how do you know messages are related?
  266. Ge0rG moparisthebest: that's the challenge
  267. moparisthebest like these might be in response to your stuff, in fact they are, but they might just be a random unrelated topic
  268. SamWhited Oh, this is for grouping messages sent in reply to another message? That seems different to me
  269. moparisthebest that seems like an unsolvable challenge from an automated perspective, so a xep to support the grouping seems useless
  270. SamWhited actually, maybe not…
  271. Ge0rG SamWhited: it's about finding out which messages are related to each other
  272. SamWhited I agree with half of what moparisthebest said; it seems unsolvable if you're trying to automate it. That doesn't mean you can't have a good UI that leads the user to do the work for you.
  273. moparisthebest I don't think you can and that's why it just returns the last X or whatever
  274. moparisthebest SamWhited, if I respond to you like this I guess you could call those grouped (by putting your name first)
  275. jonasw the relation is already spelled out in the XML (LMC, Reactions...)
  276. jonasw there’s just no unified way to detect it
  277. jonasw (it’s, from my understanding, not about generic replies)
  278. SamWhited moparisthebest: That seems like a sensible guess
  279. SamWhited This seems more like what <thread> is for though
  280. Ge0rG SamWhited: I'm not speaking about message that have content that relates to other messages
  281. Ge0rG SamWhited: I'm speaking about technical dependencies, like "this message is a reaction to message XY"
  282. Ge0rG so it doesn't make sense to parse / display the message without also having XY
  283. SamWhited oh yes, that's what I thought you meant originally, yah, that's totally what this is for
  284. SamWhited I think… you mean things like clients having a +1 button or a party hat button or something?
  285. Ge0rG so it would make sense, in the context of MAM, to use unique IDs
  286. jonasw SamWhited, yes
  287. Ge0rG SamWhited: yeah
  288. SamWhited Cool, yah, moparisthebest was confusing me :)
  289. SamWhited That is indeed what this was made for
  290. jonasw so let’s rebase xep-0367 on stable & unique message IDs and build a reactions XEP on top of that
  291. Ge0rG jonasw: +1
  292. Ge0rG Except...
  293. jonasw you want me to do the work, right? ;P
  294. Ge0rG You still don't know the unique message ID of outgoing messages.
  295. SamWhited I don't remember the MID spec, but it allows clients to assign one too, right?
  296. jonasw SamWhited, indeed
  297. SamWhited ¯\_(ツ)_/¯ problem solved
  298. jonasw so called origin-id
  299. Ge0rG But MAM operates on the server-assigned ID
  300. SamWhited That seems fine; MAM operates on server assigned ID, this operates on client assigned ones.
  301. jonasw it would be convenient if the client could query MAM for the message if MAM doesn’t support grouping
  302. jonasw (the proposed grouping that is)
  303. jonasw alternatively, we could modify MAM to adopt the client-generated origin-id for sent messages iff it doesn’t conflict with any existing ID (and maybe reject delivery otherwise or something)
  304. Ge0rG I'm sure somebody will pull the "omg security!1!" card on that.
  305. moparisthebest Ge0rG‎: "this message is a reaction to message XY" -- how do you know that though?
  306. jonasw moparisthebest, reaction as in "+1 button"
  307. jonasw not as I react to your message right now
  308. jonasw Ge0rG, how?
  309. jonasw (and isn’t that usually your job?)
  310. moparisthebest he said 'this message is a reaction' not 'I hit a +1' (is +1 a thing in xmpp or any clients?)
  311. jonasw not yet, that’s the point
  312. jonasw and those "+1 buttons" are usually called reactions
  313. jonasw e.g. on github
  314. Ge0rG jonasw: let's see... if the server is using a typical hash-table implementation, a client could DoS it by contructing specially-chosen UUIDs.
  315. jonasw Ge0rG, meeeh :P
  316. jonasw just don’t tell clients your hash seed?
  317. la|r|ma has joined
  318. Ge0rG This one! https://arstechnica.com/information-technology/2011/12/huge-portions-of-web-vulnerable-to-hashing-denial-of-service-attack/
  319. jonasw that’s a general vector, and afaict choosing a random hash seed is sufficient to fix that
  320. Ge0rG jonasw: I'm sure it's possible to extract the seed via side-channel attacks
  321. jonasw Ge0rG, *sigh*
  322. jonasw then we’ll have to operate on the client-generated ID. it’s saner anyways, because it works without MAM
  323. jonasw MAM will have to interpret these IDs then and intrenally store their relatedness for queries
  324. edhelas what is the correct request to get MAM history from MUC ?
  325. jonasw edhelas, ask the MUC for history?
  326. edhelas <iq xmlns="jabber:client" type="set" id="S8lR4X"><query xmlns="urn:xmpp:mam:1"><x xmlns="jabber:x:data" type="submit"><field var="FORM_TYPE"><value>urn:xmpp:mam:1</value></field><field var="with"><value>muc@conference.movim.eu</value></field></x><set xmlns="http://jabber.org/protocol/rsm"><max>300</max></set></query></iq>
  327. jonasw (I don’t know of any non-biboumi MUCs which support that)
  328. edhelas looks like I'm wrong somewhere
  329. jonasw edhelas, also, this may be better suited in jdev@
  330. Ge0rG jonasw: yeah. Because it's a good thing to have three different IDs on each message.
  331. edhelas a true
  332. edhelas sory
  333. jonasw Ge0rG, m(
  334. jonasw why exactly is a mam query a type='set' operation?!
  335. Ge0rG oh, wait. those IDs are all insufficient in some ways. Let's create a new XEP with a fourth, universal ID!
  336. jonasw Ge0rG, any other suggestion? other than getting a sent-carbon for your own message with the MAM ID >.>
  337. SamWhited hmm, I guess querying MAM for "a message and all of its reactions" would be sort of nice. I'm not sure if it's strictly necessary though.
  338. Ge0rG jonasw: that was exactly what I proposed back then.
  339. SamWhited It seems to add another dimension of complication for something that could easily be lived without.
  340. Guus has left
  341. Ge0rG SamWhited: the problem is not "a message and all of its reactions" but rather "the message and all the messages you need to properly understand it"
  342. SamWhited Why would you ever actually need to do that? I don't dislike the idea of making sure that's queryable, it just doesn't seem like a common enough thing to worry about.
  343. Ge0rG SamWhited: if you receive a reaction message with an unresolved reference ID, you need to delay processing until you know what it is a reaction to
  344. SamWhited I suspect 90% of people will just sync history and you'll see new reactions appearing as history gets updated
  345. SamWhited That seems fine
  346. jonasw I tend to agree
  347. Neustradamus has joined
  348. Ge0rG I tend to process messages when they are received, but that doesn't work with missing references.
  349. waqas has left
  350. jonasw the argument Ge0rG makes is in the spirit of the "simple clients, complex servers" principle though
  351. SamWhited Does MAM not guarantee delivery order?
  352. SamWhited Oh, nevermind, stupid question
  353. jonasw ok :)
  354. SamWhited If you have a reaction and *then* you sync history it doesn't matter what MAM does.
  355. Ge0rG SamWhited: it only guarantees the order for the subset you request.
  356. SamWhited yup, yup
  357. SamWhited So in that case though you end up having to make a MAM query, then for each message make another query asking if there are any reactions you haven't received yet
  358. Ge0rG if there are any messages for a given reaction.
  359. jonasw SamWhited, no, the idea would be that the original MAM query would give you all messages to which there have been reactions in the result setd
  360. jonasw (even though they may be outside the range of messages you requested)
  361. Ge0rG jonasw: but that would violate message order, and lead to interesting results.
  362. SamWhited This seems like a lot of additional complexity when you could just store your reactions somewhere on the client and when you get a message if you have reactions in storage already display them.
  363. SamWhited Or when you get a reaction, if you have the message its linked to, also display it.
  364. Ge0rG example: you request 50 messages before #103. you get #53-#102 and #40 because it was reacted to. Next, you request 50 messages before #40, because it is the earliest in your history. #41-#52 are lost
  365. jonasw Ge0rG, all depends on the sanity of your implementation
  366. Ge0rG SamWhited: that makes (limited) sense if you store the original message XML somewhere
  367. jonasw Ge0rG, do you really need the XML? I don’t think so.
  368. SamWhited Ge0rG: I don't think the storage format matters
  369. Ge0rG SamWhited: but then you end up searching your storage for a reference to each new message you receive.
  370. SamWhited Ge0rG: That seems fine
  371. Alex has left
  372. Ge0rG pulls the client DoS card.
  373. jonasw I pull the "use a proper storage backend" card
  374. SamWhited There is no client DoS card.
  375. jonasw e.g. a simple sqlite database
  376. jonasw just add a column "reaction_to" with a stable message ID thing
  377. jonasw add an index to it
  378. jonasw -> reasonable lookup time
  379. jonasw you also only need to do that for messages you fetch from the archive
  380. SamWhited Flat XML files are probably fine, you are going to get a bunch of stuff to store, that's just how XMPP works. If you're worried about scans and lookup times, its your job to do something intelligent and make sure you don't dos yourself.
  381. SamWhited Maybe that means creating an "unknown references" file to make scanning quicker, maybe it means using a database. That's up to you.
  382. Ge0rG I wish for the times when XMPP servers were complicated and XMPP clients were simple.
  383. SamWhited I agree with that in general, but this doesn't make the XMPP client complicated; it makes it a dumb display layer that doesn't have to have a ton of logic about doing crazy MAM queries.
  384. SamWhited It can just keep doing whatever it was already doing and process things as they come in. It might be processing the reaction, or it might be processing the message in terms of reactions it already has.
  385. moparisthebest do clients generally do mam queries reversed like that?
  386. moparisthebest conversations doesn't seem to, it seems to start loading from your last message and go forward
  387. moparisthebest in which case everything *just works*
  388. Ge0rG moparisthebest: I think there are two models of MAM usage: (a) query for everything since your last connection, (b) query a given channel / user history on demand when opening the tab
  389. edhelas has left
  390. edhelas has joined
  391. moparisthebest oh I was waiting for b until I just realized gajim made that into a beer...
  392. Ge0rG "Clients and servers MUST NOT include an <attach-to/> element on messages with a non-messaging payload unless they are including it on an error which may be attached to the message that caused the error to be generated." What is a "non-messaging payload"?
  393. SamWhited No idea, no <body> I guess? That should probably be fixed.
  394. SamWhited Or just removed, I don't see the point in that restriction anymore.
  395. stefandxm has left
  396. stefandxm has joined
  397. sonny has joined
  398. ralphm has joined
  399. waqas has joined
  400. la|r|ma has joined
  401. jubalh has left
  402. daniel has left
  403. jubalh has joined
  404. daniel has joined
  405. edhelas has left
  406. Ge0rG SamWhited: for reactions, I'd go with a separate non-<body> element, because people in here demanded invisibility to incompatible clients
  407. stefandxm has left
  408. sonny has joined
  409. Ge0rG And because it will be awesome to have to change all the implementations that filter out body-less messages as "unimportant".
  410. SamWhited yah, just removing those lines from message attatching seems reasonable
  411. jcbrand has left
  412. edhelas has left
  413. dwd has left
  414. edhelas has left
  415. Vaulor has left
  416. dwd has left
  417. jjrh has left
  418. ralphm has joined
  419. Guus has left
  420. jjrh has left
  421. jjrh has left
  422. jjrh has left
  423. zinid has left
  424. tux has joined
  425. jubalh has left
  426. jjrh has left
  427. stefandxm has joined
  428. jjrh has left
  429. jjrh has left
  430. sonny has joined
  431. jjrh has left
  432. jjrh has left
  433. Steve Kille has left
  434. Steve Kille has left
  435. Guus has left
  436. waqas has left
  437. goffi has left
  438. tim@boese-ban.de has joined
  439. tim@boese-ban.de has joined
  440. Steve Kille has joined
  441. Guus has left
  442. waqas has joined
  443. daniel has left
  444. daniel has joined
  445. Steve Kille has left
  446. jcbrand has joined
  447. peter has joined
  448. mimi89999 has left
  449. jjrh has left
  450. Ge0rG has left
  451. Yagiza has left
  452. Ge0rG has left
  453. lumi has left
  454. Ge0rG has joined
  455. jabberatdemo has joined
  456. jjrh has left
  457. jcbrand has left
  458. jabberatdemo has left
  459. emxp has left
  460. emxp has joined
  461. jjrh has left
  462. jjrh has left
  463. waqas has left
  464. waqas has joined
  465. Guus has left
  466. tim@boese-ban.de has left
  467. tim@boese-ban.de has joined
  468. jjrh has left
  469. daniel has left
  470. jubalh has joined
  471. sonny has joined
  472. jjrh has left
  473. daniel has joined
  474. jabberatdemo has joined
  475. sonny has joined
  476. ralphm has joined
  477. goffi has joined
  478. jabberatdemo has left
  479. sonny has joined
  480. Guus has left
  481. Ge0rG has left
  482. Guus has left
  483. jubalh has left
  484. Guus has left
  485. Alex has joined
  486. tim@boese-ban.de has joined
  487. tim@boese-ban.de has joined
  488. xnyhps has left
  489. ralphm has joined
  490. sonny has joined
  491. Kev has left
  492. sonny has joined
  493. Ge0rG has left
  494. vanitasvitae has left
  495. vanitasvitae has joined
  496. Guus has left
  497. sonny has joined
  498. Ge0rG has left
  499. sonny has joined
  500. zinid has left
  501. jabberatdemo has joined
  502. jabberatdemo has left
  503. lskdjf has joined
  504. jere has joined
  505. ralphm has joined
  506. SamWhited has left
  507. Ge0rG has left
  508. jere has joined
  509. lumi has joined
  510. jjrh has left
  511. jjrh has left
  512. Flow has joined
  513. Ge0rG has left
  514. jjrh has left
  515. jjrh has left
  516. ralphm has left
  517. valo has left
  518. goffi has left
  519. valo has joined
  520. pep. has left
  521. jubalh has joined
  522. daniel has left
  523. goffi has left
  524. goffi has joined
  525. Tobias has left
  526. Tobias has joined
  527. Ge0rG has left
  528. Flow has left
  529. Guus has left
  530. jere has left
  531. jere has joined
  532. Ge0rG has left
  533. jubalh has left
  534. tim@boese-ban.de has left
  535. tim@boese-ban.de has joined
  536. goffi has left
  537. fp-tester has joined
  538. Ge0rG has left
  539. Guus has left
  540. jcbrand has joined
  541. jcbrand has left
  542. Ge0rG has left
  543. edhelas has left
  544. ralphm has left
  545. jcbrand has joined
  546. edhelas has left
  547. edhelas has joined
  548. jubalh has joined
  549. moparisthebest has joined
  550. Ge0rG has left
  551. tux has joined
  552. Tobias has left
  553. edhelas has left
  554. Ge0rG has left
  555. edhelas muc.xmpp.org doesn't supports mam:1/mam:2 yet ?
  556. MattJ No
  557. Zash -version xmpp.org
  558. Bunneh Zash: xmpp.org is running Prosody version 0.9.12 on Linux
  559. edhelas has left
  560. jjrh has left
  561. Ge0rG has left
  562. ralphm has left
  563. moparisthebest -version muc.xmpp.org
  564. Bunneh moparisthebest: muc.xmpp.org doesn't reply to version requests
  565. edhelas yeah that seems to be the problem
  566. edhelas I don't see caps for muc.xmpp.org in my db
  567. moparisthebest Yea so we don't actually know what it's running :)
  568. Zash <identity type='text' name='Prosody Chatrooms' category='conference'/>
  569. Zash Impossible to know
  570. mathieui total mystery
  571. Ge0rG has left
  572. jcbrand has left
  573. fp-tester has left
  574. fp-tester has joined
  575. moparisthebest has joined
  576. fp-tester has left
  577. fp-tester has joined
  578. Ge0rG has left
  579. daniel has left
  580. Alex has left
  581. jjrh has left
  582. zinid has left
  583. Ge0rG has left
  584. tim@boese-ban.de has joined
  585. tim@boese-ban.de has joined
  586. jubalh has joined
  587. Guus has left
  588. Guus has left
  589. lovetox has left
  590. peter has left
  591. Ge0rG has left
  592. blabla has left
  593. blabla has joined
  594. Guus has left
  595. Ge0rG has left
  596. ralphm has left
  597. jjrh has left
  598. Ge0rG has left
  599. jjrh has left
  600. jjrh has left
  601. jjrh has left
  602. Ge0rG has left
  603. Guus has left
  604. peter has joined
  605. SamWhited has left
  606. peter has left
  607. moparisthebest It could be lying
  608. moparisthebest Never trust a remote entity
  609. Neustradamus has left
  610. Neustradamus has joined
  611. Ge0rG has left
  612. jere has left
  613. jere has joined