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


  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


  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


  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


  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


  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


  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


  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