XSF Discussion - 2018-01-03

  1. Steve Kille has left

  2. la|r|ma has joined

  3. winfried has left

  4. winfried has joined

  5. dwd has left

  6. dwd has left

  7. dwd has left

  8. moparisthebest has left

  9. moparisthebest has joined

  10. lskdjf has joined

  11. dwd has left

  12. goffi has left

  13. lumi has joined

  14. la|r|ma has left

  15. jere has joined

  16. la|r|ma has left

  17. la|r|ma has joined

  18. la|r|ma has left

  19. lskdjf has joined

  20. Tobias has joined

  21. xnyhps has joined

  22. tux has left

  23. tux has joined

  24. Ge0rG has left

  25. dwd has left

  26. Tobias has joined

  27. dwd has left

  28. matlag has left

  29. matlag has joined

  30. matlag has left

  31. matlag has joined

  32. jere has joined

  33. moparisthebest has left

  34. moparisthebest has joined

  35. dwd has left

  36. ralphm has joined

  37. @Alacer has left

  38. @Alacer has joined

  39. moparisthebest has left

  40. moparisthebest has joined

  41. Ge0rG has left

  42. valo has left

  43. valo has joined

  44. sonny has joined

  45. moparisthebest has left

  46. Tobias has left

  47. Tobias has joined

  48. moparisthebest has joined

  49. efrit has joined

  50. dwd has left

  51. Tobias has left

  52. Tobias has joined

  53. ralphm has joined

  54. SouL has left

  55. efrit has left

  56. ralphm has joined

  57. tim@boese-ban.de has joined

  58. SouL has left

  59. valo has joined

  60. valo has joined

  61. Steve Kille has left

  62. Steve Kille has joined

  63. Steve Kille has left

  64. Steve Kille has joined

  65. lumi has joined

  66. zinid has joined

  67. lumi has joined

  68. sonny has joined

  69. ralphm has left

  70. Guus has joined

  71. Steve Kille has left

  72. Steve Kille has left

  73. Steve Kille has joined

  74. moparisthebest has left

  75. Guus has left

  76. Guus has joined

  77. ralphm has left

  78. Guus has left

  79. goffi has joined

  80. ralphm has joined

  81. ralphm has joined

  82. mimi89999 has joined

  83. Ge0rG has joined

  84. Guus has joined

  85. zinid has left

  86. zinid has joined

  87. tux has joined

  88. tux has joined

  89. Guus has left

  90. Guus has joined

  91. daniel has left

  92. uc has joined

  93. zinid has left

  94. winfried has left

  95. winfried has joined

  96. uc has joined

  97. Guus has left

  98. Alex has joined

  99. Guus has joined

  100. goffi has left

  101. winfried has left

  102. winfried has joined

  103. goffi has joined

  104. Guus has left

  105. Guus has joined

  106. uc has joined

  107. uc has joined

  108. Steve Kille

    does anyone have any idea why a fetch from github xsf/xeps is failing?

  109. Steve Kille

    I want to get the latest, so I can start on Dave's comments

  110. jonasw

    care to give more details?

  111. jonasw

    error message setc

  112. jonasw

    error messages etc

  113. Steve Kille

    Git GU says it is fetching, works for ages, and then complains connection timed out

  114. Steve Kille

    Has been fine before

  115. Steve Kille

    fatal: unable to access 'https://github.com/xsf/xeps/': Failed to connect to github.com port 443: Timed out

  116. jonasw

    hmm works for me

  117. jonasw

    can you open that https url manually in your browser?

  118. la|r|ma has joined

  119. Steve Kille

    fine in my browser

  120. Steve Kille

    pushes of commits to Guithub was working fine yesterday

  121. Steve Kille

    I did the fetch from a different network two days ago, so I guess it could be our proxy

  122. Guus has left

  123. Zash

    Proxies seem like a sensible thing to blame

  124. @Alacer has left

  125. @Alacer has joined

  126. daniel has left

  127. SouL has left

  128. SouL has left

  129. zinid has joined

  130. Steve Kille

    yup - proxy

  131. SouL has left

  132. Ge0rG has joined

  133. daniel has left

  134. daniel has joined

  135. Guus has joined

  136. lskdjf has joined

  137. SouL has left

  138. uc has joined

  139. uc has joined

  140. SouL has left

  141. zinid has left

  142. SouL has left

  143. valo has left

  144. valo has joined

  145. zinid has joined

  146. SouL has left

  147. marc has left

  148. matlag has left

  149. matlag has joined

  150. ralphm has joined

  151. Martin has joined

  152. uc has joined

  153. sonny has joined

  154. uc has joined

  155. intosi has left

  156. intosi has joined

  157. ralphm has left

  158. edhelas

    I'm thinking of extending 0277, having 2 nodes, one for public publication, one restricted to presences

  159. edhelas has left

  160. edhelas has joined

  161. @Alacer has left

  162. @Alacer has joined

  163. Martin has left

  164. Alex has left

  165. oachkatzl has joined

  166. oachkatzl has left

  167. oachkatzl has joined

  168. uc has left

  169. uc has joined

  170. vanitasvitae has left

  171. la|r|ma has joined

  172. la|r|ma has joined

  173. Alex has joined

  174. goffi

    edhelas: we have since talked in private, but for the record I have tried the 2 nodes options years ago, and it doesn't work that well. The fine permission tuning (aka items permissions) is the best option from my experience. I still need to propose a protoXEP, but lacking time to write one.

  175. vanitasvitae has joined

  176. uc has joined

  177. uc has joined

  178. uc has joined

  179. uc has joined

  180. @Alacer has left

  181. @Alacer has joined

  182. oachkatzl has left

  183. moparisthebest has joined

  184. SouL has joined

  185. ralphm has left

  186. Syndace has left

  187. Syndace has joined

  188. ralphm has joined

  189. matlag has left

  190. matlag has joined

  191. dwd has left

  192. dwd has joined

  193. uc has joined

  194. uc has joined

  195. uc has left

  196. uc has joined

  197. lskdjf has joined

  198. uc has joined

  199. uc has joined

  200. SamWhited has joined

  201. zinid has left

  202. zinid has joined

  203. lskdjf has joined

  204. sonny has left

  205. sonny has joined

  206. Ge0rG has left

  207. Ge0rG has left

  208. mimi89999 has joined

  209. ralphm has joined

  210. lskdjf has joined

  211. lskdjf has joined

  212. Ge0rG has left

  213. zinid has left

  214. daniel has left

  215. marc has left

  216. edhelas

    I'd like to know if we can deprecate 0084 and go back to the good old "presence notification" for vcards

  217. edhelas

    we have 2 solutions and I though after 5 years that everyone will move to a full PEP solution

  218. edhelas

    that didn't worked

  219. edhelas

    also it doesn't work for MUC vcards

  220. edhelas

    also barelly no client is implementing it https://nl.movim.eu/?about#caps_widget_tab

  221. SamWhited has left

  222. moparisthebest

    edhelas, did you see inputmice's talk about it?

  223. edhelas

    I was at the 34c3

  224. tim@boese-ban.de has left

  225. edhelas

    which talk ?

  226. moparisthebest

    might have been that one, doesn't that fix the problem server-side ?

  227. edhelas

    I didn't been to his talk then

  228. edhelas

    what was it about

  229. moparisthebest

    I'm trying to find a link but not having any luck yet

  230. edhelas


  231. Alex has left

  232. moparisthebest

    yep that's it specifically https://github.com/iNPUTmice/talks/blob/master/2017_12_27_-_jabber_xmpp_the_past_the_presence_and_the_future.md#avatars

  233. moparisthebest

    it's not perfect, but you see what happens when we try to create perfect, we get MIX, and it never goes anywhere

  234. lskdjf has joined

  235. edhelas


  236. moparisthebest

    can I officially propose the future cut-down-to-useable-proportions MIX replacement be called MUX ?

  237. edhelas

    I just read about MUC-SUB https://docs.ejabberd.im/developer/xmpp-clients-bots/proposed-extensions/muc-sub/

  238. edhelas

    it's quite great, also retro-compatible

  239. zinid has joined

  240. moparisthebest

    ah will read, I was only aware of https://xmpp.org/extensions/inbox/muc-light.html

  241. moparisthebest

    but retro-compatible sounds great

  242. daniel has left

  243. Ge0rG

    We could probably make a MUC-actor thing where your account joins MUCs on your behalf.

  244. Ge0rG

    Maybe even without changing the protocol.

  245. moparisthebest

    and requiring all user's servers to be updated would be a good test for how feasible mix is :)

  246. Ge0rG

    There are voices saying that the big servers will update fast.

  247. goffi

    is there any server MIX implementation based on current specs ? I know about the one from Ejabberd but it was on first draft and I don't think it has been maintained.

  248. edhelas


  249. edhelas

    Muc/Pub is used by several clients in production as well

  250. moparisthebest

    which ones?

  251. winfried has left

  252. zinid has left

  253. zinid has joined

  254. Holger

    moparisthebest: Commercial ones.

  255. zinid has left

  256. zinid has joined

  257. zinid has left

  258. zinid has joined

  259. Alex has joined

  260. daniel has left

  261. dwd

    goffi, We have a MIX implementation, but it's not quite the current spec.

  262. goffi

    dwd: is it public, can we test it ?

  263. dwd

    goffi, It is public-ish - in surevine's github in our Openfire fork. You'll need a real database, though - the embedded one doesn't work.

  264. dwd

    goffi, Also, no presence, since we didn't need that.

  265. goffi

    dwd: ok cool. Would be nice to have a simple wiki page with links to current implementations, so the day I want to start client implementation I can select a server one.

  266. la|r|ma has left

  267. la|r|ma has joined

  268. moparisthebest has joined

  269. moparisthebest

    you need 2 server implementations though

  270. moparisthebest

    uh, in that your server needs support, as well as a mix component

  271. moparisthebest

    so when looking for server support you need those 2 different things right?

  272. MattJ

    It means MIX is going to take years (that's years + whatever time it takes to get implementations released)

  273. MattJ

    Because MIX is not usable by the ordinary user if they can't just invite anyone on their contact list, and most people are going to be running from OS packages

  274. moparisthebest

    years or never, like privacy lists, original archiving etc

  275. MattJ

    Privacy lists was pretty widely implemented, back in the day, actually :)

  276. MattJ

    Just with a terrible UI

  277. Ge0rG

    Damn, where's my "told you so" stamp?

  278. moparisthebest

    especially if you have something simple that solves 99% of use cases and is backwards compatible, like maybe this muc-sub thing, haven't read it yet

  279. edhelas

    Ge0rG you didn't had enough ink to stamp last time, need to buy more

  280. edhelas

    muc-sub seems to be a good 50%-50% between the two XEPs

  281. Syndace has left

  282. lovetox has joined

  283. daniel has left

  284. goffi has left

  285. Ge0rG has left

  286. Steve Kille has left

  287. Steve Kille has left

  288. uc has joined

  289. uc has joined

  290. ralphm has left

  291. Steve Kille has joined

  292. SouL has joined

  293. uc has joined

  294. SouL has left

  295. dwd has left

  296. uc has joined

  297. Flow

    moparisthebest: which "future cut-down-to-useable-proportions MIX replacement"?

  298. uc has joined

  299. jjrh has left

  300. had-hoc has left

  301. had-hoc has joined

  302. __ has joined

  303. __


  304. __ has left

  305. had-hoc has left

  306. lumi has joined

  307. dwd has left

  308. moparisthebest

    Flow, all I know is it should be called MUX

  309. moparisthebest

    I'm just assuming there will be one in the great tradition of the XSF

  310. Ge0rG

    Flow: is it possible that smack will never cache entity caps for JIDs it didn't previously receive presence from? https://github.com/igniterealtime/Smack/blob/master/smack-extensions/src/main/java/org/jivesoftware/smackx/disco/ServiceDiscoveryManager.java#L510

  311. Holger has left

  312. Ge0rG has left

  313. had-hoc has joined

  314. Flow

    moparisthebest, i'm not sure about it, but I would really like a little competition

  315. had-hoc has left

  316. jjrh has left

  317. had-hoc has joined

  318. Flow

    Ge0rG, possible, I think Smack should maybe calcucate the version itself

  319. Ge0rG

    Flow: yeah. Just noticed that in smack3, I only have persistent cache items from my own caps

  320. Flow

    I can tell from the variable naming that this is veery old code ;)

  321. Ge0rG

    it's actually the same in smack3:P

  322. jjrh has left

  323. had-hoc has left

  324. Flow

    looks like a good incentive to start on caps2

  325. ralphm has left

  326. had-hoc has joined

  327. jjrh has left

  328. dwd has left

  329. had-hoc has left

  330. had-hoc has joined

  331. Flow

    on a second look, that code locks correct, and is covered by integration tests

  332. ralphm has joined

  333. Ge0rG has left

  334. had-hoc has left

  335. had-hoc has joined

  336. had-hoc has left

  337. had-hoc has joined

  338. valo has joined

  339. valo has joined

  340. winfried has joined

  341. ralphm has joined

  342. had-hoc has left

  343. had-hoc has joined

  344. Guus has left

  345. Guus has joined

  346. SamWhited has joined

  347. goffi has joined

  348. SouL has left

  349. had-hoc has left

  350. Tobias has joined

  351. SouL has left

  352. Guus has left

  353. had-hoc has joined

  354. Guus has joined

  355. had-hoc has left

  356. SamWhited has left

  357. had-hoc has joined

  358. daniel has left

  359. daniel has joined

  360. had-hoc has left

  361. had-hoc has joined

  362. sonny has joined

  363. sonny has joined

  364. had-hoc has left

  365. zinid has left

  366. had-hoc has joined

  367. zinid has joined

  368. Syndace has joined

  369. pep.

    reading daniel's talk re avatars. Does 0153 really requires you to download your own avatar on every connection? If you have it locally you can just hash it and compare to what the server is sending you, right?

  370. sonny has left

  371. sonny has joined

  372. daniel

    pep.: how do you know it hasn't been changed by another client?

  373. pep.

    You hash the one you have locally and compare it, if it's not the same your redownload it

  374. pep.

    I mean there's not need to download it _everytime_

  375. pep.


  376. zinid has joined

  377. moparisthebest

    don't you have to download it to calculate the hash?

  378. pep.

    You have a copy locally right?

  379. pep.

    What's different from PEP here?

  380. moparisthebest

    how does that tell you what's on the server?

  381. pep.

    "A client MUST NOT advertise an avatar image without first downloading the current vCard", that's meh

  382. pep.


  383. pep.

    Isn't there a way that the server sends back a hack of the current avatar instead?

  384. lovetox

    what do you mean with is there a way

  385. lovetox

    like with a current xep?

  386. sonny has joined

  387. lovetox

    no, but it would probably be trivial to add to 0153 that the server sends the hash on request

  388. pep.

    Well, not 0084, as it doesn't work in groupchats

  389. lovetox


  390. pep.


  391. lovetox

    but downloading a vcard is really nothing i would sweat about

  392. zinid has left

  393. pep.

    I don't know, daniel put it in "downsides" in his talk

  394. lovetox

    i guess on mobile it is sometimes a downside

  395. lovetox

    and its not particular pretty

  396. pep.

    yeah but it's not like it couldn't be fixed

  397. lovetox

    but nothing that would stop me implementing it

  398. moparisthebest

    pep., more trivial than not changing the xep and having a server plugin just do it all for you? :P

  399. moparisthebest

    either way you are writing code and deploying it to a server

  400. moparisthebest

    I like daniel 's approach better

  401. pep.

    moparisthebest, sure, things take time. But 153 has been out for a while now

  402. lovetox

    but 153 is historical

  403. lovetox

    i dont think these are meant to be changed

  404. pep.


  405. pep.

    How do you change that? You fork it?

  406. moparisthebest

    what problem are you trying to solve

  407. lovetox

    and do a pr, but i guess this will not make it :)

  408. moparisthebest

    why would you try to solve it with a xep change, client change, and server change

  409. moparisthebest

    when you could solve it with just a server change, and end up with a simpler client using less bandwidth?

  410. pep.

    lovetox, yeah, honestly I don't really care

  411. pep.

    I have enough GB on my plan so that it doesn't matter at all

  412. moparisthebest

    it's not really that, it's the added time a connection takes in my opinion

  413. pep.

    I just find sad that we have to go through convoluted ways (PEP -> vcard) to fix this kind of things

  414. moparisthebest

    the other way sounds far more convoluted

  415. pep.

    How so? Making people update their software ?

  416. pep.

    How so? Making people update their software?

  417. daniel

    > I just find sad that we have to go through convoluted ways (PEP -> vcard) to fix this kind of things I find that extremely simple and straightforward

  418. daniel

    And it's already supported by the important servers

  419. moparisthebest

    pep., again "xep change, client change, and server change, and clients use more bandwidth" vs "server change (major servers already support it)"

  420. moparisthebest

    which sounds easier and more preferable?

  421. pep.

    So that means if I want to implement a server, I'll have to support both 0153 _and_ 0084 (and PEP) for avatars? Plus also the PEP -> vcard thing

  422. pep.

    How isn't this convoluted

  423. pep.

    (No I'm not planning to implement a server, still I hope you get my point)

  424. moparisthebest

    ok, well you have to support both 0153 _and_ 0084 anyway

  425. moparisthebest

    I guess you might complain about converting, but a sane structure would have you storing them in the same place anyway?

  426. Guus has left

  427. Guus has joined

  428. pep.

    I'm complaining about the workarounds mostly. I'm not sure how fixing a historical XEP works, but adding a "Server returns vcard hash" wouldn't be difficult

  429. pep.

    heh, the compliance suite doesn't state 153 at all?

  430. moparisthebest

    also your argument seems to be make it slightly easier to write a new server by making all existing servers add features to existing historical plugins

  431. moparisthebest

    still not buying it

  432. moparisthebest

    when in doubt go with the simplest thing that works

  433. moparisthebest


  434. pep.

    moparisthebest, not "historical plugins" no, just "mostly used solutions", just like edhelas showed above, 0084 isn't really implemented anywhere

  435. pep.

    Also 0084 doesn't work anyway, re groupchats

  436. daniel

    I'd rather you not write a new server in the first place

  437. pep.

    daniel, sure

  438. pep.


  439. moparisthebest

    I'm just waiting for Link Mauve to write a server in rust so I can switch

  440. pep.

    I don't think xmpp-rs is going to be designed for servers

  441. moparisthebest

    I don't care what library he uses :)

  442. pep.

    heh. I don't think he's mad enough to do that anyway

  443. Link Mauve

    You never know!

  444. pep.

    I know you're mad, don't worry

  445. moparisthebest

    on a side note, why are the majority of major xmpp servers written in crazy esoteric languages :)

  446. Link Mauve


  447. moparisthebest

    does that say something about the people who use xmpp :'(

  448. pep.

    Link Mauve, any idea what's become of Freyskeyd and his talk of writing a server?

  449. pep.


  450. pep.

    fn it_works() {} :)

  451. Link Mauve

    pep., he seems to have stopped working on his library altogether.

  452. moparisthebest

    "It's goal is to be fully tested and usable."

  453. moparisthebest

    he is halfway there (it's fully tested)

  454. pep.

    it even says it works!

  455. Guus has left

  456. moparisthebest

    is anyone aware of any xmpp test domains for client and/or server devs to test proper srv fallback etc ?

  457. moparisthebest

    similar to like http://www.dnssec-failed.org/ for testing dnssec

  458. moparisthebest

    many, possibly most, clients and such don't end up falling back correctly or at all turns out

  459. moparisthebest

    like they fallback if the port isn't listening, but not if it sends invalid xml, or doesn't support ciphers it likes, or various other errors

  460. suzyo has joined

  461. Holger

    moparisthebest: You're suggesting Rust for an internet service and complaining about esoteric language choices?

  462. moparisthebest

    no I think rust would neatly fall in there right now

  463. moparisthebest

    (the esoteric lang category)

  464. Holger

    pep.: I think it's right to have the complexity on the server side.

  465. Link Mauve

    moparisthebest, you can use OpenFire or Tigase, for a very non-esoteric language.

  466. Link Mauve

    There is also Jabberd and Jabberd2.

  467. Link Mauve

    People have been writing one in PHP and one in JS too IIRC.

  468. Link Mauve

    I would know, I’ve written one in JS.

  469. Link Mauve

    (Never again. ;_;)

  470. moparisthebest

    I'd guess ejabberd/prosody/openfire is most of the public network though, and if so, that's 66% esoteric langs :P

  471. moparisthebest

    and my guess is openfire is distant 3rd there

  472. Tobias has joined

  473. ralphm has left

  474. Kev has joined

  475. @Alacer has left

  476. @Alacer has joined

  477. SouL has joined

  478. ralphm has joined

  479. Alex has joined

  480. winfried has left

  481. jere has joined

  482. uc has joined

  483. uc has joined

  484. la|r|ma has joined

  485. SamWhited has left

  486. ralphm has joined

  487. suzyo has joined

  488. mimi89999 has joined

  489. pep.

    Holger, what annoys me the most is that, from what I understand, we're just choosing the path of least resistance for the features we want out there. Yes we are mostly volonteers, and I get we don't have all the time we want. Plus users are running old software (debian I'm looking at you), etc., Still I don't think we should stop here

  490. pep.

    "That only has to be implemented server-side, let's prefer that over X", I'm not really into this kind of thought

  491. moparisthebest

    pep., good luck getting anything actually put into use then :) (looking at you MIX yet again)

  492. pep.

    daniel, do you have stats btw of what version of Conversations people are using?

  493. jere has joined

  494. pep.

    Or maybe services like jabberfr do? (Link Mauve, mathieui)

  495. daniel

    pep.: no

  496. mathieui

    pep., I don’t think there’s a prosody module for that yet

  497. Holger

    pep.: The amount of madness a client developer new to XMPP is confronted with is insane. Avatar support is a very basic IM feature. We should be able to show him a simple XEP he needs to implement to make avatars 'just work'. If server-side hacks help with hiding the compatibility madness from him, I'd prefer those hacks.

  498. jere has joined

  499. pep.

    For this particular case I'm not sure what's best, implement PEP _and_ 0084 _and_ 0153, or fix 0153 to have the small fix we talked about earlier, and implement only that

  500. pep.

    As a client developer, maybe I'm biased :P

  501. moparisthebest

    so implement only the historical one?

  502. moparisthebest

    seems questionable

  503. Alex has left

  504. pep.

    moparisthebest, if you come up with a non-historical just for the sake of it, that has the same features, and make people use it, why not

  505. moparisthebest

    I'm also under the impression the pep one is easier for clients

  506. Holger

    Well but by now both are implemented.

  507. pep.

    That's why people are trying to shoehorn everything into PEP?

  508. ralphm has joined

  509. moparisthebest

    it's done, accept the fact and move on 😛

  510. Holger

    I don't know why they are. I would've been opposed to that if I had been around back then.

  511. pep.

    moparisthebest, I would if it worked

  512. Holger

    I'm just saying we have both now, and we either deal with that or we break interop.

  513. moparisthebest

    omemo requires it too

  514. moparisthebest

    probably other things I don't really know about?

  515. daniel

    Neither 84 nor 153 are particularly difficult to implement.

  516. daniel

    On the client side that is

  517. pep.

    daniel, it's just an example

  518. daniel

    For what?

  519. pep.

    For what I said to Holger above, we're just choosing the path of least resistance, "because this way we'll have it implemented and usable no matter how ugly/workaroundy that is"

  520. pep.

    That's just a feeling, I would be happy to be proven wrong

  521. sonny has left

  522. sonny has joined

  523. daniel

    I have quite the opposite impression. The Xsf is the textbook example of perfect is the enemy of good. That's why we have so many widely deployed XEPs stuck in experimental.

  524. moparisthebest

    if you want to fully reinvent the wheel pull a matrix :)

  525. daniel

    That's why we have been working on mix for three years now

  526. pep.

    moparisthebest, that's not my point.

  527. pep.

    daniel, true

  528. moparisthebest

    I agree daniel my impression is we create a complex monster of a xep where all possible usecases have to be fulfilled rather than a much simpler solution that fills 90% of usecases

  529. pep.

    so.. MIX and avatars are two extremes? :p

  530. daniel

    pep., moparisthebest: fwiw I'm not trying to be overly negative towards mix here. But choosing the complex solution over the much simpler one that fills 90% of the use cases is a pattern I see in a lot of XEPs

  531. pep.

    daniel, gotcha. I guess I wasn't around long enough

  532. uc has joined

  533. winfried has left

  534. zinid has joined

  535. uc has joined

  536. jjrh has left

  537. jjrh has left

  538. uc has joined

  539. pep.

    Anybody implementing 0306?

  540. pep.

    -xep 306

  541. Bunneh

    pep.: Extensible Status Conditions for Multi-User Chat (Standards Track, Deferred, 2016-06-07) See: https://xmpp.org/extensions/xep-0306.html

  542. uc has joined

  543. jjrh has left

  544. moparisthebest has left

  545. moparisthebest has left

  546. MattJ

    pep., none that I know of

  547. marc has left

  548. ralphm has joined

  549. had-hoc has left

  550. edhelas has left

  551. edhelas has joined

  552. lumi has left

  553. goffi has left

  554. goffi has left

  555. valo has joined

  556. jjrh has left

  557. jjrh has left

  558. daniel has left

  559. goffi has left

  560. jere has joined

  561. tux has left

  562. dwd has left