XSF Discussion - 2018-11-02

  1. Maranda has left

  2. dedekin has left

  3. efrit has left

  4. Guus has joined

  5. labdsf has left

  6. labdsf has joined

  7. Guus has left

  8. Guus has joined

  9. Zash has left

  10. Guus has left

  11. alexis has joined

  12. jjrh has left

  13. jjrh has left

  14. alexis has left

  15. 404.city has left

  16. Guus has joined

  17. 404.city has joined

  18. lumi has joined

  19. 404.city has left

  20. 404.city has joined

  21. jjrh has left

  22. !xsf_martin has joined

  23. UsL has left

  24. UsL has joined

  25. bear has left

  26. !xsf_martin has left

  27. Guus has joined

  28. alexis has joined

  29. matlag has left

  30. alexis has joined

  31. jjrh has left

  32. 404.city has left

  33. alexis has left

  34. Nekit has joined

  35. mrdoctorwho has left

  36. mrdoctorwho has joined

  37. mrdoctorwho has left

  38. alexis has joined

  39. j.r has joined

  40. alexis has left

  41. ThibG has joined

  42. ThibG has joined

  43. j.r has joined

  44. grumpy has joined

  45. Guus has joined

  46. mrdoctorwho has joined

  47. krauq has joined

  48. alexis has joined

  49. j.r has joined

  50. alexis has joined

  51. krauq has left

  52. krauq has joined

  53. krauq has left

  54. krauq has joined

  55. Yagiza has joined

  56. Nekit has joined

  57. Lance has joined

  58. Guus has left

  59. Guus has joined

  60. Lance has left

  61. Guus has left

  62. alexis has left

  63. Guus has joined

  64. Guus has left

  65. Guus has joined

  66. alexis has joined

  67. Guus has left

  68. Guus has joined

  69. UsL has left

  70. UsL has joined

  71. labdsf has left

  72. labdsf has joined

  73. ta has left

  74. labdsf has left

  75. labdsf has joined

  76. labdsf has left

  77. labdsf has joined

  78. alexis has left

  79. alexis has joined

  80. Guus has left

  81. Guus has joined

  82. alexis has left

  83. Guus has left

  84. Nekit has left

  85. moparisthebest has left

  86. moparisthebest has joined

  87. Nekit has joined

  88. lorddavidiii has joined

  89. ta has left

  90. Guus has joined

  91. Str4tocaster has joined

  92. Guus has left

  93. Guus has joined

  94. Guus has left

  95. Str4tocaster has left

  96. Str4tocaster has joined

  97. lorddavidiii has left

  98. Str4tocaster has left

  99. labdsf has left

  100. labdsf has joined

  101. lorddavidiii has joined

  102. Str4tocaster has joined

  103. Str4tocaster has left

  104. Str4tocaster has joined

  105. alexis has joined

  106. Str4tocaster has left

  107. Str4tocaster has joined

  108. valo has left

  109. valo has joined

  110. lnj has joined

  111. j.r has left

  112. alexis has joined

  113. Str4tocaster has left

  114. Str4tocaster has joined

  115. j.r has joined

  116. genofire has left

  117. Nekit has left

  118. Nekit has joined

  119. daniel has joined

  120. labdsf has left

  121. l has joined

  122. l has joined

  123. l has joined

  124. l has joined

  125. l has joined

  126. lskdjf has joined

  127. alexis has left

  128. lorddavidiii has left

  129. lorddavidiii has joined

  130. lskdjf has joined

  131. lskdjf has joined

  132. Guus has joined

  133. guusdk has left

  134. guusdk has left

  135. guusdk has joined

  136. 404.city has joined

  137. guusdk has left

  138. lskdjf has left

  139. 404.city has left

  140. flow

    jonas’, which server side impl does the full flush?

  141. flow

    ahh it is "bytes saved", that is why full flush percentages are lower…

  142. l has joined

  143. goffi has joined

  144. alexis has joined

  145. Zash has left

  146. alexis has left

  147. dedekin has joined

  148. Str4tocaster has left

  149. alexis has joined

  150. Str4tocaster has joined

  151. waqas has left

  152. Str4tocaster has left

  153. Str4tocaster has joined

  154. lorddavidiii has left

  155. Zash has left

  156. Str4tocaster has left

  157. Str4tocaster has joined

  158. alexis has left

  159. Str4tocaster has left

  160. Str4tocaster has joined

  161. mimi89999 has left

  162. Str4tocaster has left

  163. Str4tocaster has joined

  164. l has joined

  165. l has joined

  166. l has joined

  167. lovetox has joined

  168. l has left

  169. Str4tocaster has left

  170. Str4tocaster has joined

  171. alexis has joined

  172. Str4tocaster has left

  173. Str4tocaster has joined

  174. vaulor has left

  175. vaulor has joined

  176. krauq has joined

  177. lovetox has left

  178. Steve Kille has left

  179. Steve Kille has left

  180. Steve Kille has joined

  181. lorddavidiii has joined

  182. labdsf has joined

  183. guusdk has left

  184. guusdk has joined

  185. alexis has left

  186. Guus has left

  187. Guus has joined

  188. Guus has left

  189. Steve Kille has left

  190. Steve Kille has joined

  191. APach has left

  192. dedekin has left

  193. lorddavidiii has left

  194. lskdjf has joined

  195. lskdjf has joined

  196. jonas’ has left

  197. jonas’ has joined

  198. jonas’

    flow, I hacked the prosody impl to do a full flush

  199. Ge0rG

    ain't it called a "straight flush"? 😁

  200. Ge0rG

    how do you add images to the xmpp wiki?

  201. pep.

    There's a special page to upload file on mediawiki? That's usually accessible on the panel on the left when editing a page

  202. alexis has joined

  203. Ge0rG

    pep.: yes, that's about what I know. But that link isn't there, so now I'm lost.

  204. dedekin has joined

  205. labdsf has left

  206. labdsf has joined

  207. labdsf has left

  208. labdsf has joined

  209. pep.


  210. pep.

    If not maybe that's disabled?

  211. alexis has left

  212. ralphm

    It is disabled

  213. Ge0rG

    And I presume you can't inline-link externally hosted files?

  214. krauq has joined

  215. alexis has joined

  216. dedekin has left

  217. Str4tocaster has left

  218. dwd has joined

  219. Zash has joined

  220. flow

    jonas’, good job. that sounds like it is possible to make prosody announce a zlib-with-full-flush-or-whatever-you-wanna-call-it compression method

  221. dwd

    jonas’, Real percentages are much higher, or at least they used to be. I did a load of work compressing real traffic captures - but performing a sync flush after multiple stanzas helps a lot, and using CSI really drives it up.

  222. Ge0rG

    dwd: CSI doesn't absolve you from sync-flushing after each stanza, right?

  223. dwd

    Ge0rG, I don't think anything mandates you sync-flush after every stanza - just after every buffer flush.

  224. ThibG has left

  225. flow

    Ge0rG, you only need sync flush if there is no more data

  226. dwd

    flow, That's more or less what I was typing - you only flush once all the inbound traffic has been processed, at least on C2S.

  227. flow

    dwd, sorry, I just didn't get what you meant with "after every buffer flush" and wanted to clarify it a bit for Ge0rG

  228. dwd

    flow, Yeah, I was clarifying it the same way as you, but you beat me to it. :-)

  229. efrit has joined

  230. alexis has left

  231. Guus has joined

  232. Alex has joined

  233. flow

    dwd, I'm also confused why you wrote "inbound" traffic, I'd say it is the "outbound" traffic where an entity controls the zlib behavior. For inbound traffic it is just consuming whatever bytes have been send to it

  234. dwd

    flow, Ah. So if a client sends you N stanzas, you only need to flush after processing all N.

  235. Ge0rG

    dwd: the issue we are working around is that compression provides a plaintext size oracle for attackers, right?

  236. flow

    dwd, that again sounds like the receiving entity would flush

  237. flow

    which is kind of new to me

  238. dwd

    Ge0rG, Sure, if you think that's a realistic security problem, then you have to compress only traffic that can be influenced by one entity at a time. Which basically means compressing each stanza individually.

  239. flow

    dwd, or "do a full flush on every channel change"

  240. Ge0rG

    dwd: all security problems tend to become realistic sooner or later.

  241. dwd

    flow, It is exactly that. But it only makes a difference on C2S, I hasten to add.

  242. dedekin has joined

  243. flow

    dwd: hmm, well as long as the from/to pair does not change on s2s…

  244. dwd

    Ge0rG, Sure. But the compression oracle in HTTP was significant because it allowed access to password data, for example.

  245. flow

    you don't need to drop the dictionary, I think

  246. Ge0rG

    dwd: are you saying that s2s is not affected by the oracle vulnerability, or that the channel stays always the same between the two server domains?

  247. flow

    Ge0rG, I think he meant that the channel changes with every stanza

  248. flow

    but I'd argue that the channel stays stable until the from/to pair changes

  249. flow

    whereas in c2s, on of from/to is always fixed

  250. flow


  251. Ge0rG

    By that logic, with CSI we should reorder messages so that same-channel messages are sent consecutively

  252. dwd


  253. flow

    I don't follow how this is implied by that logic

  254. dwd

    I think that you can run a compression-oracle attack on S2S more easily - I think it's easier to inject traffic, and possibly easier to witness the transport channel as well - but you'd find it harder to get anything useful once you had the attack in place.

  255. Ge0rG

    dwd: the compression oracle in HTTP made it comparably easy to extract credentials, yes. But it does apply to content as well, just that it's rather hard for an attacker to control data injected after the typical body of a web site.

  256. Ge0rG

    with XMPP, the game is vastly different

  257. flow

    Slightly unrelated: I also wonder how widespread s2s compression is

  258. dwd

    flow, Not very. Early versions of Openfire did it, but we disabled it (because it stopped working).

  259. Ge0rG

    I don't know, but I'd argue that s2s compression is largely irrelevant in typical federated deployments

  260. APach has joined

  261. dedekin has left

  262. dwd

    It wouldn't surprise me if M-Link did it, given its use-cases, but I don't know (and it's a looong time since I knew that kind of thing).

  263. blabla has joined

  264. dwd has left

  265. flow

    Ge0rG, I'm not sure about the "irrelevant" part

  266. Ge0rG

    flow: irrelevant in the sense that you are not gaining much from it

  267. flow

    Not everyone hosts its XMPP server in a well connected datacenter

  268. flow

    Ge0rG, I figured so far, but I still believe that this may not be true in every case.

  269. Ge0rG

    flow: if you run your XMPP server in your basement on a crappy ADSL line, you are probably not going to use IBB transfers much

  270. flow

    Ge0rG, i was thinking more about third world countries

  271. dwd

    flow, Well, tactical military deployments are all S2S over long/thin links, but usually with heavy compression on the links themselves, so I'm not sure '138 would be needed.

  272. dwd

    Still, all this is rather irrelevant. If we posit that content ends up fully encrypted under OMEMO/MLS/OX/eSessions/PGP then it's incompressible (one hopes). The remaining traffic is best compressed by EXI.

  273. flow

    True, but then again, we are far from the point where content is fully, or even mostly, encrypted. It may take years until we reach that.

  274. dedekin has joined

  275. flow

    So I am again not sure about the "irrlevant" part :)

  276. Ge0rG

    dwd: if the s2s connection is encrypted, you can't compress it much on the underlying link layer

  277. dwd

    Ge0rG, WHich is why they don't in those circumstances.

  278. moparisthebest has joined

  279. daniel has left

  280. labdsf has left

  281. labdsf has joined

  282. tux has joined

  283. alexis has joined

  284. tux has left

  285. jonas’

    dwd, right, so both the prosody and aioxmpp implementations do a sync (or full) flush after each stanza

  286. jonas’

    so by implementing some CORKing, that could be made better I suppose

  287. fffo881 has joined

  288. fffo881


  289. dwd


  290. flow

    jonas’, CORKing?

  291. jonas’

    flow, like TCP CORK, where you wait for more data for a short period of time before sending it out

  292. flow

    ahh, nagle algorithmus, right?

  293. MattJ

    Similar, but manual

  294. dwd

    jonas’, Yeah, that's Nagle not CORK. CORK is holding the transmission until you manually release it.

  295. blabla has joined

  296. jonas’

    dwd, isn’t nagle that thing which reduces the data rate when stuff gets lost?

  297. jonas’

    I am lost in the TCP termini, sorry for the confusion.

  298. flow

    jonas’, I don't think so

  299. jonas’

    you’re probably both right :)

  300. jonas’

    nevermind me, you know what I mean (now) though :)

  301. dwd

    jonas’, No, that's backoff, which might well have been developed by Jon Nagle, but doesn't bear his name at least.

  302. flow

    nagle just defers the write a widen the window for more data from the application

  303. MattJ

    jonas’, Nagle's is basically automatic corking at the beginning of a connection

  304. flow

    batch/bundle and defer

  305. jonas’


  306. flow

    now that I read up on TCP_CORK I can imagine that it isn't heavily used because it appears to be error prone

  307. dwd

    jonas’, And then there's the reverse - lose stuff when the data rate drops - which is best done with RED, which is Sally Fields's design as I recall. But I don't think that makes sense in XMPP.

  308. jonas’

    this was more about the concept anyways

  309. dwd

    flow, Very platform specific too, and irrelevant to us because we need to compress as we go, I think.

  310. flow

    MattJ, "at the beginning of a connection"? Isn't nagle used over the whole lifetime of a connection (if enabled)?

  311. Str4tocaster has joined

  312. daniel has left

  313. daniel has joined

  314. ThibG has joined

  315. ThibG has left

  316. MattJ

    Mmm, yeah, sorry

  317. Str4tocaster has left

  318. flow

    jonas’, if the idea is to wait for more outbound stanzas until you give the network layer green light to send it, then I'm fully with you. And like to note that Smack allows for that since many years. Even though I've implemented it to reduce the powered-up time of the radio, it will also help regarding the compression ratio

  319. jonas’

    flow, no, the idea is to wait for more stanzas before performing the full/sync flush in zlib

  320. jonas’

    instead of flushing after each stanza

  321. flow

    MattJ, no worries, just wanted to make sure that I'm not missing something

  322. jonas’

    (of course taking into account the "(to, from) pair must match to be secure" criterion)

  323. flow

    jonas’, I think we are talking about the same mechanism

  324. jonas’


  325. flow

    I just want to point out that it also increases efficiency in other areas

  326. jonas’


  327. l has joined

  328. alexis has left

  329. fffo881 has left

  330. labdsf has left

  331. labdsf has joined

  332. Ge0rG

    what about having a zlib dictionary per JID?

  333. jonas’

    memory cost

  334. jonas’

    and I think both parties need to agree on the dictionary beforehand

  335. jonas’

    so you’d have to transfer that dictionary every time you switch?

  336. jonas’

    or if you had multiple compression streams, you’d have to have an out-of-band way to signal to the peer which one the next bytes belongs to

  337. jonas’

    or if you had multiple compression streams, you’d have to have an out-of-band way to signal to the peer which one the next bytes belong to

  338. matlag has left

  339. Ge0rG


  340. dwd

    You could build state-switching into the compression framing, of course, but yeah - memory cost would be scary-huge.

  341. lskdjf has joined

  342. Nekit has left

  343. Nekit has joined

  344. jonas’

    regarding the use of compression and e2ee: zlib seems to be rather good at reversing the base64-bloat, so that’s at least something.

  345. Ge0rG

    We need a way to embed raw bytestreams into XML.

  346. Ge0rG

    Or just replace XML with... protobufs? ASN.1?

  347. jonas’

    using base92 would probably go a long way already

  348. Zash


  349. jonas’

    (or was it 96?)

  350. jonas’

    anything above that would give diminishing returns due to UTF-8 encoding anyways

  351. alexis has joined

  352. Ge0rG

    jonas’: base-91

  353. Ge0rG

    yeah, UTF-8 is not an efficient encoding.

  354. lumi has joined

  355. dwd

    Well. Not in terms of bits, anyway.

  356. jonas’


  357. jonas’

    base91 uses < and >

  358. jonas’

    an &

  359. jonas’

    and &

  360. jonas’

    while not-using -, \ and '

  361. Ge0rG

    Anybody still remembers https://en.wikipedia.org/wiki/YEnc ?

  362. Guus has left

  363. Guus has joined

  364. guusdk has left

  365. guusdk has joined

  366. lnj has left

  367. lnj has joined

  368. jonas’

    base85 seems to be the highest thing which is specified somewhere

  369. jonas’

    base85 seems to be the highest thing which is specified somewhere sane

  370. dwd

    I do occasionally muse over whether a dedicated XMLStream compression could outperform EXI in practical ways, though. Easy to have binary blobs instead of base64, for example, and we could accrue symbols and store dictionaries of XML symbols between sessions and things. We could also ignore the problems of comments, PIs, etc. Possibly even ignore namespaced attributes, since we never (?) use them.

  371. alexis has left

  372. jonas’

    don’t shut the door on namespaced attributes completely.

  373. Ge0rG

    XML is really a horrible encoding protocol for machines.

  374. flow

    what jonas’ said

  375. Zash

    It's fine, don't worry too much

  376. dwd

    jonas’, Well, it wouldn't matter if they were considered an outlier and not encoded very efficiently, at least.

  377. jonas’

    dwd, that’s true

  378. mimi89999 has joined

  379. Guus has left

  380. dwd

    Ge0rG, I quite like many of the properties of XML for our purposes. Certainly the alternatives would make a bunch of things much more painful - and I always have a nagging feeling that a construct like JSON imposes a data structure that is hard to break away from.

  381. Zash

    Do something like header compression in h2?

  382. dedekin has left

  383. Ge0rG

    dwd: JSON shares most of the disadvantages of XML

  384. Zash


  385. matlag has left

  386. Ge0rG

    I liked the MIDI format, where all numbers are dynamic-width.

  387. dwd

    Ge0rG, Or BER, where they can be?

  388. !xsf_martin has joined

  389. jonas’


  390. jonas’


  391. Ge0rG

    dwd: I'd go with DER for lesser ambiguity

  392. dwd has left

  393. dwd has joined

  394. Zash


  395. dwd

    Ge0rG, CER?

  396. Ge0rG

    Also whoever made it possible to encode U-0000 as an arbitrarily long UTF-8 sequence deserves the highest punishment.

  397. jonas’

    tell me more

  398. jonas’

    can’t you encode all things as arbitrarily long utf-8 sequence though?

  399. dwd

    jonas’, Only by ignoring the standard.

  400. jonas’

    but that’s not true for U+0000?

  401. Zash

    JSON Encoding Rules

  402. Ge0rG

    jonas’: I'm only bitching because U+0000 has special meaning in C.

  403. Zash

    Is a thing

  404. Ge0rG

    jonas’: https://en.wikipedia.org/wiki/UTF-8#Description - UTF-8 just stuffs the data bits after the header. A sane encoding would be to automatically add 0x80 to the bits in a two-byte encoded charset, because you can represent the first 0x80 values in one byte, etc.

  405. Ge0rG

    jonas’: https://en.wikipedia.org/wiki/UTF-8#Description - UTF-8 just stuffs the data bits after the header. A sane encoding would be to automatically add 0x80 to the bits in a two-byte encoded codepoint, because you can represent the first 0x80 values in one byte, etc.

  406. jonas’


  407. matlag has left

  408. Ge0rG

    it would also reduce the required number of bytes.

  409. Guus has joined

  410. dedekin has joined

  411. alexis has joined

  412. alexis has left

  413. dedekin has left

  414. Zash has left

  415. Link Mauve

    “Possibly even ignore namespaced attributes, since we never (?) use them.”, we do, @xml:lang for instance.

  416. Link Mauve

    dwd, ↑

  417. dwd

    Ah, true. But known ones like that we'd handle differently anyway.

  418. Link Mauve

    “12:00:46 Ge0rG> Also whoever made it possible to encode U-0000 as an arbitrarily long UTF-8 sequence deserves the highest punishment.”, you’re expected to reject it though.

  419. Link Mauve

    Same as any other overly-long sequence.

  420. Ge0rG has left

  421. Zash has left

  422. lskdjf has left

  423. l has left

  424. dedekin has joined

  425. vaulor has joined

  426. alexis has joined

  427. Guus has left

  428. Guus has joined

  429. Guus has left

  430. genofire has left

  431. Holger has left

  432. alexis has left

  433. ThibG has joined

  434. genofire has left

  435. krauq has left

  436. krauq has joined

  437. Syndace has joined

  438. dwd has left

  439. daniel has left

  440. daniel has joined

  441. dwd has joined

  442. dwd

    Oh. I found an actual bug in MUC.

  443. MattJ

    I'm all ears

  444. Ge0rG

    No way!

  445. jonas’

    Just one?

  446. dwd

    Well, sorta, anyway. When a client drops, it sends unavailable to the MUC automatically because Magic(tm) on the server.

  447. ta has left

  448. dwd

    But if the MUC switches nickname on join (210 code stuff), then the directed presence recorded on the server is wrong, and the user never leaves.

  449. jonas’


  450. MattJ

    Oh, that one

  451. jonas’

    that’s a known issue

  452. jonas’

    servers need to track nickname changes for that :)

  453. dwd

    I'd seen it with nickname changes, but it didn't occur to me (for some reason) it'd happen with nickname enforcing.

  454. Ge0rG

    Why can't we just implement MUC proxies on the server.

  455. Ge0rG

    That really would solve 99% of MUC's problems, in a backward compatible manner

  456. Ge0rG

    Zash even wrote a POC already.

  457. Ge0rG

    It's got some minor drawbacks, like you can't ever leave a MUC.

  458. Alex has left

  459. fippo

    ge0rg: i think one of the dmuc proposals took that approach

  460. jonas’

    which is fun, by the way, because it means that the user’s server needs to support MUC for it to work properly :-)

  461. jonas’

    which reminds me of MIX

  462. jonas’

    except that with MUC, this requirement is hidden and not spelt out and you can join a MUC without that requirement fulfilled and have it work to a certain extent and then run in weird edge cases :)

  463. Valerian has joined

  464. Ge0rG

    jonas’: you mean the weird edge cases we cope with every day now?

  465. Ge0rG

    Like never leaving a MUC if you changed your nickname?

  466. jonas’


  467. Ge0rG

    The awesome thing about MUC Proxy would be that it's 100% transparent to the clients and can be rolled out in an instant as an upgrade to fix most of the issues.

  468. Ge0rG

    Also could include offline notifications and other nice things.

  469. ralphm has left

  470. Zash has left

  471. Zash has joined

  472. Zash has left

  473. marc has joined

  474. Zash has joined

  475. Zash has left

  476. jonas’


  477. Zash has joined

  478. jonas’

    it would be somewhat like biboumi but for xmpp

  479. Zash has left

  480. jonas’

    and looking at the quirks which still are there with persistency and biboumi, I’m not sure it’s as easy as you make it out to be

  481. Zash has joined

  482. Ge0rG

    jonas’: the quirks are there because the biboumi developers violently refuse to accept what's good design and practice.

  483. Valerian has left

  484. jonas’

    hm, where?

  485. matlag has left

  486. grumpy has left

  487. Zash has left

  488. dwd has left

  489. Ge0rG

    jonas’: like where they send you individual messages to all of your resources with Carbons disabled?

  490. jonas’

    what would be a better way?

  491. Alex has joined

  492. flow

    I don't see a problem with that either, but I believe it should be the responsiblity of the receiving entity that they messages arrive on all devices (if it whishes so), not of the sending

  493. matlag has left

  494. Valerian has joined

  495. Valerian has left

  496. Valerian has joined

  497. Valerian has left

  498. Ge0rG

    flow: the problem is that if you go offline, your messages get rerouted to a different resource, which ends up with two, three or four copies

  499. Nekit has joined

  500. guusdk has left

  501. flow

    Ge0rG, ahh, ok I see the issue now.

  502. jonas’

    Ge0rG, but on the other hand, relying on carbons would mean that resources which are not interested in those messages (read: not joined in any IRC) get them.

  503. flow

    but wait,

  504. jonas’

    there’s no good solution here

  505. jonas’

    and we’ll have the same issues with MUC proxies.

  506. flow

    you have to go offline while biboumi is sending, otherwhise biboumi won't know of the resource

  507. flow

    Ge0rG, do you experience that a lot?

  508. Ge0rG

    flow: there used to be a long discussion on the biboumi tracker

  509. flow

    with many people reporting to hit that issue of duplicate messages?

  510. Ge0rG

    jonas’: that's the same problem as with MUCs you join from one client only and the PM Carbons.

  511. Ge0rG

    flow: yeah

  512. Ge0rG


  513. jonas’

    Ge0rG, yes

  514. Ge0rG

    > Opened 1 year ago by Jonas Schäfer

  515. jonas’

    > Closed

  516. Ge0rG

    Also https://lab.louiz.org/louiz/biboumi/issues/3304

  517. jonas’

    also Closed

  518. Ge0rG

    jonas’: took some months to convince them.

  519. guusdk has joined

  520. Guus has joined

  521. jonas’

    not für #3277

  522. Zash has left

  523. Ge0rG

    jonas’: I can't find a way to search for comments by me, but I'm sure most of those would be bitching about how the developers don't understand XMPP.

  524. jonas’

    I wouldn’t accuse them of that.

  525. jonas’

    also, they’re still doing great work. I’m fine with the community ironing out the rough edges by filing issues.

  526. Ge0rG

    jonas’: oh, yes they are.

  527. Ge0rG

    biboumi is the best cross-protocol gateway I've ever seen.

  528. jonas’


  529. Ge0rG

    jonas’: the other thing being https://lab.louiz.org/louiz/biboumi/issues/3283

  530. Zash has left

  531. lorddavidiii has joined

  532. efrit has left

  533. l has joined

  534. l has joined

  535. l has joined

  536. jonas’

    Ge0rG, that might be fixed during the refactor mentioned in #3382

  537. Ge0rG

    jonas’: it's not about things being fixed, it's about how hard it is to convince the developers that they _need_ to be fixed.

  538. jonas’

    edge-cases all abound

  539. jonas’

    lots of edge-cases not only means lots of code to write, it also means lots of hard-to-reproduce stuff which will be tricky to nail down and prove.

  540. jonas’

    and we’ll have exactly the same issues with a MUC proxy

  541. Ge0rG

    I'm a certified MUC Corner Case Debugging Engineer.

  542. Zash

    If that's the case, where's your diploma?

  543. fffo881 has joined

  544. fffo881 has left

  545. Ge0rG


  546. lumi has left

  547. Ge0rG has left

  548. Seve

    Good job Ge0rG! You deserve it!

  549. jonas’

    well done

  550. Seve claps

  551. jonas’

    put it on your council application

  552. jonas’ wonders about the significance of that date

  553. Ge0rG

    jonas’: @horazont horazont merged commit b017284 into xsf:master on Mar 8

  554. jonas’

    ah, #stable_id

  555. edhelas

    Ge0rG don't fix too much MUC, we'll not have reasons to work on MIX anymore

  556. Ge0rG

    jonas’: good idea!

  557. Ge0rG

    edhelas: now you uncovered my evil secret plan!

  558. edhelas

    Make MUC Great Again

  559. Zash

    MUC was never great

  560. j.r has left

  561. j.r has joined

  562. tux has joined

  563. labdsf has left

  564. labdsf has joined

  565. lskdjf has joined

  566. moparisthebest has left

  567. lorddavidiii has left

  568. matlag has left

  569. j.r has joined

  570. Guus has left

  571. guusdk has left

  572. j.r has joined

  573. Guus has joined

  574. guusdk has joined

  575. Guus has left

  576. guusdk has left

  577. Guus has joined

  578. guusdk has joined

  579. daniel has left

  580. daniel has joined

  581. Alex has left

  582. pep.

    Who can modify the xsf calendar? To add 35C3

  583. guusdk has joined

  584. guusdk has left

  585. guusdk has joined

  586. alacer has joined

  587. dwd has joined

  588. tux has joined

  589. pep.

    I still have one last voucher btw, if people are interested. Grab it now or it will expire

  590. labdsf has left

  591. dwd has left

  592. alacer has left

  593. lskdjf has joined

  594. SamWhited has joined

  595. !xsf_martin has joined

  596. lovetox has joined

  597. muppeth has left

  598. muppeth has joined

  599. labdsf has joined

  600. lskdjf has left

  601. waqas has joined

  602. waqas has left

  603. ThibG has left

  604. ThibG has joined

  605. waqas has joined

  606. lskdjf has joined

  607. lskdjf has left

  608. grumpy has joined

  609. lskdjf has left

  610. lskdjf has joined

  611. Alex has joined

  612. lskdjf has left

  613. lskdjf has joined

  614. tux has joined

  615. ThibG has left

  616. ThibG has joined

  617. intosi has joined

  618. tux has joined

  619. lumi has joined

  620. Tobias has left

  621. Tobias has joined

  622. ak2085 has joined

  623. vaulor has left

  624. !xsf_martin has joined

  625. lskdjf has joined

  626. vaulor has joined

  627. tux has joined

  628. tux has joined

  629. krauq has joined

  630. edhelas

    In 0060 the <configure/> tag is defined this way <xs:element name='configure'> <xs:complexType> <xs:choice minOccurs='0' xmlns:xdata='jabber:x:data'> <xs:element ref='xdata:x'/> </xs:choice> </xs:complexType> </xs:element>

  631. edhelas

    However I see some <configure node='princely_musings'> in the examples

  632. edhelas

    Shoundn't we add <xs:attribute name='node' type='xs:string' use='required'/> ?

  633. mrdoctorwho has joined

  634. mrdoctorwho has joined

  635. ak2085 has left

  636. lorddavidiii has joined

  637. lorddavidiii has left

  638. mrdoctorwho has joined

  639. Tobias has joined

  640. Tobias has joined

  641. Andrew Nenakhov has left

  642. Andrew Nenakhov has joined

  643. mrdoctorwho has joined

  644. SamWhited has left

  645. genofire has left

  646. Andrew Nenakhov has left

  647. Andrew Nenakhov has joined

  648. l has left

  649. Andrew Nenakhov has left

  650. tux has joined

  651. lskdjf has joined

  652. guusdk has left

  653. guusdk has joined

  654. ThibG has joined

  655. lorddavidiii has joined

  656. sonny has left

  657. guusdk has left

  658. guusdk has joined

  659. ta has left

  660. Andrew Nenakhov has joined

  661. mrdoctorwho has joined

  662. Ge0rG has left

  663. Zash has left

  664. Andrew Nenakhov has left

  665. Andrew Nenakhov has joined

  666. Zash has left

  667. lskdjf has left

  668. lskdjf has joined

  669. moparisthebest has joined

  670. alacer has joined

  671. alacer has left

  672. alacer has joined

  673. Ge0rG

    Our wiki also has a horrible mobile expediency. Pinging I-team

  674. Yagiza has left

  675. guusdk has left

  676. guusdk has joined

  677. labdsf has left

  678. Guus has left

  679. Guus has joined

  680. guusdk has left

  681. guusdk has joined

  682. blabla has left

  683. blabla has joined

  684. guusdk has joined

  685. guusdk has left

  686. guusdk has joined

  687. Guus has left

  688. Zash has left

  689. moparisthebest has joined

  690. dwd has joined

  691. fffo881 has joined

  692. l has joined

  693. fffo881 has left

  694. Andrew Nenakhov has left

  695. Guus has joined

  696. Andrew Nenakhov has joined

  697. UsL has left

  698. UsL has joined

  699. Tobias has joined

  700. vanitasvitae has left

  701. thorsten has joined

  702. lskdjf has left

  703. Steve Kille has left

  704. Steve Kille has left

  705. Tobias has joined

  706. dwd has left

  707. ak2085 has joined

  708. lskdjf has joined

  709. alacer has left

  710. Tobias has joined

  711. lskdjf has joined

  712. blabla has left

  713. blabla has joined

  714. genofire has left

  715. Steve Kille has joined

  716. Tobias has joined

  717. matlag has left

  718. lskdjf has joined

  719. !xsf_martin has joined

  720. ak2085 has left

  721. dwd has joined

  722. dwd has left

  723. labdsf has joined

  724. Steve Kille has left

  725. ak2085 has joined

  726. dwd has joined

  727. mimi89999 has joined

  728. Alex has left

  729. ak2085 has left

  730. dwd has left

  731. Valerian has joined

  732. Guus has left

  733. Guus has joined

  734. Guus has left

  735. Valerian has left

  736. guusdk has left

  737. guusdk has joined

  738. Guus has joined

  739. matlag has left

  740. SamWhited has joined

  741. Guus has left

  742. Guus has joined

  743. guusdk has left

  744. guusdk has left

  745. guusdk has joined

  746. rion has joined

  747. Guus has left

  748. Alex has joined

  749. ralphm

    edhelas: well, not required. If using collections, you also want to be able to configure the root node, which is basically leaving off the node attribute.

  750. valo has joined

  751. Alex has left

  752. ralphm

    Also, you're looking at the wrong namespace. Try pubsub#owner

  753. ralphm

    The one in the regular pubsub node goes together with <create/> where you already have the node reference.

  754. ralphm

    eh, pubsub namespace

  755. edhelas

    ralphm thanks for the precision

  756. edhelas

    my bad

  757. ralphm

    So example 137 vs 140

  758. ralphm

    no worries

  759. ralphm

    I still regret we used multiple namespaces

  760. marc has left

  761. efrit has joined

  762. Guus has joined

  763. guusdk has left

  764. guusdk has joined

  765. l has left

  766. daniel has left

  767. Zash

    The verb another level in is weird too

  768. blabla has left

  769. valo has joined

  770. Zash has left

  771. Zash has joined

  772. Zash has left

  773. Zash has joined

  774. ta has joined

  775. vanitasvitae has left

  776. tux has left

  777. Andrew Nenakhov has left

  778. Andrew Nenakhov has joined

  779. genofire has left

  780. Andrew Nenakhov has left

  781. Andrew Nenakhov has joined

  782. Andrew Nenakhov has left

  783. Andrew Nenakhov has joined

  784. blabla has left

  785. Andrew Nenakhov has left

  786. Andrew Nenakhov has joined

  787. Andrew Nenakhov has joined

  788. j.r has joined

  789. blabla has joined

  790. j.r has joined

  791. Andrew Nenakhov has left

  792. Andrew Nenakhov has joined

  793. Andrew Nenakhov has left

  794. Andrew Nenakhov has joined

  795. Valerian has joined

  796. waqas has left

  797. waqas has joined

  798. Andrew Nenakhov has left

  799. Andrew Nenakhov has joined

  800. Andrew Nenakhov has left

  801. Andrew Nenakhov has joined

  802. Andrew Nenakhov has left

  803. Andrew Nenakhov has joined

  804. Andrew Nenakhov has left

  805. Andrew Nenakhov has joined

  806. Tobias has left

  807. Tobias has joined

  808. vanitasvitae has left

  809. j.r has joined

  810. Andrew Nenakhov has left

  811. Andrew Nenakhov has joined

  812. Andrew Nenakhov has left

  813. Andrew Nenakhov has joined

  814. Andrew Nenakhov has left

  815. alacer has joined

  816. Andrew Nenakhov has joined

  817. alacer has left

  818. alacer has joined

  819. j.r has joined

  820. waqas has left

  821. Guus has left

  822. Guus has joined

  823. Guus has left

  824. Andrew Nenakhov has left

  825. Andrew Nenakhov has joined

  826. moparisthebest has left

  827. sonny has joined

  828. blabla has joined

  829. dedekin has left

  830. dedekin has joined

  831. sonny has joined

  832. rion has left

  833. Alex has joined

  834. rion has left

  835. Guus has joined

  836. alexde has joined

  837. Valerian has left

  838. mrdoctorwho has left

  839. mrdoctorwho has joined

  840. moparisthebest has joined

  841. lorddavidiii has left

  842. marc has joined

  843. efrit has left

  844. rion has left

  845. mimi89999 has joined

  846. waqas has joined

  847. daniel has left

  848. ThibG has left

  849. ThibG has joined

  850. SamWhited has left

  851. Andrew Nenakhov has left

  852. Andrew Nenakhov has joined

  853. marc has left

  854. matlag has left

  855. Nekit has left

  856. Nekit has joined

  857. daniel has left

  858. waqas has left

  859. Zash has left

  860. waqas has joined

  861. genofire has left

  862. lnj has left

  863. Alex has left

  864. ThibG has left

  865. ThibG has joined

  866. labdsf has left

  867. Maranda has left

  868. Zash has left

  869. labdsf has joined

  870. tux has left

  871. matlag has left

  872. Maranda has joined

  873. daniel has left

  874. waqas has left

  875. lskdjf has joined

  876. Guus has left

  877. Guus has joined

  878. Guus has left

  879. l has joined

  880. l has left

  881. marc has joined

  882. MattJ has joined

  883. jjrh has left

  884. jjrh has joined

  885. l has left

  886. lumi has joined

  887. l has joined

  888. lskdjf has joined

  889. lskdjf has joined

  890. Guus has joined

  891. j.r has joined

  892. j.r has joined

  893. sonny has joined

  894. sonny has joined

  895. l has left

  896. efrit has joined

  897. Guus has left

  898. Guus has joined

  899. dwd has joined

  900. alexde has left

  901. Guus has left

  902. dwd has left

  903. Guus has joined

  904. Nekit has joined

  905. marc has left

  906. vanitasvitae has left

  907. l has left

  908. l has joined

  909. !xsf_martin has left

  910. dedekin has left

  911. dedekin has joined

  912. dedekin has left