XSF Discussion - 2017-03-16

  1. vurpo has left

  2. vurpo has joined

  3. vurpo has left

  4. vurpo has joined

  5. Zash has left

  6. Mancho has left

  7. ThurahT has joined

  8. moparisthebest has joined

  9. efrit has joined

  10. vurpo has left

  11. vurpo has joined

  12. vurpo has left

  13. vurpo has joined

  14. vurpo has left

  15. vurpo has joined

  16. vurpo has left

  17. vurpo has joined

  18. intosi has left

  19. vurpo has left

  20. vurpo has joined

  21. vurpo has left

  22. vurpo has joined

  23. ralphm has left

  24. jere has joined

  25. mimi89999 has left

  26. suzyo has left

  27. Tobias has joined

  28. kaboom has left

  29. uc has left

  30. kalkin has left

  31. nyco has joined

  32. kaboom has joined

  33. sezuan has left

  34. Tobias has joined

  35. uc has joined

  36. ralphm has left

  37. uc has left

  38. uc has joined

  39. waqas has left

  40. ralphm has left

  41. ralphm has left

  42. nicolas.verite has joined

  43. Tobias has joined

  44. Ge0rG has left

  45. Ge0rG has left

  46. sezuan has joined

  47. Mancho has joined

  48. Ge0rG has left

  49. smitb has joined

  50. smitb has left

  51. jere has joined

  52. nicolas.verite has left

  53. sezuan has left

  54. Arc has left

  55. moparisthebest has joined

  56. Ge0rG

    Am I the only one to be baffled by the Yes-Yes-Yes-No-Yes order of questions in the Last Call emails, every single time?

  57. arc has left

  58. Guus has left

  59. Guus has joined

  60. Valerian has joined

  61. vurpo has left

  62. vurpo has joined

  63. ralphm has left

  64. nicolas.verite has joined

  65. Tobias has joined

  66. Guus has left

  67. nicolas.verite has left

  68. Guus has joined

  69. Tobias

    yes you are

  70. Ge0rG

    Tobias: how can you know? :D

  71. efrit has joined

  72. nyco has joined

  73. Tobias

    aww...multi-client support in major IM apps, "WhatsApp is open on another computer or browser. Click “Use Here” to use WhatsApp in this window."

  74. nicolas.verite has joined

  75. Ge0rG

    Tobias: And you have also stored XSS vulnerabilities in WhatsAppWeb

  76. Ge0rG

    Tobias: And you have also stored-XSS vulnerabilities in WhatsAppWeb

  77. Tobias

    what web app doesn'T have XSS vulnerabilities, that's their feature, isn't it?

  78. vurpo has left

  79. Guus has left

  80. Guus has joined

  81. Ge0rG

    Last time I audited a web app, I was able to type HTML/JavaScript right into the "Send message to admin" input box. Instant root!

  82. vurpo has joined

  83. moparisthebest has left

  84. moparisthebest has joined

  85. Guus has left

  86. Guus has joined

  87. intosi has joined

  88. efrit has joined

  89. efrit has joined

  90. rion has joined

  91. rion has left

  92. ralphm has left

  93. suzyo has joined

  94. nyco has joined

  95. Tobias

    jonasw, am I missing something or does xmpp.org already show the data based on your JSON system?

  96. jonasw

    no, I think it does

  97. Valerian has left

  98. jonasw

    https://github.com/xsf/xmpp.org/pull/278 cc @ Ge0rG (who wants to write the announcement mail for software developers) A bit of manual cannot hurt for the renewal thing.

  99. Tobias

    jonasw, nice..and expiration also works as soon as last_renewed is set

  100. jonasw

    there is also that deadline hardcoded in pelicanconf.py, we should adapt this once the mail is sent out

  101. jonasw

    after that deadline anything without renewal disappears magically

  102. jonasw


  103. Tobias

    so yeah...an annoucement mail would be nice to tell people to create PRs that set the last_renewed value for their project to a value in the past and that after a months or so, all entries without a last_renewed set will be removed

  104. jonasw

    we can set this to date_of_mail + 1 month when the mail is sent out.

  105. jonasw

    no need to modify the last renewal of projects for us.

  106. jonasw

    ah, nevermind, I misunderstood you. disregard the last one, it was unrelated.

  107. nicolas.verite has left

  108. jonasw

    (true, but unrelated)

  109. arc has joined

  110. Tobias

    jonasw, could the config also be relative? like today - 13 months or so

  111. jonasw

    not sure what you mean

  112. Ge0rG

    https://op-co.de/tmp/deprecation-mail.txt draft email with PR link

  113. jonasw

    there are two reasons to kick an entry from the list in the code (aside from date parsing issues): 1. if they have no renewal timestamp set, they are kicked after the date in STRICT_RENEWAL_DEADLINE has passed 2. if they *have* a renewal timestamp set, they are kicked if it is more than ENTRY_LIFETIME in the past (currently set to 365 days)

  114. Tobias

    jonasw, ahh..so it does more than I thought :) good

  115. Ge0rG

    jonasw: ENTRY_LIFETIME should be ~13 months to provide for a grace period

  116. jonasw

    it does everything that was asked I think :-)

  117. jonasw

    Ge0rG: fine with me. make a PR ;-)

  118. Tobias

    right...I thought we'd just delete projects with no date set after the deadline, but your STRICT_RENEWAL_DEADLINE config already does this :)

  119. Tobias has joined

  120. Tobias

    does this = has the same effect

  121. Ge0rG


  122. jonasw

    Ge0rG: your email footnotes have two times [2] in them

  123. Ge0rG

    jonasw: damn off-by-ones. Fixed.

  124. jonasw

    Ge0rG: it might be better to link to the commit rather than to the PR

  125. jonasw

    the PR does a lot of unrelated stuff

  126. jonasw

    it might be even better to link to the README

  127. jonasw

    (and we can update the readme with a link to the example commit once the branch is merged)

  128. Ge0rG

    jonasw: but I did link to the commit. It was just relative to the PR and not in the xsf repo.

  129. jonasw


  130. jonasw

    I cannot read urls

  131. jonasw


  132. Tobias

    jonasw, right...maybe we should add a section to https://xmpp.org/software/ how authors can add new software and update the date

  133. Ge0rG

    jonasw: URLTLDR

  134. jonasw

    Tobias: might be wise, yes

  135. Ge0rG

    Tobias: maybe we should add it to some README and link it from https://xmpp.org/software/

  136. Tobias

    why not have the readme at https://xmpp.org/software/ ?

  137. jonasw

    https://github.com/xsf/xmpp.org/pull/278/commits/73cd247e4af6624e60ac29bf33c3f4bf46677786#diff-ac579daf3602a0a4ea57b5fdd7f73dd8 like this readme?

  138. jonasw

    Tobias: because it’s long and technical. If we want normal users to use the software directory there, we shouldn’t have that information on it

  139. Tobias

    yeah..that what you linked to looks qutie long..linking to it sounds sensible

  140. jonasw

    I thought I’d rather make it too detailed than too shallow.

  141. Ge0rG

    Yay. I've been reading 0369 for the last two hours, and I only managed to get to 6.1.6

  142. jonasw

    Ge0rG: you are in luck! it appears that prefer hidden is going to be broken out of that XEP. so less to read next time ;-)

  143. jonasw

    (which I think is a good idea, I also thought that might make sense to break out into an add-on)

  144. Ge0rG

    jonasw: yeah, I actually had three remarked about prefer-hidden that I already deleted.

  145. jonasw


  146. Tobias

    Ge0rG, you should order the audiobook version read by helen mirren

  147. jonasw

    thanks for going through it :)

  148. jonasw

    there is one? :-O Tobias

  149. Tobias

    there should be one

  150. Ge0rG

    Tobias: but I want the one read by Morgan Freeman('s German lipsync voice).

  151. Tobias

    https://youtu.be/zmeF2rzsZSU?t=2m19s :)

  152. Tobias

    Ge0rG, you mean Nelson Mandela?

  153. Guus has left

  154. vurpo has left

  155. vurpo has joined

  156. Guus has joined

  157. Valerian has joined

  158. Tobias

    jonasw, but yeah..nice work you did there...thanks :)

  159. jonasw

    no problem :-)

  160. jonasw

    you’re welcome

  161. jonasw

    (I need to get used to using "you’re welcome" in en locales)

  162. Tobias

    de nada

  163. vurpo has left

  164. vurpo has joined

  165. nicolas.verite has joined

  166. nicolas.verite has left

  167. Guus has left

  168. Guus has joined

  169. vurpo has left

  170. vurpo has joined

  171. nyco has joined

  172. Zash has joined

  173. pep. has joined

  174. Yagiza has joined

  175. jubalh has joined

  176. Ge0rG

    resolved my XMPP action items for today.

  177. Ge0rG

    When is the next council meeting due?

  178. Tobias

    Ge0rG, they usually happen on a weekly basis

  179. goffi has joined

  180. Ge0rG

    So "yesterday"

  181. nyco has joined

  182. Tobias

    Ge0rG, which reminds me to write up minutes for yesterdays meeting...nothing is more exciting than yesterday news

  183. Ge0rG

    Tobias: was there an exciting discussion of #436?

  184. Bunneh

    Tobias: XEP-0045: Add <x/> tag to MUC-PMs #436 https://github.com/xsf/xeps/pull/436

  185. Tobias

    i don't remember discussions about that

  186. Ge0rG has joined

  187. Ge0rG

    It looks like my train is arriving. I'm looking forward to read minutes.

  188. Tobias


  189. Tobias

    shoo shooo

  190. vurpo has left

  191. vurpo has joined

  192. jonasw


  193. jonasw

    is there any update on my protoxep?

  194. jonasw

    (I’m not familiar with the process, so please don’t mind me asking.)

  195. jonasw


  196. jonasw

    I am too stupid to search

  197. Tobias

    jonasw, it's awaiting votes...council members have two weeks to vote

  198. sonny has joined

  199. jonasw

    ah, I see

  200. jonasw

    didn’t know that "two weeks" detail

  201. Holger

    Ge0rG: It was mentioned last week http://logs.xmpp.org/council/2017-03-08/#16:32:52 (and then on the list) but maybe you mean a follow-up discussion?

  202. Ge0rG

    Holger: yes. I've done what was asked from me and hoped it would get discussed again

  203. Holger

    Ah ok.

  204. Ge0rG

    Looks like adding things to the PR wasn't enough. Need to bother someone to add it to trello.

  205. sonny has joined

  206. Tobias

    Ge0rG, yup..what's not in trello isn't discussed :)

  207. jonasw

    mail to council@?

  208. Ge0rG

    Tobias: can you add it please?

  209. Tobias


  210. Tobias

    Ge0rG, seems there are pending votes on https://trello.com/c/wF37u9DJ/169-vote-on-approve-xep-0045-changes-proposed-by-georg

  211. Tobias

    one of which is mine...will review that now then :)

  212. Ge0rG

    Tobias: it might need a revote (is that a thing), because I changed the PR based on council feedback

  213. sonny has joined

  214. Tobias

    Ge0rG, i'll put it on the agenda to discuss this next meeting

  215. Steve Kille has left

  216. Steve Kille has left

  217. Ge0rG

    Tobias: thanks very much! Is there anything I can do to accelerate the process, so that there is no more 1-week latency in the feedback loop?

  218. Ge0rG

    Or even 2-week in this case

  219. Steve Kille has joined

  220. Tobias

    Ge0rG, get dwd to vote on it

  221. jonasw

    Ge0rG: have you sent the deprecation announce already?

  222. Ge0rG

    jonasw: to board? Yes.

  223. jonasw

    with the link to the commit?

  224. Ge0rG

    jonasw: yes

  225. jonasw

    hm, then I’ll make sure that the commit ID doesn’t change :)

  226. Tobias

    seems i already voted on Ge0rG's PR, just forgot to mark it in Trello...now reviewing caps2

  227. jere has joined

  228. jonasw has left

  229. Ge0rG

    jonasw: it has a todo note

  230. sonny has joined

  231. mhterres has joined

  232. suzyo has left

  233. suzyo has joined

  234. nicolas.verite has joined

  235. nicolas.verite has left

  236. jonasw

    Ge0rG: what has?

  237. Martin has joined

  238. Ge0rG

    jonasw: the URL

  239. jonasw

    ah okay

  240. nicolas.verite has joined

  241. Holger

    Tobias, dwd: > <Tobias> Dave Cridland, well..p1 implemented it [MIX] too, not? > <Dave Cridland> Tobias, They implementing grouchat over pubsub; not quite the same thing. They implemented both.

  242. Holger

    (Well, an early revision of MIX.)

  243. nicolas.verite has left

  244. dwd

    Holger, That's actually the one I was referring to. The thing they said was early MIX was a brief discussion; it didn't, for example, handle <presence/> or <message/> stanzas in the traditional way, a design feature that lasted all of a week or so and was contentious at the time.

  245. vurpo has left

  246. nyconyco has joined

  247. Holger

    Yeah whatever, just wanted to clarify that there's two totally unrelated pieces of code, so you were both right :-)

  248. vurpo has joined

  249. nicolas.verite has joined

  250. nicolas.verite has left

  251. Holger


  252. nicolas.verite has joined

  253. nicolas.verite has left

  254. Holger

    Sorry you were referring to mod_mix, finally got that now.

  255. Holger

    While at it, personally I think if there's any chance to move non-essential functionality out of the core MIX spec into separate XEPs, that should be strongly considered.

  256. dwd

    Holger, I agree. I'm not sure what remains to be removed.

  257. nyconyco has left

  258. Holger

    I can totally see use cases for anonymous chat, but they don't seem to be the common me, so it would be nice if implenting that would be optional (esp. on the client side_.

  259. Holger


  260. Tobias

    Holger, indeed...it's quite an amount to review

  261. MattJ

    To be honest I'm not sure that MIX should even attempt to compete with use-cases that MUC already covers

  262. MattJ

    but maybe it's too early in the morning to be so controversial

  263. jonasw

    which use-cases does MUC actually cover?

  264. dwd

    Holger, Anonymity seems very fundamental to operations, though.

  265. dwd

    Holger, And crucial where it arises.

  266. dwd

    jonasw, Being shit on mobile?

  267. dwd

    No, seriously, MUC covers >90% of what anyone needs for pure synchronous ephemeral chat. I don't think it's hard to make MIX cover that, too, but I think MIX can and should spread its wings wider, at least in potential.

  268. MattJ

    dwd, because?

  269. MattJ

    (to your comment about mobile)

  270. Steve Kille

    dwd: +1

  271. dwd

    MattJ, The tie between your session and your participation, WRT mobile. It can be worked around to some degree, though, but it's a bit of a pain.

  272. MattJ


  273. MattJ

    Maybe it is a bit of a pain, but here comes a whole new spec that isn't exactly trivial either

  274. dwd

    MattJ, I suspect that most servers will find it *easier* to implement than we have done do far in Openfire.

  275. dwd

    MattJ, Due to the architecture, we couldn't reuse any of the MAM code, nor PubSub code, nor even the MUC code.

  276. dwd

    Not that any of that code is bad, it's just either in the wrong place, or highly focussed to what it does.

  277. Tobias

    like the s2s code? :)

  278. dwd

    Tobias, The S2S code is just very old, basically. We've updated it a considerable amount over the past few years, including fixing a bunch of security issues.

  279. Mancho has left

  280. Tobias still can't recursively disco igniterealtime.org

  281. dwd

    Tobias, The MUC code, and the pubsub code, both have near-complete, all-options, implementations of '45 and '60 respectively, with full clustering.

  282. Mancho has left

  283. dwd

    Tobias, Sure - I've not fixed the issue you found yet. It's a hang-up of Openfire originally assuming that x.domain.example could always be reached at domain.example; that assumption has entered code in a large number of cases.

  284. Guus

    no-one is arguing that that s2s bug should be fixed, Tobias. Daytime jobs and all.. :)

  285. Tobias

    Guus, dwd, yeah i know..just nitpicking :)

  286. Guus

    interop problems are annoying

  287. Guus

    you should simply switch to Openfire and be done. :)

  288. Guus ducks, runs

  289. Tobias

    Guus, and you are 100% sure that openfire would not have that issue :P

  290. Guus

    (I'm somewhat in a defiant optimistic mood now that it turns out i'm not living in the newest populist-governed country)

  291. dwd

    Tobias, Actually yes, because the assumption operates bidirectionally.

  292. dwd

    Guus, As you should be.

  293. Tobias

    dwd, i wonder if there could be a security issue there

  294. dwd

    Tobias, Actually, I suspect this case is due to authenticating domains individually rather than authorizing as domain-pairs. So no security issue.

  295. Tobias

    dwd, didn't you propose some standard for that once? bidi or dwd?

  296. Guus

    Tobias: yes.

  297. Guus

    also, what he said

  298. Guus

    (eww, lag)

  299. dwd

    Tobias, No. Those still operate on pairs.

  300. Tobias

    but it was a practice gtalk was doing right? reusing a s2s connection for all their domains?

  301. dwd

    Tobias, That's different... Piggybacking is fine. But you still have to authorize pair-wise.

  302. Tobias


  303. Valerian has left

  304. nyco

    hey, are you aware? https://www.erlang-solutions.com/blog/21-xmpp-use-cases-and-the-best-ways-to-achieve-them.html sorry, looks like a shameful ad...

  305. Flow has joined

  306. nyco

    it is interesting, as we discussed that many many times

  307. nyco

    how to read the massive amounts of XEPs

  308. nyco

    how to triage the massive amounts of infos that are behind each XEP

  309. arc has left

  310. arc has joined

  311. nyco

    do it give ideas on how to present our XEP list or feature list?

  312. sonny has left

  313. Mancho has left

  314. Ge0rG

    Wow, a burst of discussion. I think that the fact it takes multiple hours to read and understand MIX might indeed mean we won't see IM MIXes any time soon.

  315. Ge0rG

    While MUC is really broken in some regards, it can be fixed with a bunch of undocumented hacks.

  316. jubalh has joined

  317. kalkin has joined

  318. jonasw has left

  319. Valerian has joined

  320. kalkin has left

  321. Tobias

    it's all a matter of having the right abstraction in your software...and if you then already have pubsub and MAM in place, i don't think MIX is that mich work, at least a minimal version

  322. Ge0rG

    Tobias: I've tried to read the XEP (admittedly I also did some light editing along the way), and I managed to read ~40% in 2 hours.

  323. Ge0rG

    Tobias: if you have the right abstractions in your software, it still takes multiple hours to understand how to stack them

  324. Tobias


  325. Ge0rG

    I'm not sure if it would help to refactor the XEP into "Client Developers Read This", and the same for Server Devs and Service Devs.

  326. Tobias

    mostly it covers so many things...i mean user experiences like whatsapp group chats, doesn't require 4 different affilations/roles, etc.

  327. daniel has left

  328. Ge0rG

    Tobias: yes, it attempts to be everything to everyone.

  329. daniel has joined

  330. Ge0rG

    If history is repeating itself, we'll have a MIX-Light in five years that is a one-man-show slim rework of MIX, similar to what MAM is to Message Archiving, PEP is to PubSub and Blocking Command is to Privacy Lists.

  331. Ge0rG

    ...and http-upload is to Jingle FT

  332. Ge0rG

    Tobias: btw, you intended to update https://wiki.xmpp.org/web/XEP_and_RFC_Remarks/RFC_6121:_XMPP-IM with that one corner case you were talking about yesterday

  333. Tobias

    somewhere I have a tab open about that, yes

  334. Tobias opens a new tab for it :)

  335. Flow has left

  336. Guus

    that makes three rows of tabs, right?

  337. Tobias

    chrome can't do mulit rows

  338. Tobias

    but there's a nice plugin that removes duplicate tabs :)

  339. Valerian has left

  340. Valerian has joined

  341. vurpo has left

  342. vurpo has joined

  343. kalkin has joined

  344. sonny has joined

  345. Arc has joined

  346. Arc

    Amazon Smile is donating 10% of purchases to your chosen charity today

  347. Arc

    so if you've selected XMPP as your charity on smile.amazon.com be sure to make purchases ;-)

  348. mathieui

    if you’re in the US

  349. Ge0rG

    Arc: XMPP is a charity?

  350. Tobias

    Ge0rG, sure...feeding the hungry in africa

  351. kaboom has joined

  352. sonny has left

  353. sonny has joined

  354. Ge0rG

    Xenophobics' Money for Poor People?

  355. Ge0rG

    I'm sure it's a SCAM.

  356. Tobias

    Ge0rG, they probably delegated the chairity part to paypal..they are experts at this

  357. intosi

    Super Cool Automatic Messenger?

  358. jubalh has left

  359. Vinilox has left

  360. nicolas.verite has joined

  361. nicolas.verite has left

  362. dwd

    I should put MIX onto dave.cridland.net, shouldn't I? Are any [other] client developers wanting to play?

  363. jonasw

    dwd: yes

  364. jonasw

    not this month, but yes

  365. dwd

    jonasw, What library?

  366. jonasw


  367. Valerian has left

  368. dwd

    jonasw, Ah, heh. We nearly put MIX support into that, before deciding to base our test suite around Java instead.

  369. jonasw

    aw pity

  370. dwd

    jonasw, We have partial implementation, so far, only in stanza.io. I'm awaiting confirmation that'll all be offered upstream (I can't imagine why not).

  371. nicolas.verite has joined

  372. nicolas.verite has left

  373. nicolas.verite has joined

  374. nicolas.verite has left

  375. arc has left

  376. arc has joined

  377. Tobias has joined

  378. nyco has joined

  379. Mancho has joined

  380. Valerian has joined

  381. Valerian has left

  382. nyco has joined

  383. jere has joined

  384. nicolas.verite has joined

  385. Ge0rG

    dwd: any chance you can have a look at https://trello.com/c/wF37u9DJ/169-vote-on-approve-xep-0045-changes-proposed-by-georg and maybe provide feedback if action is required from my side, regarding repairing the MUC protocol?

  386. Tobias

    Ge0rG, btw: just added the text to the wiki page

  387. Ge0rG

    Tobias: thanks. Any ideas on how to fix that? Let server push a presence change to the other clients?

  388. Tobias

    with full to and from attributes, yeah

  389. dwd

    Ge0rG, FWIW, I'm a little uncomfortable with "SHOULD" here, given you're adding a normative requirement post-facto. But I suppose this is probably as good as it gets, so I'm not going to block.

  390. Yagiza has joined

  391. Ge0rG

    Tobias: I also noticed some multi client weirdness when *accepting* a subscription request, have you looked into that as well?

  392. Tobias

    Ge0rG, with accepting clients should receive a roster push, not?

  393. Tobias

    Ge0rG, also...i thought you were planning to replace the SHOULD with a MAY?

  394. Tobias

    "TLDR either change the wording to MAY or add a sentence that implementations MUST NOT rely on it." <--- regarding that

  395. Ge0rG

    dwd: thanks for the feedback. I think that we should be able to change our specifications over time, or we will end up with multiple generations of imperfect XEPs attempting to solve the same problem, evolving over the years

  396. kaboom has left

  397. Ge0rG

    Tobias: I added the sentence

  398. dwd

    Ge0rG, I don't disagree. I don't think that ought to involve simply declaring everything non-conformant. I don't see much of an option in this case, but that doesn't mean I'm happy with it.

  399. Ge0rG

    dwd: IMHO, this approach has two benefits. First, it provides a clear path for new implementors to do the right thing. Second, it provides a bit of leverage to get existing implementations fixed.

  400. dwd

    Ge0rG, But they weren't broken...

  401. dwd

    Ge0rG, Not from a standards point of view.

  402. dwd

    Ge0rG, The actual protocol seems fine. My concern is with establishing the case that conformance isn't acheivable, or important.

  403. Ge0rG

    dwd: they were compliant to an imperfect specification. One *could* consider this as broken

  404. dwd

    Ge0rG, Nothing is perfect. What we want is interoperable.

  405. dwd

    Ge0rG, And if things aren't interoperable, I'd rather they weren't despite following the specification rather than because they didn't.

  406. dwd

    Ge0rG, To put it another way, the pattern of declaring existing conformant implementations non-conformant isn't a pattern I'd like to see continue.

  407. Ge0rG

    dwd: the two largest server implementations already exhibit the new behavior.

  408. dwd

    Ge0rG, That's irrelevant.

  409. dwd

    Ge0rG, I'm not saying the protocol change is bad - I've explicitly said it seems the right solution.

  410. dwd

    Ge0rG, I'm saying the choice of how the change has been made is not something I want to see ever again.

  411. jere has joined

  412. vurpo has left

  413. vurpo has joined

  414. Valerian has joined

  415. intosi has left

  416. nicolas.verite has left

  417. Ge0rG

    dwd: I don't see a better way to change MUC, except for a hard fork. And I think we all agree that that would not really be better.

  418. waqas has joined

  419. Ge0rG

    TBH, I'd like to also add more explicit words to 0045 regarding repeated join presences from the same full JID, and also do another take on the message ID stability for reflected messages.

  420. dwd

    Ge0rG, I agree this is the best of a bad bunch. I'm just saying that introducing new normative requirements to an existing specification is a problem.

  421. dwd

    Ge0rG, For repeated joins: I think there's consensus on the approach now, but it's not clear that we could put this in as anything more than an implementation note nonetheless. But Openfire, M-Link, and possibly others do it the "right" way.

  422. dwd

    Ge0rG, For message id stability, there's really no chance. I've changed my mind on that one over the years, but there's no universally-agreed "right" way. It is, however, "fixed" in MIX.

  423. dwd

    Ge0rG, Mind you, a note saying that implementations differ on message id stability would be good if you want to pen one.

  424. Ge0rG

    dwd: my reading of rfc 2119 is more flexible, and I tend to accept "this was not part of the XEP when I implemented it" as a valid exception to a SHOULD.

  425. dwd

    Ge0rG, But that would suggest nobody would ever need to implement it... Which I don't think you really mean.

  426. jonasw

    dwd: to be frank, as a relative newcomer to XMPP, this kind of stance is annoying. If there is a consensus on how something should be done, that should be written in the XEPs. Yes, during the transition period, some implementations won’t get it right. If that’s any better, we can make it a MAY first and after a year or so make it a SHOULD. But if you only make it an implementation note, I as a developer *cannot* at all rely on that behaviour, and it doesn’t look as if I ever can, so it is often useless to me.

  427. Ge0rG

    dwd: MAY is completely optional. SHOULD at least provides direction in how to do it best

  428. MattJ

    As far as I'm aware there was only ever one implementation that rewrote ids on messages, and it tripped up everyone when it appeared

  429. dwd

    jonasw, I get that. The protocol can and should change. And if the specification says "SHOULD", you really should be able to rely on it. If we abuse that by introducing *new* normative languages into *existing* protocol, you can't.

  430. jonasw

    dwd, Ge0rG: at the same time, when such changes are made, it is important to keep a hint on that this was changed "recently" inside the text. The list of versions below is not really discoverable, and finding important changes among the long list of changes is often hard (if the list of changes is even complete). Otherwise, one might be confused by implementation which do not handle this correctly; although that can be mitigated by making that (nothing) -> MAY -> SHOULD transition.

  431. jonasw

    dwd: what about that MAY -> SHOULD transition?

  432. sonny has left

  433. jonasw

    new implementations will see where the journey is going and there is something to point existing implementations to to achieve change

  434. jonasw

    MattJ: I think daniel mentioned some gateways (Slack?) which did that, too

  435. nicolas.verite has joined

  436. nicolas.verite has left

  437. dwd

    jonasw, I don't think introducing new normative requirements to existing protocol is *ever* the ideal path. I think we want to add new *protocol*, and then add this to the requirements for a given compliance level.

  438. Kev

    jonasw: Spec versions (by protocol) should be interoperable.

  439. Kev

    If I see feature X offered, I should know that I will interoperate with it if I implement the spec.

  440. Kev

    Not that I might or might not interoperate with it based on the age of the implementation.

  441. jonasw

    okay, can we add a <feature/> then?

  442. dwd

    Or that I might not interoperate with it next week.

  443. jonasw

    that would work for "I am not rewriting message IDs" for example

  444. Kev

    Where we want to break things such that that isn't true, we do it by changing the negotiated feature (by our faux-versioning scheme).

  445. dwd

    jonasw, Sure, and we can certainly do that.

  446. Kev

    The issue here is that we're trying to avoid bumping the namespace version in MUC for obvious reasons.

  447. dwd

    Kev, We can also add new features.

  448. Kev

    dwd: Different issue if you're adding a new feature, in a sense :)

  449. Kev

    But yes.

  450. dwd

    Kev, MAM's recent :1 -> :2 transition could have done that, and it's somewhat frustrating that it hasn't.

  451. dwd

    Kev, But behavioural differences can be expressed as a new feature almost always.

  452. Kev

    dwd: If thre's a better way, you could suggest rolling back to :1 with additional features.

  453. devnull has left

  454. Kev

    Given I doubt anyone implements :2 (and if it's true that it just needs new features, that might be smart).

  455. MattJ

    Prosody implements :2

  456. Ge0rG

    Maybe we should entirely abandon the version bumping thing for new features and only use it for breaking changes.

  457. MattJ

    and iirc Conversations (but not 100% sure)

  458. Kev

    Oh. 0.10 or something?

  459. Kev

    Or are we on 0.11 now?

  460. MattJ


  461. jonasw

    Ge0rG: +1

  462. nicolas.verite has joined

  463. dwd

    MattJ, The MAM protocol itself is entirely unchanged on the wire. When used with MIX, nothing changes at all. Aside from everything, due to bumping the namespace/

  464. nicolas.verite has left

  465. dwd

    Ge0rG, Well, of course. That was *always* the intent.

  466. dwd

    Ge0rG, See XEP-0053, §4, point 2.

  467. Kev

    Yes, new features that don't break the existing stuff should be by additional feature negotiation, not by bumping the namespace.

  468. Ge0rG

    dwd: so it would be perfectly OK with you if I added the stable ID thing into MUC with an additional feature?

  469. dwd

    Ge0rG, You can't. :-) Otherwise I would have suggested it.

  470. Ge0rG

    dwd: what's wrong with it?

  471. dwd

    Ge0rG, But you've done this by - quite rightly - allowing either clients or servers to add the PM marker.

  472. dwd

    Ge0rG, You could have a feature that indicated the server would do this for you. Perhaps you should.

  473. Ge0rG

    dwd: I'm not talking about <x>, I'm talking about keeping the message ID on reflection

  474. Kev

    The thing you can't do is say that servers SHOULD or MUST implement such a new feature. The point of upgrades-through-features is that they might not happen :)

  475. dwd

    Ge0rG, Oh that. Yes, sure.

  476. Kev

    No reason a server can't advertise a feature saying "I'll keep ids stable".

  477. arc has left

  478. arc has joined

  479. Ge0rG

    dwd: though I could imagine adding a <feature> for <x> as well, I'm just not sure what that would give in that specific case.

  480. Kev

    What you can't then do is say servers SHOULD or MUST implement this.

  481. vurpo has left

  482. vurpo has joined

  483. Ge0rG

    Kev: as I wrote earlier, I consider "SHOULD" to be the appropriate wording for such things, because it indicates the purpose and intent of our Great Master Plan. Foregoing that for the sake of backwards compatibility to the year 2002 is just not right

  484. Ge0rG

    Kev: It's the right thing to RECOMMEND server implementations to do these awesome new things nobody thought of in 2002, and to have a <feature> advertising that.

  485. Ge0rG

    Kev: actually, those two are almost completely orthogonal aspects of a protocol change.

  486. Ge0rG

    (at least in my eyes)

  487. Kev

    I know you consider that. I just don't think that's the appropriate reading of SHOULD.

  488. dwd

    Ge0rG, And I strongly believe you to be wrong. Not because recommending people implement something new is wrong, but because RECOMMENDing people do something new is wrong.

  489. Kev


  490. Ge0rG

    RFC 2119 does not provide approrpiate wording to go with the time.

  491. dwd

    Ge0rG, You can strongly encourage. You can advise. But if you RECOMMEND, you are changing the past.

  492. Kev

    I think Dave's spot on here.

  493. Ge0rG

    dwd: I see what you mean.

  494. dwd

    Ge0rG, You *can*, though, say that for XMPP Server 2018 conformance, your new thing is REQUIRED.

  495. Ge0rG

    "Server implementations created in the year 2017 or later SHOULD add an <x> tag to PMs. All other implementations are strongly encouraged to do so."

  496. Kev

    Ge0rG: Which isn't needed for interop. So just go with 'strongly recommended' and MAY :)

  497. dwd

    Ge0rG, Sorta. We have XEPs specifically designed to do what you want. I RECOMMEND you help work on those. ;-)

  498. Kev

    It doesn't matter whether it's a new implementation that doesn't do it or an old one, an entity has to cope regardless.

  499. Kev

    Sorry, 'strongly suggested', senior moment.

  500. Ge0rG

    I'm still not really convinced though. IMO our main goal is to have clear normative language that corresponds to the state of affairs as it is now, if only to attract new people to XMPP and to make implementors' lives as easy as possible. I'm okay with changing the past to achieve that, and people who feel betrayed by that can still dig up the old version of the XEP as their motivation to violate the new RECOMMENDation.

  501. bjc has left

  502. bjc has joined

  503. nicolas.verite has joined

  504. nicolas.verite has left

  505. Kev

    If you implement the current version of a spec, and get weird interop problems with something else that looks like it's the same version, you've had your life made difficult, not easier.

  506. Ge0rG

    really, sentences like this are frightening in a network protocol specification: "The following is a suggested set of rules a server MAY use, or it MAY use its own; in either case it SHOULD follow the general intent of these rules."

  507. suzyo has left

  508. Kev

    Terrifying. I can scarcely sleep at night.

  509. intosi has joined

  510. Ge0rG

    Kev: everybody has their own nightmares, I suppose.

  511. Ge0rG

    Kev: re "get weird interop problems with something else", my reading of SHOULD in 2119 is that no other party may actually rely on it anyway, because you might always have a reason not to follow the RECOMMENDation

  512. MattJ

    I read it the other way: if you break a SHOULD, you have to deal with potential interop problems from that

  513. Kev

    What MattJ says.

  514. Kev

    Otherwise SHOULD is no different to MAY.

  515. Ge0rG

    So there is nothing in between SHOULD and MAY that conveys "do it this way, but if you don't then the others have to cope with it"

  516. moparisthebest

    isn't MUST the word where breaking it makes interop problems happen?

  517. Ge0rG

    I suppose this actually was a wise design decision on behalf of the Elders of the Internet

  518. Kev

    moparisthebest: No, SHOULD is.

  519. Kev

    Ge0rG: If others have to cope with it, it's MAY.

  520. moparisthebest

    then how do MUST and SHOULD differ Kev ?

  521. Kev

    From an interoperability point of view - which is what 2119 language cares about

  522. Kev

    moparisthebest: For SHOULD, you might understand how one can not implement it without affecting interop.

  523. Ge0rG

    Kev: yes, on re-reading 2119 this became apparent to me now. Thanks to you and Dave and Matt for being patient with me

  524. Kev

    But generally, in a spec a SHOULD should be matched with 'except when...'

  525. Ge0rG

    So effectively I MUST NOT change the normative language of an XEP without either making it conditional on a new feature or bumping the namespace.

  526. vurpo has left

  527. vurpo has joined

  528. Kev

    SHOULD NOT, except where you can mitigate interop considerations in some manner, yes.

  529. Kev


  530. Ge0rG

    Kev: heh :P

  531. moparisthebest

    yea I need to re-read 2119 it's been too long, thanks :)

  532. Ge0rG

    However, the question remains what is the most elegant way to convey a new intent (like in the case of <x/>) and to make it a SHOULD eventually

  533. Valerian has left

  534. Guus has left

  535. Yagiza has left

  536. Valerian has joined

  537. vurpo has left

  538. vurpo has joined

  539. goffi has left

  540. waqas has left

  541. suzyo has joined

  542. kaboom has left

  543. Guus has left

  544. uc has left

  545. SamWhited

    ralphm: Ping, reminder to create me a trello board and add me to the XSF organization if possible

  546. Tobias

    and check if the board board and the council board belong to the XSF org

  547. SamWhited

    the board board does, the council board doesn't; we should probably fix that.

  548. Tobias


  549. Ge0rG

    board the board board?

  550. Valerian has left

  551. Valerian has joined

  552. Valerian has left

  553. nicolas.verite has joined

  554. nicolas.verite has left

  555. Kev

    I can fix the Council Board once Ralph makes me as XSF admin.

  556. uc has joined

  557. nicolas.verite has joined

  558. nicolas.verite has left

  559. Guus has left

  560. jere has joined

  561. ralphm has left

  562. nicolas.verite has joined

  563. nicolas.verite has left

  564. ralphm has joined

  565. Yagiza has left

  566. nicolas.verite has joined

  567. nicolas.verite has left

  568. waqas has joined

  569. Ge0rG has left

  570. Tobias has joined

  571. kaboom has left

  572. vurpo has left

  573. vurpo has joined

  574. vurpo has left

  575. vurpo has joined

  576. vurpo has left

  577. vurpo has joined

  578. Ge0rG has left

  579. Flow has joined

  580. vurpo has left

  581. vurpo has joined

  582. vurpo has left

  583. vurpo has joined

  584. vurpo has left

  585. vurpo has joined

  586. suzyo has left

  587. suzyo has joined

  588. Ge0rG has left

  589. vurpo has left

  590. vurpo has joined

  591. vurpo has left

  592. vurpo has joined

  593. nicolas.verite has joined

  594. nicolas.verite has left

  595. vurpo has left

  596. vurpo has joined

  597. waqas has left

  598. Ge0rG has left

  599. bjc has left

  600. suzyo has left

  601. bjc has joined

  602. suzyo has joined

  603. Ge0rG has left

  604. Yagiza has joined

  605. jonasw has left

  606. Mancho has left

  607. vurpo has left

  608. vurpo has joined

  609. vurpo has left

  610. vurpo has joined

  611. Valerian has joined

  612. vurpo has left

  613. vurpo has joined

  614. vurpo has left

  615. vurpo has joined

  616. Arc has left

  617. Yagiza has left

  618. Yagiza has joined

  619. Ge0rG has left

  620. ralphm

    Kev: looking right now

  621. Tobias has left

  622. ralphm

    Kev: do you already have an Trello identifier?

  623. ralphm

    SamWhited: you, too?

  624. SamWhited

    ralphm: yup, it's just my name, same as my nick

  625. SamWhited

    I think I'm already on the board trello, but not in the organization so it shows up in my "Personal boards"

  626. ralphm

    and now?

  627. SamWhited

    yup, that did it

  628. SamWhited

    Excellent; I can create an editor board now too. Thanks.

  629. Tobias has left

  630. ralphm

    SamWhited: who owns the Council board, and can he/she initiate a transfer or something?

  631. SamWhited

    ralphm: Let me check; I think it's Kev.

  632. SamWhited

    Kev, Lance, and Tobias are admins; not sure if that's the same as owner or not.

  633. Ge0rG has left

  634. nicolas.verite has joined

  635. nicolas.verite has left

  636. ralphm

    There should be a 'change team' in the setting of the board

  637. ralphm

    Hmm. I'm not the owner of the Board board. Only bear and Laura.

  638. ralphm

    eh, admin

  639. Yagiza has left

  640. ralphm

    Even though I am admin of the team, I cannot change that

  641. SamWhited

    Board board appears to already be on the team, I think?

  642. dwd

    I've nudged Laura, but she seems to be busy.

  643. SamWhited

    oh, you just want to be an admin; nevermind, makes sense.

  644. Laura has joined

  645. ralphm

    SamWhited: it is either a documentation bug, or an implementation bug. I filed a ticket.

  646. kaboom has left

  647. Ge0rG has left

  648. jere has joined

  649. Laura


  650. dwd

    Laura, ralphm was after the Trello board ownership.

  651. kaboom has left

  652. ralphm

    Yeah, so it turns out I am admin of the team, not the Board Meetings board.

  653. Laura

    The trello Board board?

  654. kaboom has left

  655. ralphm


  656. Laura


  657. kaboom has left

  658. Guus has left

  659. Ge0rG has left

  660. Laura has left

  661. Ge0rG has left

  662. mimi89999 has joined

  663. Vinilox has joined

  664. Vinilox has left

  665. Vinilox has joined

  666. uc has left

  667. uc has joined

  668. Guus has left

  669. nicolas.verite has joined

  670. mhterres has left

  671. nicolas.verite has left

  672. nicolas.verite has joined

  673. nicolas.verite has left

  674. nicolas.verite has joined

  675. nicolas.verite has left

  676. nicolas.verite has joined

  677. nicolas.verite has left

  678. nicolas.verite has joined

  679. jonasw has left

  680. nicolas.verite has left

  681. nicolas.verite has joined

  682. nicolas.verite has left

  683. nicolas.verite has joined

  684. nicolas.verite has left

  685. nicolas.verite has joined

  686. nicolas.verite has left

  687. nicolas.verite has joined

  688. nicolas.verite has left

  689. ralphm

    Link Mauve: thanks!

  690. ralphm

    Laura: thanks!

  691. nicolas.verite has joined

  692. nicolas.verite has left

  693. nicolas.verite has joined

  694. nicolas.verite has left

  695. Valerian has left

  696. nicolas.verite has joined

  697. nicolas.verite has left

  698. nicolas.verite has joined

  699. nicolas.verite has left

  700. nicolas.verite has joined

  701. dwd

    Does MAM on MIX archive the outgoing message or the incoming one?

  702. Ge0rG would assume that archiving happens on the pubsub node, so only for messages reflected by the MIX

  703. bra has left

  704. Kev

    dwd: You mean pre-or-post unspecified munging, or something else?

  705. dwd


  706. Kev

    What you get out should be what would be sent to you.

  707. Kev

    So if you had a pastebin running, I'd expect to get the munged URL from MAM, not the paste that I submitted.

  708. dwd

    So is the from attribute set to the MIX on the forwarded message? Does it have <jid/>? (That's what I thought... But the only example is 52 and shows the opposite).

  709. Yagiza has joined

  710. Steve Kille

    Kev: yes

  711. Steve Kille

    I will sort the text

  712. Kev

    dwd: The from is always the MIX for MIX messages isn't it?

  713. dwd

    Kev, Yes. See Example 52.

  714. mimi89999 has joined

  715. Kev

    by looks right to me, and from looks like a typo.

  716. Kev

    Is that consistent with your reading?

  717. dwd

    Yup. Ta.

  718. Zash

    Are the to/from attributes even needed in MIX-MAM?

  719. Kev

    Zash: Not really needed, but it's how MAM works, so there doesn't seem huge value removing them.

  720. Kev

    The <jid xmlns='urn:xmpp:mix:0'>coven+123456@mix.shakespeare.example</jid>, which is always the proxy JID, needs to be in the archived messages to say who it's really from.

  721. Kev

    That's 123456#coven@mix... now, of course :)

  722. Ge0rG

    Steve Kille, Kev: what about using 12345%coven@mix? It might be more in line with existing transports, that encode transported IDs by replacing @ with %

  723. Kev

    Ge0rG: That was exactly my motivation for *not* using it (same as \), I didn't want any confusion when conflating it with existing stuff.

  724. Ge0rG

    Not that I'd oppose "#", it's also used by transport JIDs (e.g. for irc: `#channel%irc.server.net@irc-transport.xmpp`)

  725. dwd

    Can we have non-numeric proxy jidlets, too? (As in, in the examples - I assume it's legal)

  726. Ge0rG

    Kev: that's a great point

  727. Kev

    Ge0rG: Yeah. I realised that, but it seems like the least bad option from what Steve and I discussed earlier. I'm not tied to the octothorp, other than loving the name.

  728. vurpo has left

  729. vurpo has joined

  730. Ge0rG

    what about using UUIDs? *ducks&runs*

  731. Kev

    dwd: That'd probably be sensible.

  732. Kev

    Ge0rG: What, 123456<uid>coven@mix...? :)

  733. Ge0rG

    Kev: I had to look up into the example to determine what an octothorp is.

  734. Kev

    Ah, 'hashtag' to you youngsters.

  735. Ge0rG

    Kev: no, `#<uuid>+<uuid>@uuid.server.xmpp/<uuid>/<uuid>`

  736. Zash


  737. Ge0rG

    Kev: I'm part of the generation that associates "#" with channels, actually

  738. Ge0rG

    Kev: so having `#channel` in the JID rings a bell with me

  739. Kev

    Well, Twitter hashtags came from IRC. IRC users started using them to associate messages informally, them actually being a 'thing' came later.

  740. Ge0rG

    personally, I liked '+' and was surprised by its demise.

  741. Zash

    I thought it was meant as an inverse channel?

  742. jere has joined

  743. Kev

    Ge0rG: I liked it, but + in local parts has a definite semantic from email. I felt that reversing the semantic would be confusing.

  744. Kev

    But your arguments about proxypart coming first seemed compelling.

  745. Ge0rG


  746. Kev

    So, changing the separator seemed sensible.

  747. Ge0rG

    Kev: I'm not sure if we are going to expose the proxy JIDs at all to non-tech users, and we are going to realize it's not an email anyway

  748. Kev

    End users are probably less likely to recognise the + notation than devs. It was confusing devs that I was worried about.

  749. Ge0rG

    So my vote goes to '+', with '%' a remote second.

  750. moparisthebest

    + isn't really an email standard anyway, iirc sendmail used +, and qmail or something used -

  751. moparisthebest

    I have my postfix configured to accept +, -, or . as that seperator :)

  752. Ge0rG

    what about using a slug of the user's nickname to create the proxy JIDlet?

  753. Zash

    What if they change it?

  754. Ge0rG

    Zash: keep it as-is. Also if somebody tries to collide, obviously, use a different JIDlet

  755. Kev

    Ge0rG: I think we leave choice of proxy JID parts up to the service.

  756. Kev

    So if they wanted to do that, they could.

  757. Ge0rG

    Kev: but we could RECOMMEND something. It's not too late! :D

  758. vurpo has left

  759. Zash

    I'd also like to say that I don't think structured data belongs in jid parts, but I haven't manged to read all of MIX yet so I don't know if there's a good enough reason.

  760. Ge0rG

    Zash: pseudonymity combined with routability.

  761. Kev

    Zash: I agree, in principle, but it also doesn't seem harmful, and is beneficial in this case.

  762. Ge0rG

    Zash: the MIX needs to provide JIDs for all resources of all participants, in a way that prevents you from obtaining their real identity

  763. vurpo has joined

  764. vurpo has left

  765. vurpo has joined

  766. vurpo has left

  767. vurpo has joined

  768. vurpo has left

  769. vurpo has joined

  770. vurpo has left

  771. Kev

    Right, the Council Trello board is now in the XSF org.

  772. vurpo has joined

  773. Kev

    ralphm: Thanks for the team stuff.

  774. jere has joined

  775. sezuan has joined

  776. Lance has joined

  777. vurpo has left

  778. vurpo has joined

  779. SamWhited

    Yey! Thanks Kev and ralphm

  780. vurpo has left

  781. vurpo has joined

  782. uc has left

  783. uc has joined

  784. goffi has left

  785. vurpo has left

  786. vurpo has joined

  787. ralphm has left

  788. vurpo has left

  789. vurpo has joined

  790. vurpo has left

  791. Martin has left

  792. vurpo has joined

  793. ralphm has left

  794. vurpo has left

  795. sezuan has left

  796. vurpo has joined

  797. sonny has joined

  798. vurpo has left

  799. vurpo has joined

  800. SamWhited

    I just discovered that Trello has "due dates". I haven't used this before. ♡

  801. nyco has left

  802. nicolas.verite has left

  803. nicolas.verite has joined

  804. Steve Kille has left

  805. Steve Kille has left

  806. nicolas.verite has left

  807. arc has left

  808. arc has joined

  809. waqas has joined

  810. kalkin has left

  811. waqas has left

  812. waqas has joined

  813. vurpo has left

  814. vurpo has joined

  815. vurpo has left

  816. vurpo has joined

  817. vurpo has left

  818. vurpo has joined

  819. Steve Kille has joined

  820. arc has left

  821. Ge0rG has left

  822. vurpo has left

  823. vurpo has joined

  824. arc has joined

  825. jonasw

    Guus: you wanted me to write a blogpost. I cannot recall what it was about

  826. jubalh has joined

  827. tim@boese-ban.de has joined

  828. tim@boese-ban.de has joined

  829. moparisthebest

    how about the meaning of life

  830. Zash


  831. Guus

    jonasw: anything xmpp related? :)

  832. jonasw

    Guus: I cannot recall.

  833. vurpo has left

  834. vurpo has joined

  835. Guus

    ah, it was pretty obvious, actually: http://logs.xmpp.org/xsf/2017-03-13/#11:59:19

  836. vurpo has left

  837. vurpo has joined

  838. jonasw

    oh right

  839. Ge0rG has left

  840. vurpo has left

  841. Steve Kille has left

  842. vurpo has joined

  843. nicolas.verite has joined

  844. nicolas.verite has left

  845. nicolas.verite has joined

  846. nicolas.verite has left

  847. vurpo has left

  848. vurpo has joined

  849. kalkin has joined

  850. nicolas.verite has joined

  851. Lance has left

  852. vurpo has left

  853. vurpo has joined

  854. nyco has left

  855. nicolas.verite has left

  856. Yagiza has left

  857. Zash

    Was there someone asking why the mam:2 namespace bump was needed?

  858. Zash

    IIRC MattJ said things about security considerations that sounded reasonable. Integration with stanza-ids, and stuff.

  859. MattJ

    I think dwd was arguing that we should have had a "stanza-ids-are-mam-ids" feature instead of bumping the main namespace

  860. efrit has joined

  861. MattJ

    There were some other changes though (though not as many as I originally had in the doc when we decided to bump the namespace)

  862. dwd

    I couldn't *find* any other changes... Might well have been textual ones.

  863. jere has joined

  864. goffi has joined

  865. uc has left

  866. jere has joined

  867. Lance has joined

  868. winfried has left

  869. ralphm has joined

  870. SamWhited has left

  871. nicolas.verite has joined

  872. nicolas.verite has left

  873. iiro.laiho has joined

  874. jonasw has left

  875. daniel has left

  876. nyco has joined

  877. Martin has joined

  878. Martin has left

  879. blipp has left

  880. blipp has joined

  881. nicolas.verite has joined

  882. mimi89999 has left

  883. Guus has left

  884. nyco has joined

  885. iiro.laiho has left

  886. ralphm has left

  887. Flow has left

  888. jubalh has left

  889. nyco has left

  890. vurpo has left

  891. vurpo has joined

  892. vurpo has left

  893. vurpo has joined

  894. vurpo has left

  895. vurpo has joined

  896. nicolas.verite has left

  897. moparisthebest has joined

  898. nicolas.verite has joined

  899. kalkin has left

  900. kalkin has joined

  901. nyco has joined

  902. ralphm has left

  903. blipp has left

  904. blipp has joined

  905. nyco has left

  906. nicolas.verite has left

  907. nyco has joined

  908. boothj5 has joined

  909. arc has left

  910. arc has joined

  911. efrit has joined

  912. nicolas.verite has joined

  913. Tobias has left

  914. nicolas.verite has left

  915. nicolas.verite has joined

  916. Guus has left

  917. Flow has joined

  918. nyco has joined

  919. nicolas.verite has left

  920. kalkin has left

  921. Guus has left

  922. sezuan has left

  923. daniel has joined

  924. kaboom has left

  925. Zash has left

  926. boothj5 has left

  927. ralphm has left

  928. Lance has left

  929. Mancho has joined

  930. Ge0rG has joined

  931. Mancho has left