XSF Discussion - 2017-02-16

  1. Lance has left
  2. stpeter has joined
  3. mancho has left
  4. jere has joined
  5. jere has joined
  6. vurpo has left
  7. vurpo has joined
  8. vurpo has left
  9. vurpo has joined
  10. mancho has left
  11. goffi has left
  12. goffi has left
  13. vurpo has left
  14. stpeter has left
  15. waqas has left
  16. Steve Kille has left
  17. Kev has left
  18. Kev has left
  19. Steve Kille has joined
  20. Kev has left
  21. Kev has left
  22. Steve Kille has left
  23. Kev has left
  24. Kev has left
  25. Kev has joined
  26. Steve Kille has joined
  27. Kev has left
  28. kalkin has left
  29. kalkin has joined
  30. uc has joined
  31. vurpo has left
  32. jere has left
  33. jere has joined
  34. kalkin has left
  35. daniel has left
  36. mancho has left
  37. mancho has joined
  38. jere has left
  39. kalkin has joined
  40. Sonny has left
  41. daniel has joined
  42. vurpo has left
  43. vurpo has joined
  44. Sonny has joined
  45. daniel has left
  46. kalkin has left
  47. waqas has joined
  48. daniel has joined
  49. waqas has left
  50. mancho has left
  51. vanitasvitae has joined
  52. waqas has joined
  53. mancho has joined
  54. mancho has left
  55. mancho has joined
  56. vurpo has left
  57. vurpo has joined
  58. kalkin has joined
  59. vurpo has left
  60. Sonny has left
  61. nyco has joined
  62. SamWhited has left
  63. Valerian has joined
  64. Valerian has left
  65. Guus has left
  66. Guus has joined
  67. waqas has left
  68. Guus has left
  69. Guus has joined
  70. moparisthebest has joined
  71. mimi89999 has left
  72. mimi89999 has left
  73. mimi89999 has joined
  74. sezuan has left
  75. xnyhps has left
  76. Tobias has left
  77. Guus has left
  78. Guus has joined
  79. Guus has left
  80. Guus has joined
  81. intosi has left
  82. intosi has joined
  83. kalkin has left
  84. vurpo has left
  85. vurpo has joined
  86. xnyhps has left
  87. kalkin has joined
  88. daniel has left
  89. Guus has left
  90. Guus has joined
  91. kalkin has left
  92. vurpo has left
  93. vurpo has joined
  94. daniel has joined
  95. jere has joined
  96. xnyhps has left
  97. xnyhps has left
  98. xnyhps has left
  99. xnyhps has left
  100. xyz has joined
  101. bjc has joined
  102. Guus has left
  103. Guus has joined
  104. moparisthebest has left
  105. moparisthebest has joined
  106. jcbrand has joined
  107. Ge0rG If I'll ever going to write a server-side PARS [xep 379], I'll call it SPARSE: Server-side Pre-Authenticated Roster Subscription Emission.
  108. vurpo has left
  109. vurpo has joined
  110. xyz has left
  111. kalkin has joined
  112. xyz has joined
  113. blipp has left
  114. winfried has joined
  115. xyz has left
  116. jonasw is the board meeting *still* going on? *glances at topic*
  117. Guus has a Summit 21 flashback: https://imgflip.com/i/1jqylr
  118. jonasw :D
  119. vurpo has left
  120. vurpo has joined
  121. Valerian has joined
  122. Steve Kille has left
  123. winfried has left
  124. winfried has joined
  125. xyz has joined
  126. vurpo has left
  127. Steve Kille has joined
  128. vurpo has joined
  129. jubalh has joined
  130. jubalh has left
  131. Martin has joined
  132. suzyo has joined
  133. vurpo has left
  134. vurpo has joined
  135. vurpo has left
  136. vurpo has joined
  137. nyco has joined
  138. kalkin has left
  139. Ge0rG Guus: ha, so awesome!
  140. vurpo has left
  141. vurpo has joined
  142. vurpo has left
  143. vurpo has joined
  144. goffi has joined
  145. Ge0rG And so I added 'MUC subject' to https://wiki.xmpp.org/web/Usability/Glossary
  146. Sonny has joined
  147. winfried has left
  148. goffi has left
  149. goffi has joined
  150. Tobias has left
  151. Tobias has joined
  152. Ash has joined
  153. sezuan has left
  154. winfried has joined
  155. kalkin has joined
  156. vurpo has left
  157. vurpo has joined
  158. vurpo has left
  159. vurpo has joined
  160. vurpo has left
  161. vurpo has joined
  162. kalkin has left
  163. jubalh has joined
  164. xyz has left
  165. Flow has joined
  166. Zash has joined
  167. Guus has left
  168. pep. has joined
  169. Ge0rG should section1 and section2 headings in XEPs be capitalized?
  170. Ge0rG actually any headings.
  171. xyz has joined
  172. xnyhps has left
  173. xnyhps has left
  174. kalkin has joined
  175. Flow I have started working on ISR-SASL2. In case you want to have a look at the first alpha quality draft and provide early feedback: http://geekplace.eu/xeps/xep-isr-sasl2/xep-isr-sasl2.html
  176. xyz has left
  177. xyz has joined
  178. winfried has left
  179. jcbrand has left
  180. nyconyco has joined
  181. jcbrand has left
  182. xyz has left
  183. xyz has joined
  184. Sonny has left
  185. Sonny has joined
  186. jcbrand has joined
  187. Sonny has left
  188. Sonny has joined
  189. dwd Flow, Just submit it.
  190. xyz has left
  191. winfried has left
  192. jonasw Flow: nitpick > It MUST not contain whitespace characters. that should probably be MUST NOT
  193. winfried has left
  194. dwd Also I still dislike the term "Nonza".
  195. nyco dwd, "wtf-za" is better
  196. nyco nyco, of "stream first-born child", maybe... or not
  197. dwd nyco, "Element" is suitable in almost every case, and a term of art much more widely known.
  198. nyco dwd, nah too simple
  199. Ge0rG dwd: aren't elements the things you can stuff into your messages?
  200. dwd nyco, I just dislike inventing jargon for the sake of it.
  201. jonasw it would have to be stream-level elements to be precise, and that’s long
  202. Ge0rG let's abbreviate Stream-Level Element as SLE and call it a SLEnza.
  203. dwd jonasw, Only in cases where the distinction is needed.
  204. dwd jonasw, I mean, we use "session" quite happily in multiple senses, and we use "node" pretty much everywhere. I don't understand why we needed to have a made-up word for "non-routable stream-level element".
  205. nyco Stream Level Anti Stanza Hop (SLASH)
  206. Ge0rG dwd: because ambiguous protocol references are ambiguous.
  207. dwd Ge0rG, Sure. But what's ambiguous about, for example "followed by a <authenticate/> element", as opposed to using a made-up word?
  208. Ge0rG I don't like the specific word very much either, but at least it is a well-defined term for a well-defined thing in XMPP, which makes it much better than much of our other terminology.
  209. Kev I dislike nonza fairly intensely :)
  210. Kev For much the same reason, it's inventing a word that doesn't need inventing.
  211. Ge0rG If you read the intro to https://tools.ietf.org/html/rfc6120#section-8 then you'll realize that nonzas are stanzas, too.
  212. jonasw huh, I thought that stanzas are limited to the jabber:{client,server} namespaces?
  213. jubalh has left
  214. jonasw and also {iq,message,presence} possibly
  215. dwd jonasw, And XEP-0114. Two namespaces defined there.
  216. Alex has joined
  217. Ge0rG jonasw: "either party can send XML stanzas. Three kinds of XML stanza are defined for the 'jabber:client' and 'jabber:server' namespaces: <message/>, <presence/>, and <iq/>." - the spec doesn't claim this to be an exhaustive list of stanzas.
  218. nyconyco has left
  219. jonasw well, okay, but that doesn’t mean that any stream-level element is a stanza, does it, Ge0rG?
  220. dwd Ge0rG, Right. And XEP-0360 simply says everything not a stanza is a nonza.
  221. Ge0rG oh, §4.1 is the important one: Definition of XML Stanza: An XML stanza is the basic unit of meaning in XMPP. A stanza is a first-level element (at depth=1 of the stream) whose element name is "message", "presence", or "iq" and whose qualifying namespace is 'jabber:client' or 'jabber:server'.
  222. dwd Ge0rG, Except that's not true.
  223. Zash What about jabber:component:something
  224. Ge0rG By contrast, a first-level element qualified by any other namespace is not an XML stanza (stream errors, stream features, TLS-related elements, SASL-related elements, etc.), nor is a <message/>, <presence/>, or <iq/> element that is qualified by the 'jabber:client' or 'jabber:server' namespace but that occurs at a depth other than one (e.g., a <message/> element contained within an extension element (Section 8.4) for reporting purposes), nor is a <message/>, <presence/>, or <iq/> element that is qualified by a namespace other than 'jabber:client' or 'jabber:server'. An XML stanza typically contains one or more child elements (with accompanying attributes, elements, and XML character data) as necessary in order to convey the desired information, which MAY be qualified by any XML namespace (see [XML-NAMES] as well as Section 8.4 in this specification).
  225. Zash For XMPP 2.0, can we just use a single namespace?
  226. Ge0rG it goes on!
  227. Ge0rG dwd: what's not true?
  228. dwd Ge0rG, As Zash says, XEP-0114 carries stanzas in other namespaces.
  229. intosi dwd: no ends of fun because of it.
  230. Ge0rG dwd: 0114 is historical. It doesn't even count. And even if it did, it were wrong, because 6120§4.1
  231. Kev I don't think jabber:(client|server|component) adds anything useful to the protocol that I can see, over a single one.
  232. dwd Ge0rG, A better definition would be that stanzas are stream-level XML elements, with local names "iq", "message", or "presence", within the content namespace of the stream, which may be routed without additional negotiation over other connections (and namespaces).
  233. dwd Ge0rG, But much of that is reversing the defition of a Nonza in XEP-0360.
  234. dwd Kev, No, I agree. It's a distcintion that proves more annoying than useful.
  235. Ge0rG from 114: "Once authenticated, the component can send stanzas through the server and receive stanzas from the server. All stanzas sent to the server MUST possess a 'from' attribute and a 'to' attribute, as in the 'jabber:server' namespace." - I don't even see how this is violating the Stanza definition
  236. Zash The Default Namespace
  237. intosi Kev: +1
  238. Tobias has left
  239. Tobias has joined
  240. Ge0rG dwd: having different terms for routable, standardized stream elements vs. unroutable negotiated ones is very useful. Please rephrasse your critique in a way that still allows for this distinction, without writing out "non-routable top-level stream-elements" every time.
  241. dwd Ge0rG, I'll do so when you can answer the question about when such a precise distinction is warranted above.
  242. dwd Ge0rG, Even when we need to talk about stream-level elements other than stanzas, we can do so clearly (as I just have).
  243. dwd Ge0rG, That, incidentally, requires no reference or document to support it. Whereas even someone well-versed in the RFCs, who has read and implemented a number of XEPs, will not know what "Nonza" means without further reading.
  244. Ge0rG From 0198: "To enable use of stream management, the client sends an <enable/> command to the server." - it's using "command", which is ambiguous and makes me think of ad-hoc commands. There is merely a single mention that 0198 is using not-stanzas at the root level.
  245. Kev Sure, it should say 'element' instead of 'command'.
  246. Kev It doesn't need to say nonza.
  247. Ge0rG dwd: The benefit of "nonza" is actually that the word itself, being a portmanteau of not-stanza, is easy to remember and even to guess from context.
  248. Ge0rG 0198 obviously pre-dates the term. My point is that our specs are ambiguous, and that the term helps reducing the ambiguity
  249. Zash It's kinda like abstracting some code into a function
  250. Zash Silly term tho
  251. Ge0rG Kev: it should say 'top-level element', or 'root-level element', so it won't be confused with a <message> or <iq> element.
  252. Kev If anyone reads "an <enable/> element" and thinks "I think it means a <message/> stanza", then I doubt their ability to understand any other part of the stack they need to implement.
  253. dwd Ge0rG, You';re right. I'm convinced by all those people who implemented '198 as an ad-hoc command.
  254. Ge0rG well then, looks like we are done here.
  255. Ge0rG Now, what term do I need to search for if I want to get a list of all XEPs that define new non-routable root-level stream elements?
  256. Ge0rG Okay, enough time spent on bikeshedding today. Another XEPs PR is waiting to be completed.
  257. Ge0rG SamWhited: would you still like to have a revision block added to #413?
  258. Piotr Nosek has joined
  259. Bunneh has left
  260. Bunneh has joined
  261. Zash Howabout #413
  262. Bunneh Zash: XEP-280: Improve readability #413 https://github.com/xsf/xeps/pull/413
  263. Ge0rG Bunneh doesn't like me.
  264. Zash Wasn't enabled for this room
  265. Ge0rG Zash: That's what you say. I tell you: robot discrimination can go both ways.
  266. Flow What Ge0rg said.
  267. winfried has left
  268. Flow Also you all had enough time to suggest a term for xep360. :-P It's not like I care about the exact name. But I agree with everything Ge0rg said. A definition for non-stanza top level stream elements was truly missing.
  269. Valerian has left
  270. xyz has joined
  271. Ge0rG Flow: sorry, you missed the discussion. But the XEP-0368 LC on standards@ could use some more bikeshedding.
  272. Sonny has left
  273. Sonny has joined
  274. Flow Ge0rG: I disagree with everything said in that thread, including what I said myself there
  275. Ge0rG Flow: that'd make a great follow-up post.
  276. goffi has left
  277. Ge0rG Also, 0368 needs a pre-Direct-TLS nonza to inform the other party of an imminent connection security upgrade.
  278. Flow jonasw: Thanks for the hint :)
  279. Flow Ge0rG: I do believe SASL2 probably could do that :)
  280. Sonny has left
  281. Zash No what we really should do is make SASL a TLS extension!!
  282. Ge0rG Zash: yay! We could use SNI to send our bare-JID and encode the password in ALPN!
  283. Zash YES!
  284. Ge0rG +also
  285. Zash And use session tickets instead of 198
  286. jonasw this doesn’t sound like a bad idea at all!
  287. Ge0rG What is the correct way to attribute XEP changes to external authors? the <initials> element of the <revision> element looks like it's not sufficient.
  288. Ge0rG Flow: wow, that was blazing fast. re #423
  289. Bunneh Flow: XEP-0379: Added "Usability Considerations", removed actual XMPP client, some text editing. #423 https://github.com/xsf/xeps/pull/423
  290. Ge0rG 30 minutes between PR and merge. New record :)
  291. Sonny has joined
  292. Valerian has joined
  293. jonasw Ge0rG: are you working on 0280 currently?
  294. Ge0rG jonasw: yes
  295. jonasw s/elible/eligible/ in the revision history, if that’s legit
  296. jonasw has left
  297. Ge0rG jonasw: thanks, added
  298. Ge0rG that 0.10 block is a good example for what I asked above, btw.
  299. xyz has left
  300. xyz has joined
  301. Ge0rG Flow, SamWhited: we need to update the "XMPP Extensions Editor" email template to link to https://xmpp.org/ instead of http://
  302. Sonny has left
  303. Sonny has joined
  304. Flow I first want to know what is missing in xep-README that is preventing your updated version to appear at xmpp.org
  305. Sonny has left
  306. Sonny has joined
  307. Sonny has left
  308. Sonny has joined
  309. Sonny has left
  310. Sonny has joined
  311. suzyo has left
  312. suzyo has joined
  313. jubalh has joined
  314. daniel has left
  315. daniel has joined
  316. jubalh has left
  317. xyz has left
  318. xyz has joined
  319. vanitasvitae has joined
  320. daurnimator has left
  321. xyz has left
  322. xyz has joined
  323. daniel has left
  324. daniel has joined
  325. daniel has left
  326. daniel has joined
  327. daniel has left
  328. daniel has joined
  329. xnyhps has left
  330. daniel has left
  331. daniel has joined
  332. xnyhps has left
  333. Sonny has left
  334. Sonny has joined
  335. Sonny has left
  336. Sonny has joined
  337. Ge0rG Flow: if you want to try another attempt: https://github.com/xsf/xeps/pull/413 is ready to merge now.
  338. Sonny has left
  339. vanitasvitae has left
  340. jcbrand has left
  341. jonasw Ge0rG: the inversion of SHOULD to MUST NOT should *probably* be mentioned in the changelog
  342. jonasw ah it is
  343. jonasw nevermind
  344. xyz has left
  345. xyz has joined
  346. Piotr Nosek has left
  347. Piotr Nosek has joined
  348. jcbrand has joined
  349. waqas has joined
  350. Piotr Nosek has left
  351. xnyhps has left
  352. Sonny has joined
  353. daniel has left
  354. daniel has joined
  355. Sonny has left
  356. Piotr Nosek has joined
  357. Tobias has joined
  358. Piotr Nosek has left
  359. daniel has left
  360. daniel has joined
  361. kalkin has left
  362. Tobias has joined
  363. Tobias has joined
  364. kalkin has joined
  365. xnyhps has left
  366. Zash has left
  367. Zash has joined
  368. jere has left
  369. jere has joined
  370. Kev has left
  371. Kev has left
  372. Kev has joined
  373. xyz has left
  374. xyz has joined
  375. vurpo has left
  376. vurpo has joined
  377. Sonny has joined
  378. Kev has left
  379. Kev has left
  380. Kev has joined
  381. Kev has left
  382. jere has left
  383. vurpo has left
  384. vurpo has joined
  385. xnyhps has left
  386. vurpo has left
  387. vurpo has joined
  388. Sonny has left
  389. jere has joined
  390. Sonny has joined
  391. xyz has left
  392. xyz has joined
  393. daniel has left
  394. daniel has joined
  395. uc has left
  396. uc has joined
  397. daniel has left
  398. daniel has joined
  399. Sonny has left
  400. Sonny has joined
  401. Sonny has left
  402. Sonny has joined
  403. Piotr Nosek has joined
  404. SamWhited Aww man, all the good rants get taken before I'm a awake: Nonza always just seems like needless tribal knowledge to me too.
  405. Sonny has left
  406. jonasw I like nonzas.
  407. Ge0rG This is a clear case of majority-vote-needed. Just let us trump it down properly.
  408. jonasw speaking of which, is "yes we can make xmpp great again" a better slogan than simply "make xmpp great again"?
  409. Sonny has joined
  410. xyz has left
  411. xyz has joined
  412. dwd jonasw, Twice as presidential.
  413. Sonny has left
  414. Sonny has joined
  415. Ge0rG so much bikeshedding. So little actual input.
  416. dwd "Make Britain Great Again" was the slogan under which Thatcher first stood as an MP.
  417. dwd (It was Churchill's reelection campaign, actually - he won).
  418. Zash I quite like "Make America Great Britain Again"
  419. Ge0rG Now that #413 is as-good-as-approved, I'm going to push forward with my threats from https://mail.jabber.org/pipermail/standards/2017-January/032048.html re MUC-PMs in 45 and 280.
  420. Bunneh Ge0rG: XEP-280: Improve readability #413 https://github.com/xsf/xeps/pull/413
  421. Ge0rG I'd really like to hear Kev and dwd on that.
  422. dwd It's a huge rewrite.
  423. dwd Which is probably a good thing, but it does mean going over it carefully.
  424. Ge0rG dwd: what is a huge rewrite?
  425. dwd #413 - seems to make a lot of changes to normative language.
  426. Bunneh dwd: XEP-280: Improve readability #413 https://github.com/xsf/xeps/pull/413
  427. dwd Bunneh, Thanks.
  428. jonasw Ge0rG: FWIW, what you wrote regarding MUC-PMs seems reasonable to me, but I haven’t looked in detail yet. also it seems really a server-implementor specific thing, so I cannot really give feedback :/
  429. Ge0rG dwd: I'd like to hear you on https://mail.jabber.org/pipermail/standards/2017-January/032048.html and not on the almost-approved PR, thanks
  430. xyz has left
  431. xyz has joined
  432. jcbrand has left
  433. suzyo has left
  434. daniel has left
  435. daniel has joined
  436. goffi has joined
  437. mancho has left
  438. Piotr Nosek has left
  439. xyz has left
  440. mimi89999 has left
  441. waqas has left
  442. waqas has joined
  443. waqas has left
  444. Ash has left
  445. Kev has left
  446. Steve Kille has left
  447. Kev has left
  448. Steve Kille has joined
  449. Kev has joined
  450. Valerian has left
  451. Valerian has joined
  452. waqas has joined
  453. Sonny has left
  454. Sonny has joined
  455. winfried has left
  456. waqas has left
  457. vurpo has left
  458. vurpo has left
  459. vurpo has left
  460. xyz has joined
  461. vurpo has left
  462. jonasw is there any … information material which shows why matrix is uncool?
  463. waqas has joined
  464. moparisthebest well re-inventing the wheel is uncool
  465. dwd jonasw, They spent a huge amount of time and money telling the world that XMPP was terrible.
  466. MattJ moparisthebest, that's why XMPP should have just been IRC :)
  467. dwd jonasw, They've stopped that now, mostly. But they still have lots of time and money to spend on publicity. We really need to catch up.
  468. goffi the protocol itself and work done is interesting, my main grief against them is there attitude against XMPP community (it is still visible in the F.A.Q.), and also I'm naturally suspicious with corporate stuff.
  469. dwd goffi, Right, it's still a single company, with a lot of money, pushing their proprietary solution. It's more open than, say, WhatsApp, but not much.
  470. goffi and if we have to compare, I think it's extensibility is a good think in opposition to what they say (that monolitic is better)
  471. moparisthebest MattJ, well IRC didn't federate and had other problems
  472. goffi dwd: I don't say it's not open, I'm just suspicious and I'm more confident with XMPP workflow (which is not perfect either), were I know I can have my word to say
  473. moparisthebest matrix is just xmpp re-written in a less extensible manner with json and webservices meh
  474. goffi it's impressive to see the number of clients/libraries available they already have after 2 years and something
  475. goffi -available
  476. dwd moparisthebest, No, there are some fundamental differences. Mostly that domains are not autonomous.
  477. Tobias moparisthebest, and a different data model, not? doesn't it use a tree structure to distribute messages instead of just routing XML pieces like XMPP?
  478. dwd goffi, Yes. Mindshare is important, as is being able to devote some cash to good examples.
  479. Tobias dwd, domains not being autonomous? what do you mean by that?
  480. jonasw oh great. people complaining about XMPP because it loses messages on mobile. you ask what client they use, they say xabber.
  481. mancho has left
  482. dwd jonasw, Yeah. Matrix don't have this problem because the pool is very small, so far.
  483. dwd Tobias, Chatrooms don't live on one domain exclusively, so aren't under single control.
  484. Tobias ahh...so they have federated MUC built in
  485. goffi dwd: that can be a good or bad thing
  486. dwd Tobias, Sort of. FMUC and friends operate on the principle that there is a source of truth, or else that a sort of semi-independence can be achieved.
  487. goffi single control may be needed in some case (enforcing policy for instance), avoiding single point of failure is nice for popular public room
  488. dwd Tobias, Matrix operates on the notion that there is no single source of truth,
  489. goffi how do message deletion/modification works on Matrix?
  490. dwd goffi, Well, XMPP has supported clustered services for years, so there's no *single* point of failure, but the entirety of control resides within a single autonomous domain.
  491. dwd goffi, I have no clue.
  492. intosi git commit --allow-empty -m 'Hello world!'
  493. intosi git push
  494. dwd goffi, I also have never quite worked out how your server knows to stop mirroring the entire chatroom if ever you leave it.
  495. intosi dwd: despite asking them, right?
  496. dwd intosi, I can't decide if that's an ironic statement or a wrong window.
  497. Ge0rG dwd: I'd really like to get your 2¢ on the MUC-PM thing.
  498. daniel goffi: that's probably something they will add an extension - aehm I mean module - to their monolithic spec for later on
  499. dwd daniel, Right, they don't do extensions. They do fork-lift upgrades.
  500. goffi couldn't Matrix be used as a distributed database for XMPP ? Data replication is interesting for directory.
  501. dwd intosi, And yes, I did ask them, once. I can't even recall the answer, though.
  502. goffi or put in other words, would it be possible (and yes it would) to implement a similar thing in XMPP?
  503. jonasw has left
  504. dwd goffi, Oh, sure.
  505. jonasw has left
  506. SamWhited Ge0rG: ++ ; thanks for the first "Usability Considerations" section; looking forward to reading that (and Flow ++ for getting it merged so quickly!)
  507. Ge0rG SamWhited: half of it was in the XEP already, part under "Business", part under "Security"
  508. Guus has left
  509. Ge0rG SamWhited: Flow performed the magic, but https://xmpp.org/extensions/xep-0379.html wasn't immediately updated. He wondered why.
  510. Ge0rG SamWhited: also you can merge #413 now, we've provided the <revision> block (plus some revision typos)
  511. Bunneh SamWhited: XEP-280: Improve readability #413 https://github.com/xsf/xeps/pull/413
  512. Ge0rG SamWhited: and I'd like to move on with my 0280 rewrite ;)
  513. SamWhited Ge0rG: Thanks, let me go merge that now before I get too deep into the weeds with my day job.
  514. Ge0rG SamWhited: yay!
  515. SamWhited When you say, "wasn't immediately updated", what actually happened?
  516. Ge0rG SamWhited: I have no idea beyond "12:49:16 Flow> I first want to know what is missing in xep-README that is preventing your updated version to appear at xmpp.org"
  517. Tobias i think it requires action from the XEP editor to rerender
  518. Ge0rG SamWhited: btw, I've also encouraged @penguineer to make another PR to xeps/README, describing the contribution process
  519. SamWhited yah, I'm not sure what that means; is the README not up to date? Maybe I just forgot to update it last time I tweaked things.
  520. SamWhited I wouldn't add anything people need to be able to discover easily to xep-README; it's just a bunch of technical details for the editors so that we don't forget how to do things
  521. Flow I found out why I failed, everything is fine now
  522. Ge0rG SamWhited: not sure about your version of the README, but the one I see on github is a bunch of links and two hints about the makefile, nothing about the editorial process
  523. SamWhited Oh, that readme, sorry, different thing.
  524. Ge0rG I have no idea how the editorial process looks like or whether it should be public.
  525. SamWhited Ge0rG: It's public, it's just probably not something we want to point people too; it's not really written to be consumable or easy to follow.
  526. Piotr Nosek has joined
  527. SamWhited Yah, I'm sure the GitHub README could be improved; PRs welcome :)
  528. Ge0rG SamWhited: TBH, I don't care too much about how it looks, as long as onboarding new editors works sufficiently well for them.
  529. SamWhited Maybe we should just merge the two and just have the markdown readme *be* the editor readme.
  530. SamWhited Although I don't think it will generate a nice table of contents for you, so maybe that would be harder.
  531. xnyhps has left
  532. Ge0rG SamWhited: I think the README.md should be aimed at contributors first, not at editors.
  533. SamWhited Ge0rG: Yah, you're right
  534. xnyhps has left
  535. Ge0rG SamWhited: it's okay to cover editorial tasks further down, but it's not a prio for me
  536. xnyhps has left
  537. intosi Editors have xep-README.*, right?
  538. Ge0rG SamWhited: and the email template needs to be https'ed.
  539. SamWhited intosi: Yup: https://xmpp.org/extensions/xep-README.html
  540. xnyhps has left
  541. Ge0rG wow, that file is impossible to discover :D
  542. SamWhited I mean, it's not supposed to be hidden, it's just not listed or linked anywhere really
  543. Ge0rG which is not a problem probably.
  544. SamWhited and is full of confusing details and incorrect information that I haven't updated yet :)
  545. SamWhited Yah, not a problem as long as contribution details don't go in there (but that was just me getting my README's confused)
  546. Ge0rG All of this meta talk reminds me that I still need an XML schema for 0379. And I'd love to get that contributed by somebody more familiar with schemas
  547. SamWhited is pretty sure it's the editors job to help with that…
  548. SamWhited runs away and hides.
  549. Kev Editor's job to write schemas for people? No, I don't think so.
  550. Kev Something the authors need to do before Draft.
  551. SamWhited Oh? In that case, nevermind, I'm happy :) thought I read somewhere that if you needed help with the schema the editor was supposed to provide it.
  552. SamWhited XEP-0143:
  553. SamWhited > The XMPP Extensions Editor team can assist you in defining an XML Schema for the protocol you are proposing
  554. Kev Maybe I misremember, it happens sometimes.
  555. SamWhited hides again.
  556. Kev Oh, help, yes. But not to write the thing.
  557. intosi Or point you to the nearest person who hasn't lost sanity yet?
  558. SamWhited Kev: I did say "editors job to help with that", not "to write that" :)
  559. Kev You did.
  560. Ge0rG I've lost my sanity a long time ago. Help me please.
  561. waqas has left
  562. Kev I got the wrong end of the piece of rope's back.
  563. intosi The frayed end?
  564. Ge0rG https://xmpp.org/extensions/xep-README.html#updating references an announce.py. Is that part of https://github.com/xsf/xmpp.org ?
  565. Ge0rG Kev: I'd also like to hear your opinion on https://mail.jabber.org/pipermail/standards/2017-January/032048.html before I start writing PRs.
  566. SamWhited Ge0rG: https://github.com/xsf/xeps/blob/master/announce.py
  567. Ge0rG SamWhited: thanks
  568. waqas has joined
  569. Ge0rG SamWhited: #424 :D
  570. Bunneh SamWhited: gen-scripts: Encrypt all URLs ;-) #424 https://github.com/xsf/xeps/pull/424
  571. SamWhited Ge0rG: LGTM, thanks.
  572. Tobias although it's not encrypting URLs
  573. Ge0rG Tobias: it's not?
  574. SamWhited No, the URLs are still in plain text :)
  575. Ge0rG damn, that's a security vulnerability. Let me pull a CVE ID fast.
  576. Ge0rG SamWhited: what did you do to change the sha1 of my gen-script commit?
  577. xyz has left
  578. SamWhited Ge0rG: Used GitHub to merge it instead of doing it myself (which is always a mistake)
  579. Zash I go for one short walk in the sun and I get back to a bazillion messages?
  580. Ge0rG SamWhited: it wasn't even a merge, it rather looks like a rebase. Generally I like rebase more, but it could have been a fast-forward
  581. SamWhited With GitHub you get your choice of: Add a worthless merge commit with some useless default message, change the hash and get a useless merge commit with a default message, or just change the hash.
  582. Sonny has left
  583. Sonny has joined
  584. intosi We need more options.
  585. SamWhited Ge0rG: Yah, I agree, this is why I normally don't use GitHub's web interface
  586. Ge0rG SamWhited: I don't mind it at all, I just wondered. Thanks.
  587. Zash Re Matrix: If they do what I think they should, based on what I've heard (because their docs are terrible), it's all basically MAM queries all the time.
  588. SamWhited Ge0rG: Good eye though; I'm impressed you noticed :)
  589. Ge0rG SamWhited: Switched to branch 'master' Your branch and 'xsf/master' have diverged, and have 1 and 2 different commits each, respectively.
  590. Ge0rG SamWhited: (actually, I saw it in gitk, but this is just a minor thing)
  591. Ge0rG My other project's git history looks like a map of the London Underground. I appreciate linear histories.
  592. Ge0rG (which now reminds me of that one Linux commit that is octomerging 60 different branches)
  593. winfried has left
  594. Zash Should have stuck with Mercurial
  595. Zash It doesn't even allow more than 2 parents :)
  596. Ge0rG Zash: because a series of 60 merge commits is much cleaner than one octomerge? (usually, project that do either are seriously broken)
  597. Zash Or if it does, I have no idea how that would work with the internal data structures I've looked at.
  598. SamWhited Yah, I feel like if you think you need to merge 60 things, you have other problems and choosing a different VCS isn't going to help.
  599. Ge0rG choosing a different VCS was one of the main culprits of the NTPsec fork.
  600. Zash SamWhited: Having a system that allows it does sorta encourage it tho
  601. Ge0rG Zash: I think that hg only was inveted to troll git users.
  602. xyz has joined
  603. Zash Ge0rG: You got it wrong, it was to troll Python 3 users
  604. SamWhited Zash: yah, I agree, octomerge is dumb
  605. Sonny has left
  606. Sonny has joined
  607. Sonny has left
  608. Ge0rG Zash: I'm not part of that audience, but maybe it was meant to troll both.
  609. Zash Probably to troll everyone but SVN users
  610. Sonny has joined
  611. Ge0rG Zash: I have heavily used svn before git, and hg still makes me stumble every time.
  612. SamWhited I heavily used SVN, and then HG, and was absolutely an HG fanboy for a while just because it was my first DVCS. Then I realized that we should have learned from our mistakes, and that literally everything was easier and just worked better in Git and that a few minor foibles about the interface not being very consistent should not be enough to stop me from using it, so I learned it and haven't looked back since.
  613. Zash Maybe it's just the order you learn things in
  614. Zash I used svn first, then git, then hg
  615. Zash I like hg the most
  616. Ge0rG Zash: it's the same order for me, and I really can't stand hg. It's trolling me right into my face: hg: unknown command 'fetch' 'fetch' is provided by the following extension: use "hg help extensions" for information on enabling extensions
  617. Flow MattJ: I assume you saw https://github.com/xsf/xeps/pull/420 ?
  618. Zash Ge0rG: That's your brain on git
  619. Ge0rG Zash: no, that's a program telling me: "I know what you want, but I won't let you do it. Instead, you have to read a dozen pages of my useless manual first"
  620. SamWhited I understand the difference and don't really care between feetch/merge and update/pull, but that specific example aside I do agree that the extension thing always pisses me off.
  621. Zash Ge0rG: I could say the same thing about all the times I've done git pull and wondered why the heck it did a merge
  622. Ge0rG What about a friendly "hg fetch is provided by the 'fetch' extension. Activate? (Y/n)"
  623. Piotr Nosek has left
  624. SamWhited Oh, I just don't like the idea that it has extensions at all (I mean, in a sense Git does too, but it's not actually a thing you're supposed to make generic extensions against, it's just how commands work internally)
  625. SamWhited Not to say that people can't write their own tools to manipulate stuff, I just don't like that it's built right in and it will actually try to get you to use them.
  626. Zash Ge0rG: Here, it yells that fetch is deprecated
  627. winfried has left
  628. winfried has joined
  629. xyz has left
  630. Sonny has left
  631. Ge0rG Is there any other Elder whom I can summon to be enlightened about the interaction of MUCs, PMs and Carbons?
  632. Zash Elders predate Carbons
  633. Piotr Nosek has joined
  634. Ge0rG Zash: I seriously hope that the Elders predate any of the XMPP protocols.
  635. jcbrand has left
  636. jere has left
  637. jere has joined
  638. Sonny has joined
  639. Sonny has left
  640. Sonny has joined
  641. vurpo has left
  642. vurpo has joined
  643. Piotr Nosek has left
  644. Sonny has left
  645. Sonny has joined
  646. Valerian has left
  647. Piotr Nosek has joined
  648. Piotr Nosek has left
  649. jubalh has joined
  650. Guus has left
  651. sezuan has left
  652. xnyhps has left
  653. waqas has left
  654. xnyhps has left
  655. Sonny has left
  656. Sonny has joined
  657. vurpo has left
  658. vurpo has left
  659. vurpo has joined
  660. vurpo has left
  661. vurpo has joined
  662. jonasw Zash: you replied to Ge0rGs thread that at least two implementations are already tagging outgoing MUC PMs with <x/>. can you tell me which?
  663. jcbrand has joined
  664. Zash jcbrand: Prosody and ejabberd
  665. jonasw you’re not good at tabcompletion today
  666. Zash jonasw: Prosody and ejabberd
  667. Zash I'm not
  668. Zash I blame Kev. Everything is Kevs fault!
  669. jonasw Ge0rG was talking about clients, not servers, I think.
  670. jonasw Zash wrote: > a) Require carbon-enabled clients to tag outgoing MUC-PMs with <x/>, > carbon-copy the 'sent' MUC-PM to all clients, require carbon-enabled > clients to check for <x/> tag and to drop if they are not joined. This > is a 90% solution (it will still display outgoing PMs if you are > joined to the same MUC under different nicknames, as the other client > doesn't know which nickname the 'sent' message came from). I believe at least two implementations do this already.
  671. Zash jonasw: I believe I was talking about servers
  672. Ge0rG Zash: you believe? :P
  673. jonasw ah, oddly quoted then
  674. vurpo has left
  675. vurpo has joined
  676. Zash Ge0rG: bee-hive
  677. jcbrand has left
  678. jubalh has left
  679. tim@boese-ban.de has left
  680. Tobias Zash, you mean bhyve? http://bhyve.org/ :P
  681. mancho has left
  682. Guus has left
  683. jere has left
  684. jere has joined
  685. Piotr Nosek has joined
  686. Vinilox has joined
  687. xyz has joined
  688. vurpo has left
  689. vurpo has joined
  690. xyz has left
  691. xyz has joined
  692. mimi89999 has joined
  693. SamWhited has left
  694. moparisthebest I wrote a kontalk JID hash to phone number lookup service if anyone is interested https://www.moparisthebest.com/phonehash/
  695. moparisthebest more of a fun learning excercise than anything, but you can look up any 1 of 100 billion phone numbers with it in ~2 seconds
  696. waqas has joined
  697. jonasw "kaputt" as we say in germany :)
  698. Zash Phone numbers in what format?
  699. moparisthebest Zash, currently supports currently supports 0-000-000-0000 to 9-999-999-9999, which kontalk hashes like '+00000000000'
  700. Zash So basically +%011d then
  701. moparisthebest so I guess it doesn't support 2 digit country codes or strange formats? it'd be easy to generate files with those then
  702. moparisthebest yes all 11 digit phone numbers
  703. mancho has left
  704. jere has left
  705. jere has left
  706. Valerian has joined
  707. Zash Hm, 2TB of storage required for a rainbow table, or is my math wrong?
  708. moparisthebest Zash, I couldn't find really good resources for rainbow tables, so I don't know :)
  709. moparisthebest this only takes 500gb of storage though because I'm not storing any hashes, just the numbers
  710. Zash What
  711. Zash 10¹¹ * 24B
  712. jonasw (also you could probbaly get away with storing only a unique prefix or part of the hash, reducing the storage needed drastically. after all, a phone number has only 36 bits of entropy)
  713. moparisthebest I explain it all here: https://github.com/moparisthebest/phonehash
  714. Zash 20 byte sha1 output + 4 byte number
  715. moparisthebest 99,999,999,999 won't quite fit in 4 bytes, you need 5, right?
  716. jonasw moparisthebest: nice hack!
  717. jonasw congrats on that idea :)
  718. Zash How many bytes is 64 bits again?
  719. jonasw 8, Zash
  720. moparisthebest yea
  721. Zash Well then
  722. moparisthebest actually iirc that number fits in like 38 bits instead of the 40 bits I'm using
  723. Zash Probably possible to use truncated sha1 hashes, don't think the full output is required to avoid collisions
  724. moparisthebest but unaligned bytes sounded TERRIBLE
  725. Zash Storage is cheap
  726. Zash Maybe I should have done some calculations before attempting to generate this rainbow table in memory
  727. moparisthebest yea but I'm hosting this on my server that only had 800gb of free space hehe
  728. vurpo has left
  729. moparisthebest if someone really cared they could get a huge SSD and it'd be faster
  730. Piotr Nosek has left
  731. vurpo has joined
  732. Zash Build a big B tree or something
  733. moparisthebest but 90 hours for generation on 2 slow spinners in linux software raid1, and then ~2 seconds per lookup is fine for me
  734. vurpo has left
  735. vurpo has joined
  736. vurpo has left
  737. moparisthebest yea I sorted the numbers in the file by hash, but only store the numbers, so I could do a binary search
  738. moparisthebest which for 100 billion numbers is max 26 lookups/sha1 hashes
  739. vurpo has joined
  740. moparisthebest which my machine can apparantly do in <2 seconds, probably mostly constrained by disk seek speeds
  741. jonasw yeah, 26 times sha1 should be *very* cheap
  742. jonasw microseconds cheap
  743. jonasw it’s the disk :)
  744. moparisthebest during generation I wrote to 65535 files and it KILLED my disk
  745. goffi has left
  746. Steve Kille has left
  747. moparisthebest I had to put in synchronization code so only one file was written to at any given time
  748. moparisthebest so an SSD with no seek time, I bet generation would go from 90 hours to 20 or less
  749. moparisthebest anyone want to send me a >500gb SSD to find out? :P
  750. jonasw no.
  751. moparisthebest or run it yourself :P
  752. jonasw ENOSPC
  753. Zash Rent some CLOUD
  754. moparisthebest I don't have an SSD with that much free space
  755. moparisthebest or money to burn on a toy idea like this lol
  756. Piotr Nosek has joined
  757. Steve Kille has joined
  758. SamWhited has left
  759. moparisthebest Zash, so how were you calculating how big a rainbow table needed to be?
  760. moparisthebest I couldn't really find good info
  761. moparisthebest the strings being hashed are like +00000000000
  762. moparisthebest so a +, then 11 digits
  763. Zash moparisthebest: But if they are numbers, you can just encode them as digits
  764. Zash err
  765. Zash as computers do
  766. moparisthebest yea but can rainbow tables?
  767. Zash integers
  768. moparisthebest I mean presumably a custom implementation can do whatever it wants
  769. Zash Gaint hash table?
  770. moparisthebest but yea all the tools I found only let you specific 'character set' and 'length', which meant it was doing length of 12
  771. moparisthebest and also trying numbers like '00000+000000'
  772. moparisthebest and I had it do that and using 100% cpu for 4 days only had generated a 4gb file so far
  773. moparisthebest so I stopped it hehe
  774. Zash Hu, I ran into the 1GB memory limit of LuaJIT in a few seconds :/
  775. moparisthebest this was the first time java using a 32-bit signed integer as array indices actually effected me
  776. Zash t [ sha1( sprintf("+%011d", i) ) ] = i for i in 0 → 10^11
  777. moparisthebest yea that's a *lot* of memory
  778. jonasw ha, I know why I have swap turned off by default :-)
  779. moparisthebest because just storing the integers as 5 bytes each is 500gb
  780. moparisthebest storing them with 20 byte sha1 hashes is 2.5tb
  781. moparisthebest if you stored them as the 12 character strings they are actually hashed with, that's a TON of space
  782. moparisthebest depending on character encoding and such of course hehe
  783. SouL has joined
  784. jonasw I’m still amazed by your binary search hack
  785. Zash ... binary search what
  786. xyz has left
  787. Piotr Nosek has left
  788. Zash If you sort them into 256 buckets based on the first byte of sha1, then sort each of those buckets into buckets based on the second byte of sha1 output, and so on, you get a tree thing...
  789. moparisthebest Zash: 256 buckets is a bit big, I sorted them into 65535 buckets based on the first 2 bytes of the sha1 hash, then sorted those, concatenated all of them into one big now sorted file
  790. Piotr Nosek has joined
  791. xyz has joined
  792. SamWhited Isn't that just the definition of a prefix tree?
  793. moparisthebest And then just do a binary search on it
  794. Zash SamWhited: Being self-taught, I rarely know the names of things.
  795. moparisthebest Idk I forgot most of these terms from school :-)
  796. SamWhited ah, no, this is the phone numbers… sort of a weird mix of prefix tree and binary search.
  797. SamWhited or a trie or whatever
  798. Martin has left
  799. Martin has joined
  800. moparisthebest It's like a bucket sort, what I did
  801. moparisthebest That's where I got the idea anyway
  802. Zash I've seen a physical bucket sort. It was cool.
  803. Zash Post sorter machine
  804. Zash Mail sorter machine
  805. Martin has left
  806. moparisthebest there I added a tl;dr to the readme
  807. moparisthebest tl;dr I put all 11 digit phone numbers represented as 5 byte integers in a 500gb file sorted by their sha1 hashes, now I can binary search it fast.
  808. moparisthebest https://github.com/moparisthebest/phonehash if I didn't link it already
  809. jere has left
  810. jere has joined
  811. Zash There are some fun ways to store sets of integers
  812. Zash Like, delta compression
  813. Zash Or a giant bitfield
  814. jonasw not sure if any of these work if you have essentially shuffled integers
  815. moparisthebest yea compressing a random set of integers is impossible of course, but these are sequential, but the order is probably essentially random?
  816. moparisthebest it'd be interesting to look into though
  817. Zash If the numbers are divided into blocks of bit fields, then you do a linear search through the bit field but binary search on the blocks...
  818. Sonny has left
  819. Sonny has joined
  820. moparisthebest I have no idea what you just said, why don't you try to implement it then let me look at your code... :)
  821. Zash I have no idea how large a bit field would need to be
  822. Zash Going to implement food instead
  823. intosi Zash: enjoy the debugging!
  824. mancho has left
  825. xnyhps Instead of the binary search, wouldn't it be faster to jump to index (hash / 2^160) * size and search up or down from there depending on the difference between the hashes? The hashes should be quite uniform.
  826. moparisthebest not entirely positive what you mean xnyhps , sounds interesting to try though, care to explain more?
  827. Piotr Nosek has left
  828. jonasw moparisthebest: you have the data sorted by hashes, so looking at the first 32bit or something to guess the index in your array is a pretty reasonable thing to do
  829. moparisthebest ah yea, interesting
  830. xnyhps If you were looking for the hash 10000000000000..., you can assume it's close to 1/16th in the list of phone numbers because it's 1/16th of the possible values for the hash.
  831. xnyhps You'd start at 8000000..., then 4000000..., etc.
  832. moparisthebest it's not clear to me whether that would always be 26 comparisons or less though?
  833. moparisthebest I guess it'd depend on exactly how evenly distributed the hashes were?
  834. xnyhps Yeah.
  835. jonasw sha1 should be pretty uniform
  836. Zash So you basically treat it as a hash table?
  837. moparisthebest it is for some definition of "pretty" :)
  838. xyz has left
  839. xnyhps You could also do a binary search, but with a weighted "middle" value.
  840. moparisthebest so like when I sorted it into 65535 different files based on the first 2 bytes, if it was *perfectly* distributed the files should have all been like 7.3mb, but they ranged between ~7 and 7.8 or so
  841. Zash moparisthebest: 10^11 is a pretty small sample size tho :)
  842. moparisthebest I should have taken exact byte counts at the time
  843. Zash You could have just kept the files as is
  844. moparisthebest yea could have, more math than just jumping to a place in one file though
  845. Zash Wouldn't it be exactly the same math, just a smaller file?
  846. moparisthebest like I already had the code written to do a binary search in one file and didn't want to bother doing anything else hehe
  847. Zash and you get told the right file to open from the input
  848. moparisthebest and it was the same amount of disk writing, read file into memory, sort file, write file to same file or append to one file is the same
  849. Sonny has left
  850. moparisthebest ah yea that's true, yea that would have been faster
  851. moparisthebest well I'm not redoing it haha
  852. Sonny has joined
  853. Zash And then jumping to some point based on the 3rd byte of the input and done a linear search from there
  854. Sonny has left
  855. moparisthebest it would be faster but it's not faster by a huge margin log(100000000000/65535) is 15 sha1+comparison worst case vs 26 for the whole 100 billion
  856. moparisthebest still that would have been better :)
  857. jonasw moparisthebest: it will be quite a bit faster
  858. Zash Don't underestimate the performance of linear searches. CPUs, kernels and the disk can be much smarter
  859. jonasw sequential access is good for spinnign disks
  860. jonasw probably you will have only a single access because all of the numbers fit in the same block
  861. jonasw maybe two disk accesses
  862. Zash binary search mucks up all the caches and whatnot
  863. jonasw I guess the disk latency is the most expensive thing here, and that will vanish to O(1) instead of O(log n)
  864. Sonny has joined
  865. moparisthebest yea it'd be interesting to see how much it improves
  866. moparisthebest it's already <2 seconds though, if I reworked it like that what would it drop to, 1?
  867. moparisthebest hmm
  868. Sonny has left
  869. Sonny has joined
  870. jonasw 100ms or something maybe, from a naive calculation
  871. moparisthebest well also I can see how a forward sequential read would be faster
  872. moparisthebest but jumping to a place might put me ahead of it too which would cause a reverse sequential read
  873. moparisthebest which would equally negate caching
  874. jonasw hm, maybe
  875. jonasw this then really depends on the block alignment
  876. jonasw the disk cache is what benefits your application the most, I think, and that is controlled by the block alignment. unless you hit a block boundary you should be fine. and that can happen both ways.
  877. jonasw on a more on-topic manner, has there been discussion about introducing {urn:xmpp:mix:0}feature elements in disco query responses? I do not like that idea.
  878. Zash Wha?
  879. Sonny has left
  880. jonasw Zash: e.g. example 40 in xep 369
  881. Zash -xep 369 ex 40
  882. Bunneh Zash: http://xmpp.org/extensions/xep-0369.html#example-40
  883. jonasw woah, dem features
  884. jonasw (pun not intended)
  885. Zash Hnnng
  886. xyz has joined
  887. mancho has left
  888. jonasw I cannot interpret that
  889. Zash <grunt-of-disapproval/>
  890. Zash No caps?
  891. jonasw not sure if mix channels are supposed to support caps :)
  892. jonasw but the interaction with caps would for sure be interesting
  893. moparisthebest so based on a clients support or mix or not, could a server allow them into a mix channel if supported or throw them into some type of muc compatibility layer for the mix jid if not?
  894. moparisthebest sounds super hacky and terrible from a server POV but nice and cozy from a client/user POV :)
  895. moparisthebest ie client A supports mix, client B supports muc, both try to join room@example.org, end up joining same room but B is using his servers muc->mix layer?
  896. moparisthebest since mix requires server support anyway, at least it wouldn't *require* client support this way
  897. suzyo has joined
  898. moparisthebest plus I'm sure that sounds like loads of fun to implement for Zash
  899. moparisthebest hey it'd work the other way around too, servers could treat remote MUCs as MIXs for their clients that supported MIX ? :)
  900. Sonny has joined
  901. Sonny has left
  902. Sonny has joined
  903. Valerian has left
  904. SamWhited has left
  905. sezuan has left
  906. mancho has left
  907. jubalh has joined
  908. jubalh has left
  909. Zash has joined
  910. suzyo has left
  911. Valerian has joined
  912. suzyo has joined
  913. Kev has left
  914. goffi has joined
  915. goffi has left
  916. goffi has joined
  917. nyco has joined
  918. jonasw good night everyone ☺
  919. jonasw has left
  920. Sonny has left
  921. Sonny has joined
  922. moparisthebest alright SamWhited it's up https://github.com/xsf/xeps/pull/426
  923. daniel has left
  924. xyz has left
  925. xyz has joined
  926. xyz has left
  927. xyz has joined
  928. daniel has joined
  929. pep. has left
  930. SamWhited has left
  931. stpeter has joined
  932. Valerian has left
  933. Valerian has joined
  934. nyco has joined
  935. xyz has left
  936. sezuan has left
  937. xyz has joined
  938. suzyo has left
  939. suzyo has joined
  940. xyz has left
  941. Zash has joined
  942. Alex has left
  943. Zash has joined
  944. goffi has left
  945. goffi has joined
  946. pep. has joined
  947. boothj5 has joined
  948. boothj5 has left
  949. boothj5 has joined
  950. nyco has joined
  951. Tobias has joined
  952. boothj5 has left
  953. jere has left
  954. xyz has joined
  955. Valerian has left
  956. Zash has joined
  957. moparisthebest has joined
  958. sezuan has left
  959. nyco has joined
  960. jere has joined
  961. xyz has left
  962. xyz has joined
  963. suzyo has left
  964. suzyo has joined
  965. xyz has left
  966. xyz has joined
  967. vurpo has left
  968. vurpo has joined
  969. Neustradamus has left
  970. suzyo has left
  971. xyz has left
  972. nyco has joined
  973. Neustradamus has joined
  974. koyu has joined
  975. koyu has left
  976. suzyo has left
  977. stpeter has left
  978. mancho has left
  979. nyco has joined
  980. mancho has left
  981. ralphm has left
  982. Zash has joined
  983. uc has left
  984. vurpo has left
  985. vurpo has joined
  986. uc has joined
  987. SamWhited has left
  988. winfried has left
  989. Sonny has left
  990. uc has left
  991. SamWhited has joined
  992. SamWhited has joined
  993. uc has joined