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


  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


  284. Ge0rG


  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


  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


  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


  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


  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


  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


  751. moparisthebest

    or run it yourself :P

  752. jonasw


  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


  765. Zash

    as computers do

  766. moparisthebest

    yea but can rainbow tables?

  767. Zash


  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


  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


  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


  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


  886. xyz has joined

  887. mancho has left

  888. jonasw

    I cannot interpret that

  889. Zash


  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