XSF Discussion - 2019-02-05

  1. pep.

    How bad would it be to s/http:\/\/xmpp\.org/https:\/\/xmpp\.org/ in the xeps repo? Do I have any chance of breaking normative language

  2. Zash

    You'll find that one place where someone used http://xmpp.org in a xmlns

  3. pep.

    I feel http://jabber.org is used most often (when not urn:xmpp), but yeah I guess

  4. Zash


  5. Zash

    xeps$ ack http://xmpp.org/protocol inbox/sxe.xml 262: <query xmlns='http://xmpp.org/protocol/disco#info'/> 268: <query xmlns='http://xmpp.org/protocol/disco#info'> xep-0284.xml 268: <query xmlns='http://xmpp.org/protocol/disco#info'/> 274: <query xmlns='http://xmpp.org/protocol/disco#info'>

  6. pep.


  7. pep.


  8. pep.


  9. Zash

    That's gotta be a typo for jabber.org/protocol tho?

  10. pep.

    Ok I'll be careful then

  11. pep.

    Probably in examples?

  12. pep.

    let's see

  13. Zash

    xep-0397.xml has a bunch of xmlns="https://xmpp.org/....

  14. pep.

    that's fine, I won't change this one :P

  15. pep.

    But yeah that should be fixed

  16. Zash

    https://xmpp.org/extensions/xep-0284.html#host this points to xep 30, so looks like a mistake

  17. pep.

    With a bit less effort we should probably add HSTS first

  18. pep.

    The 301 is already there

  19. karoshi1 has left

  20. pep.

    What about: "<p>The &REGISTRAR; shall add 'urn:xmpp:idle:1' to its registry at <link url='https://xmpp.org/registrar/namespaces.html'>https://xmpp.org/registrar/namespaces.html</link>.</p>" ? Is that normative? the registrar uri

  21. Zash


  22. pep.

    (I changed to https in this quote)

  23. Zash

    It is technically a completely different URL, that doesn't have to have the same content as the http: URL

  24. remko has joined

  25. pep.

    err, I don't have access to the nginx that should do HSTS, do I

  26. pep.

    This docker thing only serves 80

  27. Zash

    <meta name='horrible-hack-no-372' http-equiv='strict-transport-security' value='max-age=infinity'>

  28. pep.


  29. labdsf has joined

  30. Neustradamus has left

  31. pep.

    Technically I can already do that with the nginx inside, but that will send it on both http and https, and it's invalid on http (or just useless?)

  32. Zash

    wasn't 80 just serving a redirect?

  33. pep.

    I should be able to check for x-forwarded-proto maybe

  34. pep.

    Zash, 80, as seen from the outside, yes

  35. pep.

    Not from the container

  36. Zash


  37. Zash

    the outside won't see hsts on port 80?

  38. pep.


  39. pep.

    HSTS SHOULD(MUST?) only be on https

  40. Zash

    so if the container spits it out on port 80, which is reverse-proxied to port 443 with tls

  41. Zash

    then it should all be in order

  42. moparisthebest

    Browsers will ignore it over http

  43. pep.

    It will also spit it on http. But then maybe as I said I can check for X-Fowarded-For

  44. pep.

    moparisthebest, sure

  45. moparisthebest

    So it's fine to send it either way

  46. pep.

    browsers are as compatible as one can be, because the web if full of crap

  47. moparisthebest

    The point is they never visit http again anyhow?

  48. pep.

    I just like to do things properly :x

  49. moparisthebest

    Don't forget to set up a redirect to https from http, and put it in the preload list :)

  50. pep.

    it's already there

  51. Zash

    pep.: if the public port 80 is configured to only s/http/https/ then I don't see how anyone can get hsts via http

  52. moparisthebest

    Do things properly, the web, bahaha :)

  53. pep.

    So I might as well ask iteam directly

  54. pep.

    And not put this hack in the xeps repo

  55. pep.

    Zash, true.

  56. pep.

    Still that's probably not something for the xeps repo

  57. pep.

    Maybe the website, but I feel that should go in the host's conf

  58. Zash

    Is there a container that contains the conainer-container that holds the 7th proxy?

  59. jmpman has joined

  60. UsL has left

  61. UsL has joined

  62. pep.

    Anyway, I should stop procrastinating the procrastination

  63. pep.

    Anyway, I should stop procrastinating procrastination

  64. Alex has left

  65. remko has left

  66. Zash has left

  67. rtq3 has left

  68. rtq3 has joined

  69. mimi89999 has joined

  70. rtq3 has left

  71. rtq3 has joined

  72. j.r has left

  73. j.r has joined

  74. Neustradamus

    It will be nice to have same base for all without www. etc

  75. lskdjf has joined

  76. waqas has joined

  77. mimi89999 has joined

  78. moparisthebest has left

  79. jmpman has joined

  80. moparisthebest has joined

  81. moparisthebest has left

  82. moparisthebest has joined

  83. wurstsalat has joined

  84. kokonoe has left

  85. rtq3 has left

  86. rtq3 has joined

  87. j.r has left

  88. lskdjf has left

  89. mrDoctorWho has left

  90. Maranda has joined

  91. Maranda has joined

  92. neshtaxmpp has joined

  93. neshtaxmpp has joined

  94. alexis has joined

  95. alexis has left

  96. lumi has left

  97. matlag has joined

  98. rtq3 has left

  99. rtq3 has joined

  100. Yagiza has joined

  101. mrDoctorWho has left

  102. Yagiza has left

  103. lskdjf has joined

  104. lskdjf has joined

  105. Yagiza has joined

  106. mrDoctorWho has joined

  107. mrDoctorWho has left

  108. jmpman has joined

  109. ThibG has joined

  110. mrDoctorWho has left

  111. Nekit has joined

  112. rtq3 has left

  113. remko has joined

  114. lskdjf has joined

  115. 404.city has joined

  116. remko has left

  117. 404.city has left

  118. kokonoe has joined

  119. vaulor has joined

  120. thorsten has left

  121. ThibG has left

  122. ThibG has joined

  123. lorddavidiii has joined

  124. Tobias has joined

  125. Tobias has left

  126. Tobias has joined

  127. j.r has joined

  128. waqas has left

  129. moparisthebest has joined

  130. mimi89999 has joined

  131. jmpman has joined

  132. l has joined

  133. jmpman has joined

  134. sezuan has left

  135. labdsf has left

  136. lnj has joined

  137. sezuan has left

  138. sezuan has left

  139. j.r has joined

  140. remko has joined

  141. andy has joined

  142. kokonoe has left

  143. kokonoe has joined

  144. Alex has joined

  145. Maranda has joined

  146. Maranda has joined

  147. andy has left

  148. andy has joined

  149. vaulor has left

  150. Tobias has joined

  151. lorddavidiii has left

  152. lorddavidiii has joined

  153. ralphm has joined

  154. kokonoe has left

  155. Steve Kille has left

  156. neshtaxmpp has joined

  157. architekt has joined

  158. Steve Kille has joined

  159. kokonoe has joined

  160. architekt has left

  161. jmpman has joined

  162. frainz has left

  163. frainz has joined

  164. lovetox has joined

  165. frainz has left

  166. frainz has joined

  167. APach has left

  168. APach has joined

  169. karoshi has joined

  170. sezuan has left

  171. Guus has left

  172. edhelas

    I'm really tired of refusing OMEMO requests

  173. edhelas

    I'm thinking of hardcoding the body detection and starting to reply automatically

  174. Guus has left

  175. Ge0rG

    edhelas: just blacklist the OMEMO node on your PEP

  176. lovetox

    whats a OMEMO request?

  177. edhelas

    > I sent you an OMEMO encrypted message but your client doesn’t seem to support that. Find more information on https://conversations.im/omemo

  178. labdsf has joined

  179. lovetox

    tell your contacts to disable omemo?!

  180. thorsten has left

  181. edhelas

    yes, one by one :) if at one moment they move to conversations

  182. Ge0rG

    lovetox: that's O(N*M)

  183. Ge0rG

    with N=number of contacts and M=number of devices each contact has

  184. edhelas

    I'm not there to do "remote xmpp client configuration over human written messages"

  185. lovetox

    hm in Gajim you can deactivate publishing keys to the node

  186. lovetox

    but yes this problem exists because you use a client that supports omemo ..

  187. Ge0rG

    because you once used such a client

  188. Ge0rG

    if you are on prosody < 0.11, you can restart your server to "fix" it

  189. edhelas

    yes I do use Conversations sometimes, and Movim 95% of the rest of the time

  190. ralphm

    pep.: there are some, mostly deferred/retracted, XEPs that use http://xmpp.org/ as the start of their namespace. I'd leave them be. If we ever resurrect them, they'd have to go with a urn one anyway.

  191. lovetox

    fastest way would probably to set the devicelist node to whitelist

  192. Ge0rG

    edhelas: write a Movim plugin that subscribes to the siacs namespace and removes all devices

  193. Ge0rG

    or what lovetox said

  194. lovetox

    Ge0rG that does not help

  195. lovetox

    as devices are instantly republished

  196. lovetox

    you can configure nodes in Gajim 🙂

  197. ralphm

    pep.: and probably everything that still has shtml in a link should get looked at.

  198. jmpman has joined

  199. moparisthebest has joined

  200. vanitasvitae

    edhelas: does movim support Explicit Message Encryption?

  201. edhelas

    vanitasvitae I as looking into that

  202. vanitasvitae

    You could use that to determine, if a message is omemo encrypted or not

  203. vanitasvitae

    Might be better than to check the body

  204. edhelas

    conversations is adding the tag ?

  205. vanitasvitae

    Pretty sure it does

  206. edhelas


  207. Ge0rG

    lovetox: how do you configure PEP in Gajim? I've opened the "Configure services.." menu on my server, but there are no items listed and the buttons are greyed out, except for "Close"

  208. lovetox

    because your server does not support configuring nodes

  209. Ge0rG

    lovetox: would be awesome to have that displayed in that box

  210. lovetox

    yes once i rework the dialog, its still from ancient times

  211. Ge0rG

    Ah, the Good Old Times!

  212. pep.

    What happened about the LC on 345 BTW, did I miss any decision made about it?

  213. goffi has joined

  214. Ge0rG

    pep.: I suppose the Board needs to vote on advancing it next.

  215. Ge0rG

    Or maybe somebody can make a PR incorporating LC feedback

  216. thorsten has left

  217. mimi89999 has left

  218. Ge0rG

    dwd: I would kindly ask you to put https://github.com/xsf/xeps/pull/752 and XEP-0410 advancement on the next Council agenda. cc jonas’

  219. kokonoe has left

  220. Zash has left

  221. moparisthebest has joined

  222. moparisthebest has joined

  223. kokonoe has joined

  224. igoose has joined

  225. igoose has joined

  226. ralphm

    Ge0rG: with the Summit happening, we haven't had a meeting to discuss the LC feedback on XEP-0345 yet. Thursday is the first opportunity.

  227. Ge0rG

    pep.: ^

  228. Ge0rG

    There was also a Board PR that Council was asked to look into.

  229. ralphm has left

  230. Zash has left

  231. architekt has joined

  232. wurstsalat has joined

  233. architekt has left

  234. rtq3 has joined

  235. j.r has joined

  236. goffi

    hey there. I was thinking this morning, it would be nice to have a QR code with my jid in it on my website, so people could get it easily from phone, and it would be nice to have a way to make it easy to recognise. It's possible to put an image inside QR codes, so would not it be nice to agree on something (e.g. putting XMPP logo inside) so we could know immediatly "OK this is a XMPP identifier"? Would it make sense to have an informational XEP on this?

  237. ta has left

  238. ta has joined

  239. Ge0rG

    goffi: yes, you can increase the FEC on QR codes and then just bump some picture over the middle

  240. Guus

    sounds like a fun little shareable service.

  241. goffi

    Ge0rG: FEC?

  242. jonas’

    (forward error correction)

  243. pep.

    Wasn't it "the image isn't part of the standard, it's just ignored with error correction"

  244. Ge0rG

    goffi: forward error correction. Also related: https://github.com/ge0rg/easy-xmpp-invitation

  245. jonas’

    although I’% not entirely sure that’s the correct term for QR codes

  246. pep.

    hah, right

  247. jonas’

    although I’m not entirely sure that’s the correct term for QR codes

  248. goffi

    I know it's possible, that why I'm proposing it, we don't need much characters for a jid.

  249. Ge0rG

    jonas’: but it still is FEC.

  250. jonas’


  251. Ge0rG

    just because people invent new fancy names... 🤷

  252. pep.

    goffi, what do you want to do with "a JID"?

  253. pep.

    Add as contact?

  254. goffi

    pep.: yes

  255. goffi

    not only on website, on visit card too

  256. Ge0rG

    goffi: what if the person scanning the code doesn't have a Jabber client yet?

  257. goffi

    I just want a way to recognise immediately "oh this is a jid"

  258. pep.

    goffi, have a look at what Ge0rG pasted

  259. Ge0rG

    I'd put a Jabber lightbulb in it.

  260. pep.

    We can probably just put a QR code there

  261. goffi

    Ge0rG: it's the same issue with a xmpp:myjid@example.net link.

  262. pep.


  263. goffi

    my point is just to have a way to recognise the QR code as XMPP related.

  264. Ge0rG

    goffi: I've heard you are good at webdev.

  265. mightyBroccoli has left

  266. mightyBroccoli has joined

  267. goffi

    using http or xmpp is an other thing. There are issues with http (you have to keep a service, and it won't be catched by registered client). But that's not the point of my idea, I just wonder if it would make sense to agree on a way to recognise XMPP QR Code (image inside is one thing, we could also play with colors).

  268. Ge0rG

    > it won't be catched by registered client yaxim will catch both yax.im and conversations.im landing pages

  269. goffi

    Ge0rG: what do you mean ? I'm working with web sometimes yes, and on a XMPP web framework.

  270. pep.

    I'd have a QR code with the XMPP logo (to add to the bikeshed discussions)

  271. Ge0rG

    goffi: the easy-xmpp-invitation project is looking for volunteers 😁

  272. goffi

    Ge0rG: and what I have gajim ?

  273. Ge0rG

    goffi: how do you scan images in Gajim?

  274. debacle has joined

  275. goffi

    Ge0rG: I would love to help on that, but I'm already close to burn out with my paid job + work on SàT + all side stuff (like preparing FOSDEM)

  276. Ge0rG

    goffi: alright, thanks anyway :)

  277. rion has left

  278. rion has joined

  279. goffi

    Ge0rG: I was mentioning gajim for the contact link, a xmpp:toto@example.net will work there, https://yax.im/i/#vladimir@xmpp.example wont

  280. rtq3 has left

  281. rtq3 has joined

  282. thorsten has left

  283. Ge0rG

    goffi: on my OS, Gajim doesn't handle xmpp: URIs

  284. goffi

    is it possible with QR code to have 2 links ? A http: one and a xmpp: one ?

  285. Ge0rG

    nope. But the landing page contains an xmpp: link ;)

  286. goffi

    what if the size is down ?

  287. goffi


  288. pep.

    Then it's down I guess

  289. dele has joined

  290. goffi

    xmpp: will still work. I mean I get the point with https: link, and I agree on most of them, but the xmpp: is the standard way of doing, it's not linked to an entity, in short it has many advantages too.

  291. goffi

    it's not linked to a client or service*

  292. pep.

    goffi, what if your xmpp server is down

  293. Ge0rG

    goffi: it's got many advantages, but it doesn't work for normal people.

  294. pep.

    Will the other server resend the subscription request(?)

  295. goffi

    pep.: it won't prevent you to add the contact, after the subscription will happen when it will be up again.

  296. Tobias has left

  297. pep.

    goffi, ok. I wouldn't mind having the xmpp: uri in there, but then you only target people already present on xmpp

  298. goffi

    best way would be to find a way to have both in a easy way, but doesn't looks like possible.

  299. pep.

    (I agree we're mixing two issues, but I don't know how to entangle them)

  300. mtavares

    have two qr codes...

  301. mtavares

    just to make it more complicated.

  302. pep.

    mtavares, I think that's be even more confusing

  303. mtavares

    using a http link works well enough, me thinks.

  304. pep.

    "So which one is it??" "It's the same" "Why do you have two then?" -- my mom

  305. goffi


  306. goffi

    it seems possible

  307. mtavares

    ahh.. interesting.

  308. pep.

    goffi, it's just text right, you put whatever format you want in there

  309. Wiktor has left

  310. Tobias has left

  311. Wiktor has joined

  312. jonas’

    pep., QR codes have multiple subformats for different payloads

  313. pep.

    I see

  314. jonas’

    partly because they use different codes for different payloads to save bits

  315. pep.

    And of course this website only accepts URLs

  316. Zash has left

  317. pep.

    not XMPP URIs

  318. goffi

    ah it's just redirecting and shows the 2 links

  319. goffi

    pep.: yes I know, but the QR code readed need to know how to handle both.

  320. mtavares

    it's just a https link to qr-creator.

  321. goffi

    mtavares: yes, so not good :(

  322. dele has left

  323. Tobias has left

  324. Ge0rG


  325. Ge0rG


  326. goffi

    I like more the second one

  327. goffi

    it's neat :)

  328. pep.

    yeah me too

  329. Ge0rG

    This is the moment to complain about our well-known marketing name being absolutely burned, and our official protocol name being too technical for regular people.

  330. pep.

    Maybe just remove the "XMPP" from there

  331. pep.

    So you don't have to pronounce it.

  332. goffi

    yeah the logo only is fine I think

  333. goffi

    also I think the text could be used for something else.

  334. goffi

    for instance, would it make sense to distinguish QR Code depending on their use: for instance a contact to add, or an ad-hoc command to execute, or a pubsub service ?

  335. goffi

    so you would but the XMPP logo, and "contact" under it instead of "xmpp"

  336. Ge0rG

    did I mention that normal people in our region consider QR codes as something awkward?

  337. goffi

    why ?

  338. Ge0rG


  339. goffi

    nearly everybody is getting use to it, it's a nice techno

  340. Ge0rG


  341. Andrew Nenakhov has left

  342. ta

    I have it on my applications as vCard. I still hope some technical employer finds it nerdy.

  343. Zash has left

  344. Ge0rG

    ta: do you have a utm tag in it?

  345. ta

    well, i don't have a link in it, so no...

  346. ta

    I mean application as in paper/pdf. QR-code being just contact information as vcard.

  347. ta

    But i should consider tracking when applying at some online shops. they like everything i try to block ;-)

  348. lnj has left

  349. Andrew Nenakhov has left

  350. Andrew Nenakhov has joined

  351. rtq3 has left

  352. rtq3 has joined

  353. lnj has joined

  354. Zash has left

  355. lovetox

    woever wrote me a pm here, i cant answer because converse does not support pm 😃

  356. ta

    <-- is just asking about the gajim muc not beeing reachable from some servers.

  357. lovetox

    ta, would be interested what the error is

  358. lovetox

    im joined and im on jabber.at currently

  359. equil has joined

  360. ta

    if you guide me. gajim and xml console didn't give me much feedback.

  361. ta

    you can guess my JID, so we don't spam here. I am using trashserver.net (no comments on that name ;-)

  362. lovetox

    but it should, restart gajim open xml console, join the muc and maybe wait for 1 minute, whatever the servers timeout is, at one point your server should inform you why its not possible to connect

  363. lovetox

    otherwise ask the admin

  364. architekt has joined

  365. Zash

    lovetox: Looks like a IPv6 problem, please try to fix it.

  366. lovetox

    can you be more specific

  367. lovetox

    im not the server admin, but i can tell him

  368. Ge0rG

    If only XMPP servers could gracefully support both IPv4 and IPv6

  369. Ge0rG looking at Zash

  370. architekt has left

  371. architekt has joined

  372. Ge0rG

    lovetox: traceroute to conference.gajim.org (2001:bc8:342f:101::1), 30 hops max, 80 byte packets ... 5 * * * 6 2001:bc8:400:1::8e (2001:bc8:400:1::8e) 27.964 ms 28.068 ms 28.263 ms 7 2001:bc8:400💯:26 (2001:bc8:400💯:26) 25.912 ms 26.035 ms 26.204 ms 8 * * * ...

  373. ta has left

  374. pep. has left

  375. Zash

    Ha. Blame Link Mauve

  376. Ge0rG

    Zash: is he behind gajim.org?

  377. pep. has left

  378. pep. has left

  379. Link Mauve

    No I’m not.

  380. Zash

    No, why I bumped a timeout back up to the point where it gives up completely before trying the next IP

  381. Ge0rG

    Zash: you bumped Link Mauve?

  382. Ge0rG

    can't you unbump him?

  383. Zash

    Link Mauves toaster was too slow for the low timeout

  384. ta

    Well is this the cause already? I restarted gajim, have a very spammy xml console...

  385. Ge0rG

    Zash: can't you also increase the *other* timeout then?

  386. Maranda has joined

  387. Maranda has joined

  388. Ge0rG

    Zash: it's a bit shortsighted to break connectivity for all users of prosody just because of Link Mauve

  389. lovetox

    ta i reported it to asterix but will not be fixed immediatly

  390. Zash

    Actually, this specific configuration still works because the write timeout here is 60s and the "give up completely" timeout is 90s

  391. Zash

    But ... this varies

  392. dwd

    Hi all. Do we have an incremental update for disco#items and things? I've a feeling that Sem Whited documented something that HipChat did a while back but I can't find it.

  393. jonas’

    what do you mean by incremental update?

  394. neshtaxmpp has joined

  395. ta

    lovetox, thanks. No hurry. I was just surprised that nobody "cared" in all the other XMPP-centric MUCs ;-)

  396. dwd

    So if I have cached, for example, all the disco#items, and I now want to find what's changed instead of downloading the entire list again.

  397. dwd

    Sorta like XEP-0237 for Disco.

  398. Zash

    lovetox: The prosody module mod_bidi might help a bit, since it reduces the number of connections that can fail

  399. Zash

    dwd: Isn't that caps?

  400. Zash

    Or you want caps on ... things?

  401. Zash

    Or disco-sub or whatsitcalled?

  402. dwd

    Not caps. Though caps on ... things would be nice, actually - good plan.

  403. dwd

    But caps doesn't do disco#items.

  404. Zash


  405. Zash

    Did caps2 do that?

  406. Zash

    I'm sure we discussed some semi-recursive caps thingy recently

  407. dwd

    But yeah, if I have 1.2 quadzillion MUCs, I'd like to just fetch the three new ones and not the 1.2 quadzillion over again.

  408. jonas’

    caps isn’t really incremental, either

  409. Zash

    Yeah. Figuring that out would be nice.

  410. dwd

    jonas’, Yes, indeed.

  411. rtq3 has left

  412. jonas’

    disco#items versioning essentially

  413. dwd

    I can't recall if we decided that Sam's proposal should be a XEP or even if he submitted it.

  414. Zash

    I was leaning towards not returning complete results in disco#items at all and defering to some search interface

  415. jonas’

    I don’t recall anything in that direction

  416. Ge0rG


  417. Zash

    I only recall that there was "disco-(pub)sub"

  418. dwd

    But otherwise, I'll do a ProtoXEP based around '237's design if there's interest.

  419. dwd

    Ge0rG, RSM is good for paging, less good for incremental update.

  420. Zash

    RSM is also weird if items can be removed

  421. Guus

    dwd hipchat has a couple of features documented here https://docs.atlassian.com/hipchat.xmpp/latest/xmpp/rooms.html

  422. Guus

    the room push comes closest to what you describe

  423. dwd

    Or... I could do it based on pubsub, and then list disco#items things in a pubsub node... somewhere.

  424. Guus

    (it also does something with service discovery - but that does not seem to match your description)

  425. Zash

    dwd: But if you have 1.2 quadzillion MUCs, having a cache of them locally is probably not fun anyways

  426. Ge0rG

    dwd: did we solve the multiple-items-per-node pubsub problem yet?

  427. Zash

    Ge0rG: What problem is that?

  428. dwd

    Zash, True, but I have a way of having a set of MUCs I'm interested in anyway. The problem is that I have a lot of them.

  429. dwd

    Zash, Also, caching 1.2 quadzillion items is not fun, but fetching them anew every time is even less fun.

  430. jonas’

    dwd, wouldn’t some type of search interface make more sense then?

  431. dwd

    Perhaps, but I do have a few cases where I want all the disco#items.

  432. pep. has left

  433. j.r has joined

  434. dele has joined

  435. flow

    dwd: I am not sure, but you are maybe looking for https://xmpp.org/extensions/xep-0366.html

  436. flow

    But I guess for a delta sync of disco#items you probably want something like disco#items versioning…

  437. Zash

    How many implement the incemental roster versioning thing?

  438. j.r has joined

  439. dele has left

  440. dele has joined

  441. karoshi has left

  442. karoshi has joined

  443. jmpman has joined

  444. lumi has joined

  445. j.r has joined

  446. Nekit has left

  447. Nekit has joined

  448. ta has left

  449. ralphm

    dwd: having a pubsub node to represent available channels would definitely be interesting.

  450. jmpman has joined

  451. ralphm

    dwd: with RSM, it would be much easier to keep lists on the client side in sync.

  452. 404.city has joined

  453. dwd has left

  454. ralphm

    We kind of already have a specification for this with `pubsub#subscription_type` with the value of `nodes`, and using that in subscription options towards the root node.

  455. Ge0rG

    dwd: did you receive my message further above regarding Council Agenda additions for tomorrow?

  456. ralphm

    https://xmpp.org/extensions/xep-0248.html#notify-items suggests there's a `<create/>` element in pubsub#event to be used for notifications, but the schema in XEP-0060 doesn't current have that.

  457. l has joined

  458. dwd has left

  459. l has left

  460. architekt has joined

  461. dele has left

  462. architekt has left

  463. architekt has joined

  464. goffi

    I have no time to check it now, but is not this RELOAD protoxep doing something similar to jingle?

  465. l has joined

  466. Zash

    Based on what dwd wrote, I wonder if it's rather something for the IETF?

  467. j.r has joined

  468. lskdjf has joined

  469. architekt has left

  470. lorddavidiii has left

  471. lorddavidiii has joined

  472. lorddavidiii has left

  473. neshtaxmpp has joined

  474. lorddavidiii has joined

  475. Guus has left

  476. Alex has left

  477. l has joined

  478. ralphm

    Too bad the date on the inbox entries are all from yesterday.

  479. pep. has left

  480. pep. has joined

  481. pep. has joined

  482. debacle

    goffi, to me XOR looks more like 0174 (Serverless), but with NAT traversal

  483. jonas’

    XOR depends on '174 AFAICT

  484. goffi

    OK, I've just overlooked and it looked like a way to establish a stream.

  485. goffi

    interesting then, I'll check that later.

  486. moparisthebest has joined

  487. Tobias has joined

  488. moparisthebest has joined

  489. efrit has joined

  490. sezuan has left

  491. j.r has joined

  492. moparisthebest has left

  493. krauq has left

  494. equil has left

  495. equil has joined

  496. krauq has joined

  497. dwd

    Ge0rG, I've not noticed it, and would welcome an email. Travelling tonight at short notice, and I'll try to do the agenda stuff on the train.

  498. Tobias has left

  499. jmpman has joined

  500. Ge0rG

    dwd: sure thing

  501. dwd

    So, XEP-0366 is more or less what I was after. I think including caps, though, is probably interesting too.

  502. Zash

    "I have stuff with caps hash xxxx, what's changed since?"

  503. jmpman has joined

  504. Maranda has joined

  505. Maranda has joined

  506. Tobias has left

  507. alacer has joined

  508. Zash


  509. MattJ

    oh no

  510. Andrew Nenakhov has left

  511. MattJ

    > Appendix A. Changes from Unicode 6.3.0 to Unicode 7.0.0 > Changes from derived property value UNASSIGNED to either PVALID or DISALLOWED.

  512. andy has left

  513. Andrew Nenakhov has joined

  514. Andrew Nenakhov has joined

  515. debacle has left

  516. j.r has left

  517. j.r has joined

  518. edhelas has left

  519. edhelas has joined

  520. alacer has left

  521. alacer has joined

  522. matlag has left

  523. Ge0rG

    In the context of RELOAD, I'd suggest defining an XMPP wire-format to exchange X.509 CSRs and CRTs, which could be immediately plugged into a XMPP JID-identity CA

  524. dwd

    Zash, No, caps can be an all-or-nothing for disco#info. But it'd save me a huge amount in this particular instance. I think an entityver thing would help with disco#items, though.

  525. vaulor has joined

  526. lorddavidiii has left

  527. j.r has joined

  528. lorddavidiii has joined

  529. goffi has joined

  530. lovetox has left

  531. Zash has left

  532. Nekit has left

  533. Nekit has joined

  534. waqas has joined

  535. ThibG has joined

  536. ThibG has joined

  537. Nekit has left

  538. Nekit has joined

  539. efrit has left

  540. ralphm

    MattJ: so RFC 7622 will need an update?

  541. ralphm has left

  542. Nekit has left

  543. Nekit has joined

  544. Guus has left

  545. goffi has joined

  546. Zash has left

  547. Ge0rG has left

  548. Zash has left

  549. lovetox has joined

  550. pep.

    ralphm, thinking about <gone/> again for <moved/>, and MUC affiliations/PubSub subscriptions. I can't just return <gone/> for everything that comes pinging my account for privacy reasons. And my server doesn't know (could know, but allegedly doesn't track) these subscriptions, so..

  551. lnj has joined

  552. ralphm

    Well, if you want to leave some kind of tombstone, but only to selected people, you kinda have to keep the former relationships, whichever way.

  553. alacer has left

  554. pep.

    It will work for contacts, because we have the roster

  555. pep.

    But that's about the extent of what the server keeps track of, in the general case

  556. ralphm

    I suppose for pubsub subscriptions it might be harder indeed.

  557. jonas’

    and MUC affiliations

  558. pep.

    Not even talking about server shutting down etc. yet

  559. ralphm

    But this is one of the reasons why dwd suggested PAM, so that your server keeps track for you. When you move, you could take that with you.

  560. pep.

    (I'm thinking about not considering this use-case for a first rewrite of <moved/>)

  561. pep.


  562. ralphm


  563. Ge0rG

    pep.: the hard question with roster is how to tell multiple clients of your friend, if the first client will replace unsubscribe your old JID.

  564. pep.

    Ge0rG, yes I got that, you don't have to repeat it over and over, that wasn't the question

  565. pep.

    I know we need a tombstone of some sort, and that was discussed

  566. Zash

    pep.: This came up at summit, about needing to keep the roster, or maybe some magic hash of it

  567. pep.

    Zash, "this"?

  568. Ge0rG

    you could create a PEP node with a whitelist populated with your roster when moving.

  569. Ge0rG

    pep.: what's the question then? Who is allowed to see your tombstone? Either everyone or old-roster-only, I suppose

  570. pep.

    Ge0rG, no that wasn't the question

  571. pep.

    Ah well, yes sorry

  572. pep.

    But not for the roster

  573. pep.

    I'm asking for muc affiliations and pubsub subscriptions (read the question)

  574. Ge0rG


  575. ralphm

    so couldn't you whitelist the muc services on your bookmark list (private storage or PEP) and the pubsub nodes you have received notifications from?

  576. Ge0rG

    there is no way to enumerate all your MUCs and PubSub subscriptions, unless your PAM keeps track of them all, from day 1

  577. pep.

    Using bookmarks for MUC seems interesting

  578. pep.

    But yeah for PubSub we'd need PAM or sth

  579. Ge0rG

    bookmarks probably contain the relevant subset (what do you care if you are affiliated with a MUC you never joined)

  580. ralphm

    *also*, besides leaving a tombstone, there's no reason why you couldn't send a presence with forwarding address

  581. pep.

    presence is ephemeral

  582. ralphm

    not for muc rooms

  583. Ge0rG

    it might suffice to let PubSub and MUCs know.

  584. ralphm

    i.e. you only need to have it received once

  585. Ge0rG

    but you don't know where to send, in the first place

  586. pep.

    Technically the server can know

  587. pep.

    But yes that has to be done from day1

  588. ralphm

    wouldn't you likely cover this by the list of muc servers that you frequent rooms of?

  589. ralphm

    unless 100% is your goal, in which case good luck

  590. jonas’

    gateways & transports are another topic

  591. pep.

    I would hope services GC after some time being unresponsive

  592. jonas’

    a tricky one, actually

  593. jonas’

    I wouldn’t want to loose my biboumi MAM because I moved accounts

  594. pep.


  595. pep.

    We're really trying to sort all the problems in the world at the same time :/

  596. pep.

    This thing is never going to progress

  597. jonas’

    I’m calling it "enumerating"

  598. jonas’

    I don’t expect your proposal to solve all of them

  599. pep.

    jonas’, I guess it's time for a client-side MAM? :/

  600. jonas’

    but it should enumerate them all, and clearly distinguish between those which are solvable and solved, those which are likely solvable and deferred and those which are not likely solvable

  601. jonas’

    client side MAM?

  602. pep.

    So that you can just ditch the server archive once you've fetched it, and then have your mobile ask your desktop client for archives

  603. jonas’

    yea, no

  604. pep.

    Why not

  605. ta has joined

  606. jonas’

    I don’t want to implement the server side of MAM things in a client

  607. jonas’

    huge complexity, especially with Smart MAM ahead

  608. pep.


  609. jonas’

    (and how about the clients which have the "I don’t want to store everything locally anyways" philosophy)

  610. pep.

    It's really not the first time I hear about it though

  611. jonas’

    yeah, you hear from it mostly from crypto fashionistas

  612. pep.


  613. jonas’

    who want to solve the PFS problem with a huge pile of complexity

  614. Ge0rG

    ...and then end up talking with people who just dump everything into sqlite

  615. pep.

    Anyway, this is not a crypto party, the topic is different

  616. Ge0rG

    but you can't just just expose your new JID to every entity that claims to be a pubsub node.

  617. jonas’

    in any case, client side MAM won’t solve the biboumi case

  618. jonas’

    you don’t want to have that all stored on your phone anyways

  619. pep.

    jonas’, it would yes? I think

  620. ralphm

    I see this problem as moving house. You let your friends know. In the Netherlands you have a service that informs (selected) entities of your new address so they can update their records. Also, the occupant typically temporarily forwards stuff to you.

  621. ralphm

    (new occupant)

  622. goffi has joined

  623. ralphm

    You never reach 100%, and that's fine.

  624. Ge0rG has left

  625. pep.

    Right. So we're inevitably going to drop mail, but yeah it's fine

  626. pep.

    They'll recontact us, (or not)

  627. ralphm

    And the rest of it is usually a thing you solve socially, out of band, not technically.

  628. alacer has joined

  629. pep.

    Ge0rG, would you be ready to compromise on that <moved/> thing, or do you want to get all the use-cases into the one XEP

  630. pep.

    If so, I'll split efforts because I'd like to have something ready by 2025 not 2030

  631. pep.

    (I'm being generous)

  632. Ge0rG

    pep.: you know, I was like you, back then in 2018. I thought "how hard can it be". But then I started work. And I realized...

  633. Ge0rG

    So, what exactly do you want to compromise?

  634. Zash

    pep.: privacy problem of gone, needing to keep the roster

  635. Ge0rG

    Also persistent PEP with a configurable access model.

  636. pep.

    I want to drop the "My server is offline" use-case. I am not sure I'll be able to support "My server is scheduled for shutdown" entirely either, because we need tombstones

  637. pep.

    But I guess if your server shutdown is planned in 6 months time, that's already quite enough time to migrate most of your contacts

  638. Ge0rG

    pep.: do you want to drop muc affiliation and pubsub?

  639. pep.

    I don't know. At the moment I see it as something the server will have to keep track of for us, unless you have a client-side solutions

  640. Ge0rG

    Do you want to support users migrating from prosody < 0.11?

  641. pep.

    non-persistent PEP?

  642. pep.

    No I don't care

  643. pep.

    People please update.

  644. pep.

    Well, there is MAM, I can do with that if you really want

  645. Ge0rG

    A cryptographic identity overlay network that works over XMPP as the routing layer

  646. pep.

    yeah no thanks

  647. alacer has left

  648. pep.

    I wouldn't mind trying to make it future proof, as in, compatible with a possible crypto thingy that would come on top, if that's possible. But I'd like to have something out soon

  649. pep.

    Actually PEP/MAM are not necessary if we do <gone/>, on the old server.

  650. Ge0rG

    The old server must support it then.

  651. Ge0rG

    Also access permissions

  652. pep.

    The old server must support RFC 6120?

  653. pep.

    I hope it does

  654. pep.

    Ah ok I see

  655. pep.

    hmm, we can prompt for support, and if not fallback(?) how is that

  656. Ge0rG

    > Also access permissions

  657. Ge0rG

    Is there a protocol to *configure* gone on your account?

  658. pep.

    Yes, we can prompt for support on the old server, and if not PEP/MAM?

  659. alacer has joined

  660. pep.

    We talked about adding that to IBR, so that'd be a new thing indeed

  661. MattJ

    The problem with PEP is that it needs to be explicitly checked or subscribed to, and works on a client level

  662. Ge0rG

    So you'd say the default access permissions for <gone/> will be the user's last roster?

  663. MattJ

    <gone> errors in response to probes are much nicer

  664. MattJ

    But do require support from the migrating server

  665. pep.

    MattJ, sure, they all require support on different level..

  666. pep.

    *Somebody* has to support *something* :(

  667. Ge0rG

    pep.: sending messages to all your contacts doesn't.

  668. pep.

    Ge0rG, yes, clients need to understand MAM, and the moved payload

  669. Ge0rG

    pep.: I wanted to make a protocol that gracefully degrades if it's only supported by clients on both sides.

  670. pep.

    How far did you get

  671. Ge0rG

    pep.: messages with a moved payload from the old and from the new account. MAM / Carbons on the receiving side as faux persistence.

  672. pep.

    (all these french words)

  673. Ge0rG

    pep.: maybe a private PEP node on the receiving side where the first client can store the Moved from-to pair

  674. pep.

    yeah I remember these discussions, and I'm fine with that

  675. pep.

    I thought that was dealt with already

  676. Ge0rG

    But then there is a nice race condition on populating that PEP node.

  677. rtq3 has joined

  678. Ge0rG

    pep.: not written down yet.

  679. pep.

    Ok, let's do it then

  680. Ge0rG

    pep.: you want to continue the work? I can commit and push my last sad state.

  681. Ge0rG

    A compliant server could process a Moved PEP node on your account, and send a gone error to entities that are allowed to read that pep node

  682. Ge0rG

    Or maybe always send the gone, but only fill the JID if permitted.

  683. sezuan has left

  684. pep.

    yeah that's details to me at this stage

  685. pep.


  686. Ge0rG

    pep.: https://github.com/ge0rg/xeps/tree/xep-0283

  687. Ge0rG

    that's the code behind the rendered version I forgot to tell you before Summit.

  688. pep.


  689. goffi has joined

  690. pep.

    I wouldn't actually mind only including compliant servers or clients in my assumptions, tbh

  691. pep.

    Deployment is an issue, and we all know that. My goal is not to solve this. (/me eyes non-rolling release distributions)

  692. Zash has left

  693. rtq3 has left

  694. rtq3 has joined

  695. Zash has left

  696. Zash has left

  697. dwd has left

  698. moparisthebest

    but a feature that only requires clients to upgrade will be adopted faster, especially if users want it, because it's fully under their control

  699. pep.

    But their contacts also need to support it

  700. pep.

    So maybe not that fast

  701. moparisthebest

    not if they can fall back

  702. moparisthebest

    like 'oh you don't support automatic roster migration? ok send message "hi I was x@x now I'm y@y"

  703. Ge0rG

    with the main reason for this being "abandonden servers" I'd pull the line at modern client support

  704. pep.

    Ge0rG, it's not my main reason fwiw

  705. lskdjf has left

  706. pep.

    My main reason is services like quicksy, or any other public services, which are great for adoption, but then users might want to move away from that

  707. Ge0rG

    I've heard there are ~250 users on Quicksy.

  708. pep.


  709. pep.

    "or any other public services"

  710. moparisthebest

    then it has to be a client-only feature

  711. pep.

    moparisthebest, why does it have to

  712. moparisthebest

    public services that don't want people to move away would just never enable it?

  713. moparisthebest

    especially if they get $ from users, directly or data mining (google)

  714. pep.

    Yeah I'm not considering evil services tbh, that's another can of worms

  715. moparisthebest

    I'm not talking about evil

  716. pep.

    Why would they block then

  717. moparisthebest

    client-only doesn't work with actively evil either, they can block stanzas etc

  718. pep.


  719. pep.

    Any server can just block the PEP node

  720. moparisthebest

    I'm talking about "should I download and install/configure this plugin that makes it easier for users to leave?"

  721. moparisthebest

    why would they do extra work for that?

  722. pep.

    moparisthebest, if it's a PEP node it's no extra work

  723. lskdjf has left

  724. moparisthebest

    so that's client-only?

  725. pep.

    PEP is not client-only no

  726. pep.

    Neither is MAM. They all require server support

  727. moparisthebest

    yea but it doesn't require specific server support is all I meant

  728. pep.

    Yes it does

  729. moparisthebest

    not for this specific thing

  730. Yagiza has left

  731. moparisthebest

    just PEP in general that's used for lots of other things?

  732. pep.

    Yes yes

  733. pep.

    So here's your reason why they would set it up

  734. pep.

    So the feature can require server support

  735. moparisthebest

    yea that all sounds fine then

  736. moparisthebest

    I just meant if it required all servers to upgrade before it was useable, it'd be worthless and never adopted

  737. moparisthebest

    think MIX

  738. pep.

    Well there are still prosody < 0.11 out there, and it's going to be the case for a while

  739. rtq3 has left

  740. moparisthebest

    so you are, vaguely, publishing a pep node as old@old.com saying you've moved to new@new.com ?

  741. pep.

    Yeah. And that tombstone should stay up for your contacts' devices to see.

  742. lskdjf has left

  743. lskdjf has left

  744. moparisthebest

    I tended to like what Ge0rG called a 'cryptographic overlay' better, it's maybe a bit more complicated, but not too much

  745. lskdjf has left

  746. ralphm has left

  747. pep.

    I don't mind having that as a goal for later, in a different XEPs, with different goals (including moar uses-cases)

  748. mtavares has left

  749. moparisthebest

    vaguely, you publish a public key, your contacts save this (public key for old@old.com), then if a new account sends a subscription request with a message "I was old@old.com but now am new@new.com" signed by old@old.com's key, you know to update it

  750. moparisthebest

    not that much more complicated, supports everything that does plus the (I would think) common usecase of a server disappearing

  751. lskdjf has joined

  752. pep.

    You don't actually need crypto fwiw

  753. lskdjf has joined

  754. pep.

    Except if your old server is _already_ offline

  755. pep.

    But then you're probably not in a good position anyway

  756. moparisthebest

    that seems like a valuable usecase to support though

  757. pep.

    Yeah, I'm not worried about it for now, but you're welcome to

  758. moparisthebest

    so is yours, uh, lazy

  759. pep.

    And you should have preemptively declared your key if that's the case

  760. moparisthebest

    it relies on all your contacts checking your old PEP node every time?

  761. pep.

    They can check it once and be done

  762. moparisthebest

    once every time the client connects or?

  763. pep.

    Once they've acked it

  764. j.r has joined

  765. moparisthebest

    it doesn't react to being sent a message though?

  766. pep.

    I don't understand

  767. moparisthebest

    it checks pre-emptively for all roster contacts?

  768. pep.


  769. moparisthebest

    your client

  770. pep.

    Yeah, you +notify on the node

  771. lskdjf has joined

  772. moparisthebest

    so when a client logs in it has to check them all too I guess

  773. j.r has joined

  774. j.r has joined

  775. lskdjf has left

  776. pep.


  777. moparisthebest

    xep-27 already announces a key even, 'moved' could just define a signed payload for "I've moved"

  778. moparisthebest

    seems far simpler

  779. moparisthebest

    > so when a client logs in it has to check all pep nodes for all roster contacts all too I guess

  780. lskdjf has joined

  781. pep.

    A client doesn't "Check", notifications gets pushed to it, but sure

  782. moparisthebest

    even notifications sent before the client logs in?

  783. equil has joined

  784. lskdjf has joined

  785. pep.

    Sure, you say add +notify in your disco stuff and the server will resend it (I think?). You'll receive the last event

  786. pep.

    Sure, you add +notify in your disco stuff and the server will resend it (I think?). You'll receive the last event

  787. moparisthebest

    if I understand it's just adding a bunch more login traffic, at least one extra outgoing stanza and an ack per contact?

  788. moparisthebest

    vs the key thing, which supports all the same use-cases, plus missing server, with no extra login traffic?

  789. pep.

    There's no extra login traffic if there's no event. And once you've seen the event on contactX, you can unsubscribe from it.

  790. pep.

    what key thing

  791. moparisthebest

    crypto signed "i've moved" roster subscription messages from the contact that moved

  792. pep.

    But then in my use-case you'd need an extra PEP node on your own account mapping old-jid -> new-jid of your contacts, so that all your devices can ACK.

  793. pep.

    Then you do that from MAM?

  794. pep.

    You can also use MAM without crypto. And that's how Ge0rG implements it for now in his draft

  795. moparisthebest

    isn't the roster stored on the server? can't only 1 client change it then?

  796. moparisthebest

    technically the server could change it and not involve clients

  797. pep.

    So what's your use-case then, do you want the server to be involved or not

  798. moparisthebest

    that server involvement would be optional, on the non-moving client's end?

  799. moparisthebest

    wouldn't need to be mentioned in the XEP, the server could just optionally do it instead of the client

  800. pep.

    That can be mentioned in the XEP yes, and we already had something like that in mind.

  801. moparisthebest

    I tend to think moved that doesn't support a server going away in the future wouldn't be very useful

  802. pep.

    I think it is

  803. pep.

    And that'd be my main use-case

  804. moparisthebest

    my point is that if you do it a slightly different way, it supports both use cases

  805. pep.

    "slightly" meaning crypto?

  806. Steve Kille has left

  807. pep.


  808. moparisthebest


  809. Steve Kille has left

  810. moparisthebest

    you aren't inventing primitives or anything scary, just signing a message and verifying a signature?

  811. pep.

    You don't need crypto for most of what you just said

  812. pep.

    If your use-case if "server going away in the future", you don't need crypto

  813. pep.

    As your identity provider is still alive

  814. moparisthebest

    ok let me clarify, I mean "I'm gonna go ahead and publish this now, and still want to be able to use it to move if my server goes away in the future"

  815. lnj has joined

  816. Steve Kille has joined

  817. pep.

    publish where

  818. moparisthebest

    either signed presence like xep-27 or a PEP node?

  819. pep.

    Ok so what about non-supporting contact clients (which is a concerned that's been raised), at the time you published it, until you server went down

  820. pep.

    Also presence won't work, it's ephemeral

  821. peter has joined

  822. moparisthebest

    but you could save the key from the first presence you see or something, in your client

  823. pep.

    If you support it, sure

  824. moparisthebest

    non-supporting clients I think is the same regardless of method, if they don't advertise support, your client sends them a manual message?

  825. pep.

    And if you see it, in the first place

  826. moparisthebest

    (after it moves I mean)

  827. pep.

    Which is why I just don't want to worry about this use-case. With the current changes we have in moved, nothing prevents you to also publish your signed payload

  828. lnj has joined

  829. Zash has left

  830. lorddavidiii has left

  831. labdsf has joined

  832. rtq3 has joined

  833. equil has left

  834. equil has joined

  835. labdsf has left

  836. labdsf has joined

  837. Zash has left

  838. rtq3 has left

  839. rtq3 has joined

  840. rtq3 has left

  841. rtq3 has joined

  842. rtq3 has left

  843. rtq3 has joined

  844. Andrew Nenakhov has joined

  845. Andrew Nenakhov has left

  846. Andrew Nenakhov has joined

  847. wurstsalat has joined

  848. lskdjf has joined

  849. goffi has joined

  850. krauq has joined

  851. peter has left

  852. sezuan has left

  853. Nekit has left

  854. Nekit has joined

  855. lskdjf has joined

  856. Andrew Nenakhov has left

  857. tux has left

  858. Guus has left

  859. Guus has left

  860. lskdjf has left

  861. krauq has joined

  862. lskdjf has left

  863. Guus has left

  864. lskdjf has left

  865. Guus has left

  866. Andrew Nenakhov has left

  867. Andrew Nenakhov has left

  868. lnj has left

  869. lnj has joined

  870. labdsf has joined

  871. sezuan has left

  872. marc_ has left

  873. mimi89999 has joined

  874. jmpman has joined

  875. goffi has joined

  876. Guus has left

  877. Lance has joined

  878. igoose has left

  879. igoose has joined

  880. j.r has left

  881. j.r has joined

  882. peter has joined

  883. peter has left

  884. rtq3 has left

  885. rtq3 has joined

  886. Andrew Nenakhov has left

  887. lskdjf has joined

  888. goffi has joined

  889. remko has left

  890. rtq3 has left

  891. rtq3 has joined

  892. j.r has joined

  893. j.r has joined

  894. rtq3 has left

  895. rtq3 has joined

  896. efrit has joined

  897. intosi has left

  898. goffi has joined

  899. j.r has joined

  900. j.r has joined

  901. ralphm has left

  902. labdsf has left

  903. labdsf has joined

  904. Tobias has joined

  905. Nekit has joined

  906. Lance has left

  907. lnj has left

  908. goffi has joined

  909. lnj has left

  910. lnj has joined

  911. goffi has joined

  912. equil has left

  913. Seve has left

  914. j.r has left

  915. j.r has joined

  916. j.r has left

  917. j.r has joined

  918. lnj has left

  919. j.r has joined

  920. j.r has joined

  921. moparisthebest has joined

  922. vaulor has left

  923. jeroen has joined

  924. peter has joined

  925. jeroen has left

  926. jeroen has joined

  927. jeroen has left

  928. jeroen has joined

  929. MattJ has joined

  930. jeroen has left

  931. jeroen has joined

  932. goffi has joined

  933. jeroen has left

  934. Zash has left

  935. jeroen has joined

  936. peter has left

  937. jeroen has left

  938. j.r has joined

  939. j.r has joined

  940. Lance has left

  941. jeroen has joined

  942. goffi has joined

  943. jeroen has left

  944. Zash has left

  945. jeroen has joined

  946. lskdjf has left

  947. jeroen has left

  948. sezuan has left

  949. jeroen has joined

  950. labdsf has left

  951. jeroen has left

  952. jeroen has joined

  953. labdsf has joined

  954. jeroen has left

  955. jeroen has joined

  956. rion has left

  957. jeroen has left

  958. jeroen has joined

  959. jeroen has left

  960. jeroen has joined

  961. jeroen has left

  962. jeroen has joined

  963. jeroen has left

  964. goffi has joined

  965. lovetox has left

  966. krauq has joined

  967. remko has joined

  968. rtq3 has left

  969. rtq3 has joined

  970. Maranda has joined

  971. Maranda has joined

  972. krauq has joined

  973. lnj has left

  974. jmpman has joined

  975. remko has left

  976. lskdjf has joined

  977. lskdjf has left

  978. lskdjf has joined

  979. matlag has left

  980. goffi has joined

  981. Zash has left