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. /Special:Upload
  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 *one
  251. Ge0rG By that logic, with CSI we should reorder messages so that same-channel messages are sent consecutively
  252. dwd *sigh*
  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 F
  289. dwd G
  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’ ok
  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’ good
  325. flow I just want to point out that it also increases efficiency in other areas
  326. jonas’ true
  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 Yay.
  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 XER
  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’ meh
  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 CBOR!
  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’ matroshka?
  390. jonas’ matroshka!
  391. Ge0rG dwd: I'd go with DER for lesser ambiguity
  392. dwd has left
  393. dwd has joined
  394. Zash PER?
  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’ yeah
  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’ yes
  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’ yes
  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’ mh
  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 https://lab.louiz.org/louiz/biboumi/issues/3277
  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’ indeed.
  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 https://op-co.de/tmp/MUC-CCDE.jpg
  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