XMPP Council - 2020-09-30


  1. paul has left

  2. SouL has left

  3. Wojtek has left

  4. stpeter has joined

  5. stpeter has left

  6. kusoneko has left

  7. kusoneko has joined

  8. adityaborikar has left

  9. adityaborikar has joined

  10. moparisthebest has left

  11. SouL has joined

  12. Tobias has joined

  13. paul has joined

  14. sonny has left

  15. sonny has joined

  16. sonny has left

  17. sonny has joined

  18. sonny has left

  19. sonny has joined

  20. sonny has left

  21. sonny has joined

  22. sonny has left

  23. sonny has joined

  24. sonny has left

  25. sonny has joined

  26. sonny has left

  27. sonny has joined

  28. sonny has left

  29. sonny has joined

  30. sonny has left

  31. sonny has joined

  32. sonny has left

  33. sonny has joined

  34. paul has left

  35. paul has joined

  36. adityaborikar has left

  37. adityaborikar has joined

  38. debacle has joined

  39. sonny has left

  40. sonny has joined

  41. sonny has left

  42. adityaborikar has left

  43. adityaborikar has joined

  44. sonny has joined

  45. sonny has left

  46. sonny has joined

  47. sonny has left

  48. neox has joined

  49. sonny has joined

  50. sonny has left

  51. debacle has left

  52. sonny has joined

  53. sonny has left

  54. sonny has joined

  55. sonny has left

  56. adityaborikar has left

  57. adityaborikar has joined

  58. sonny has joined

  59. adityaborikar has left

  60. adityaborikar has joined

  61. debacle has joined

  62. adityaborikar has left

  63. adityaborikar has joined

  64. neox has left

  65. neox has joined

  66. neox has left

  67. neox has joined

  68. neox has left

  69. neox has joined

  70. Syndace has left

  71. sonny has left

  72. sonny has joined

  73. stpeter has joined

  74. moparisthebest has joined

  75. sonny has left

  76. sonny has joined

  77. sonny has left

  78. stpeter has left

  79. sonny has joined

  80. sonny has left

  81. sonny has joined

  82. sonny has left

  83. sonny has joined

  84. sonny has left

  85. sonny has joined

  86. sonny has left

  87. sonny has joined

  88. sonny has left

  89. sonny has joined

  90. Syndace has joined

  91. sonny has left

  92. sonny has joined

  93. sonny has left

  94. sonny has joined

  95. adityaborikar has left

  96. adityaborikar has joined

  97. sonny has left

  98. sonny has joined

  99. sonny has left

  100. adityaborikar has left

  101. sonny has joined

  102. stpeter has joined

  103. sonny has left

  104. sonny has joined

  105. sonny has left

  106. sonny has joined

  107. Ge0rG

    I don't think I'll make it, but I'm +1 on the CS2021 XEP

  108. Ge0rG

    And on-list for the other items

  109. dwd has joined

  110. jonas’

    1) Roll Call

  111. Zash

    Here

  112. daniel

    Hi

  113. dwd

    Hello

  114. jonas’

    Hi everyone

  115. jonas’

    Ge0rG sent apologies, so moving on

  116. jonas’

    2) Agenda Bashing

  117. jonas’

    Assuming nothing

  118. jonas’

    3) Editor’s Update

  119. jonas’

    - New ProtoXEP: Compliance Suites 2021 - LC for XEP-0411 extended until 2020-10-14 after the original extension got lost in the void.

  120. jonas’

    yeah, no idea what went wrong with that email, this one seems to have passed through

  121. jonas’

    4) Items for Voting

  122. jonas’

    (sorry for being terse today)

  123. jonas’

    4a) PR#986: XEP-0277: pubsub#type MUST be set in bare PubSub URL: https://github.com/xsf/xeps/pull/986

  124. jonas’

    I am on-list, I didn’t have the chance to read into what pubsub#type even is :)

  125. Zash

    I saw daniel comment that this is Experimental and thus not our thing to approve

  126. daniel

    what Zash said what I said

  127. Zash

    (actually Deferred, but still)

  128. jonas’

    right, so this is not an item for vote, but an AOB

  129. jonas’

    since pep. explicitly asked for guidance

  130. jonas’

    let’s move it there and discuss it then, thanks for the hint

  131. Zash

    ack

  132. jonas’

    4b) PR#988: XEP-0060: Add integer-or-max datatype to use with Data Forms Validation URL: https://github.com/xsf/xeps/pull/988 Note: The idea behind is to formally define the behaviour of the max-items field in PubSub.

  133. pep.

    !

  134. daniel

    As I said on the list; I'd be willing to +1 this unless someone really wants to put this somewhere 60-agnostic

  135. daniel

    but i'm not even fully sure that 122 is a better place

  136. Zash

    Assuming the schema magic is sane, +1. It would be nice if the registry was working ;)

  137. jonas’

    '122 wouldn’t be a better place either

  138. jonas’

    '122 wouldn’t be a better place I think

  139. jonas’

    '60 is "fine by me", though not excellent

  140. Zash

    New XEP?

  141. daniel

    so the only way to make it it agnostic is a brand new XEP?

  142. jonas’

    Zash, seems like overkill if I ever saw one

  143. daniel

    which is overkill. so 60 it is?

  144. pep.

    I did think about making it a new XEP just to define the type, and then edit 0060 to use it :/

  145. jonas’

    I’m on-list nevertheless, I want to understand if that schema stuff is right first

  146. pep.

    Not sure what's best

  147. jonas’

    I got the gut feeling that it isn’t

  148. Zash

    jonas’: oh glob

  149. daniel

    anyway have my official +1

  150. pep.

    jonas’, got it from https://www.w3.org/TR/xmlschema-2/#union-datatypes

  151. daniel

    and then have someelse block it if they feel like it

  152. jonas’

    I would’ve expected dwd to have a strong opinion here (subtle ping)

  153. dwd

    pep., Your thought is that it needs an edit to '60 either way? I think that's probably right, so we might as well have the registration there too.

  154. dwd

    On the schema, it looks right to me.

  155. pep.

    yeah 0060 needs editing in any case I'd say. Because I need to give meaning to the type

  156. pep.

    For each field using it

  157. Zash

    If you want it Generic, shouldn't it have a 'min' enum too?

  158. dwd

    pep., Yes, seems right.

  159. dwd

    Zash, Is min not equivalent to zero in any case?

  160. Zash

    dwd: only if it's unsigned

  161. pep.

    Zash, not against adding it, but yeah I'd say it's likely to be 0

  162. pep.

    right..

  163. Zash

    Is it?

  164. dwd

    Oh.

  165. pep.

    'integer' is

  166. pep.

    signed.

  167. pep.

    Sorry

  168. dwd

    Is there an unsigned integer type?

  169. daniel

    I can’t think of a use case for 'min' and I rather not add something unless we have an explicit use

  170. pep.

    and infinite..

  171. pep.

    dwd, we can make one

  172. pep.

    But I'd think there is one already

  173. dwd

    Ugh.

  174. Zash

    And the semantics here is that 'max' is always whatever the acutal max is, even if you reconfigure it in the thing defining it?

  175. pep.

    daniel, if I split the thing into its own XEP I guess it might make sense

  176. daniel

    Zash yes

  177. dwd

    This feels like the sort of grinding down in detail that would be best done on the list. But anyway, I'm +1, but if you find improvements that's also good.

  178. daniel

    which is actually what I like about that

  179. jonas’

    Zash, want to cast a vote?

  180. Zash

    +1

  181. dwd

    I'm also fine with this not needing a "min". If we want to expand later we can by having an integer-or-min-or-max or something.

  182. jonas’

    let’s move on then

  183. jonas’

    4c) Proposed XMPP Extension: Compliance Suites 2021 URL: https://xmpp.org/extensions/inbox/cs-2021.html Abstract: ... you know it ...

  184. jonas’

    +1

  185. daniel

    +1

  186. dwd

    (I apologise for not having the strong opinions jonas’ hoped for).

  187. dwd

    +1

  188. Zash

    +1

  189. jonas’

    swift

  190. jonas’

    5) Pending Votes

  191. jonas’

    a few on #983 from last week

  192. jonas’

    me including, but then again, two people vetoed already

  193. jonas’

    any need for discussion about that one?

  194. jonas’

    oh, it’s the URI one

  195. adityaborikar has joined

  196. jonas’

    the author agreed in the meantime that URI encoding should be used and we’re done

  197. jonas’

    6) Date of Next

  198. dwd

    You effectively pre-veto'd it.

  199. jonas’

    +1w wfm

  200. daniel

    let me check

  201. dwd

    +1 to +1w wfm.

  202. jonas’

    dwd, and by that you can see how awake I am today :D

  203. Zash

    +1w wfm

  204. pprrks has left

  205. daniel

    +1w wfm

  206. jonas’

    neat

  207. jonas’

    7) AOB

  208. pprrks has joined

  209. neox has left

  210. jonas’

    let’s insert the PR#986

  211. jonas’

    -> https://github.com/xsf/xeps/pull/986

  212. jonas’

    my stance doesn’t change (I need to read into this before I can provide guidance), but maybe someone else can

  213. Zash

    Opinion: This is good.

  214. daniel

    as I already said in the comments. _seems_ good to me. but i'm not an expert on microblogging. maybe someone else out there is using this on a different node for reasons?

  215. daniel

    it should really be left to the authors imho

  216. jonas’

    note that pubsub#type is *not* the node ID

  217. jonas’

    most of the authors I haven’t seen much around here lately

  218. pep.

    Yeah that's on purpose. The node ID is generally set to a UUID I think in Movim and/or Sàt

  219. dwd

    I think it's maybe a SHOULD and not a MUST. But I'd be curious as to what the authors say, as well as the Movim guys who (I think) use this heavily.

  220. pep.

    When not on PEP

  221. Zash

    edhelas seemed to approve: https://logs.xmpp.org/xsf/2020-09-30?p=h#2020-09-30-030be57f8039269d

  222. Zash

    and pep. said goffi did too

  223. dwd

    Oh, that's good then.

  224. daniel

    right. yes. just shows how not of an expert on microblogging I am

  225. daniel

    but if the two only implementors agree…

  226. Zash

    The #type field isn't super-well-defined tho

  227. dwd

    But experimental, so if those who want this want it this way, that's fine by me.

  228. jonas’

    what is the benefit of using the pubsub#type?

  229. pep.

    Zash, true

  230. jonas’

    is that something you can filter on when finding pubsub nodes?

  231. dwd

    jonas’, Discovery I guess.

  232. pep.

    The only thing that's normative about pubsub#type is "payload type"

  233. pep.

    The rest is somewhere in an example

  234. Zash

    AIUI it's meant to be an URI / namespace representing the payload type

  235. pep.

    jonas’, I don't think so, it's just that there might be multiple nodes using microblog on the same pubsub component

  236. pep.

    So you can't set them all to the same value

  237. jonas’

    … to the same node ID

  238. jonas’

    makes sense

  239. jonas’

    but how does it help any entity then?

  240. Zash

    Theoretical filtering abilitity?

  241. jonas’

    right

  242. jonas’

    and maybe for showing stuff in a pubsub node directory or something

  243. Zash

    jonas’: microblog support for search.jabber.network !

  244. jonas’

    of course :)

  245. daniel

    in that case a SHOULD should be fine?

  246. dwd

    If we ever did disco#search, it'd be useful.

  247. Wojtek has joined

  248. jonas’

    yeah, so, I have little idea about microblogging. we’ll have to ping the authors anyway, but if the implementors agree, that’s already a good thing

  249. Zash

    Yeah, RFC 2119 expert comment on the MUST plz

  250. jonas’

    daniel, any concrete reason why a MUST would not be desirable?

  251. pep.

    daniel, I feel that if it's a SHOULD in microblog, it makes this change moot. I said to Zash earlier "the XEP becomes unusable without the MUST the second another spec uses pubsub + atom"

  252. dwd

    Well, is it an absolute requirement for interoperability?

  253. pep.

    (because no, microblog is not just pubsub+atom)

  254. jonas’

    how about we delegate that MUST/SHOULD debate to the authors?

  255. pep.

    hah

  256. daniel

    jonas’, i got the impression that it is a discovery/search thing? so if i don’t need it to be found

  257. dwd

    I mean, my gut feeling is SHOULD, but I'm not the expert here, and if those who are think if this is missing there's concrete interop harm then MUST it is.

  258. daniel

    but i'm really what ever on that

  259. Zash

    jonas’: sounds reasonable

  260. dwd

    daniel, I'm thinking if it's on the well-known node ID then it probably doesn't add value.

  261. daniel

    dwd, yes

  262. jonas’

    then I’d like to move on to 7b

  263. dwd

    But I susp[ect this is bikeshed.

  264. jonas’

    dwd, daniel, note that the text says that it’s not needed if on the well-known node ID

  265. jonas’

    only if it isn’t

  266. jonas’

    either way

  267. jonas’

    pinging authors, moving on

  268. dwd

    I'm right then in my previous assertion. :-)

  269. daniel

    there might be other well knowns

  270. jonas’

    7b) Message Styling It was not advanced and the author disagrees with Council. What to do next?

  271. pep.

    daniel, not defined in microblog

  272. jonas’

    formally, we should Reject it, right?

  273. daniel

    which one is message styling again? :-)

  274. jonas’

    the one from Sam

  275. dwd

    Was Sam an outlier on this on the list, and did the community feel that the Council proposal was reasonable?

  276. jonas’

    the one by Sam

  277. jonas’

    unclear

  278. pep.

    daniel, 393

  279. Zash

    https://xmpp.org/extensions/xep-0393.html

  280. jonas’

    there was lots of discussion I was not in the mood for reading *again* yesterday

  281. dwd

    Yeah, fair.

  282. jonas’

    I think we should do sometihng about the status of '393

  283. jonas’

    it is dangling in LC for a while now, and I’d like it if next council wouldn’t have to formally re-call it

  284. daniel

    sorry I wasn’t prepared to have that discussion

  285. dwd

    So, in general terms, our documents are meant to match our consensus as a group (not just Council, but everyone).

  286. jonas’

    at the same time, I don’t feel like I can take it to go through that right now, so it’d be good if someone else was available to take that task

  287. daniel

    can someone share a link to the thread?

  288. daniel

    or the name/date

  289. jonas’

    daniel, one second

  290. jonas’

    it’s a minutes thread

  291. jonas’

    [Standards] Council Minutes 2020-05-27

  292. jonas’

    link in another second

  293. daniel

    thanks that's probably enough

  294. jonas’

    https://mail.jabber.org/pipermail/standards/2020-May/037495.html

  295. jonas’

    nice, pipermail doesn’t let you click next on that one

  296. jonas’

    https://mail.jabber.org/pipermail/standards/2020-June/037496.html this may do

  297. dwd

    So if Sam, as author, is in the rough here, then he gets to say "I told you so", and not much else. But if there's no clear(ish) consensus, rough or otherwise, from the group on the way forward then that's not much help.

  298. Zash

    Because it goes into June

  299. daniel

    right. if I recall that thread correctly there wasn’t a clear community consensus

  300. daniel

    some (rightfully) hate the xep a lot for not being xhtml-im

  301. daniel

    but it also doesn’t try to be

  302. jonas’

    quick question: can we extend by +10min to bring this to a more useful ending?

  303. daniel

    i personally probably would not vote to reject it

  304. daniel

    yes

  305. Zash

    shure

  306. Kev

    (Interjecting) ISTR there were some quite sensible suggestions made to make this a better imperfect solution to an impossible problem, which should probably have serious thought. Around opt-ins and the like.

  307. Kev returns to his corner

  308. jonas’ hands Kev some cookies

  309. daniel

    right. those changes (if we want them to) could be made by simply taking the XEP over instead of rejecting it

  310. pep.

    I also wasn't ready for this :P

  311. jonas’

    pep., nobody ever is for a re-iteration of message {styling,theming,formatting}

  312. pep.

    Iirc even the opt-in/out mechanisms wouldn't really help

  313. daniel

    not making an argument for or against those signaling/opt-in/opt-out changes

  314. jonas’

    daniel, yes

  315. Kev

    pep.: IIRC, the mechanisms couldn't make this a perfect solution to the impossible problem.

  316. Kev

    But did solve some of the issues.

  317. Kev

    But I don't have this swapped in at the moment, sadly.

  318. jonas’

    nobody has

  319. eta

    one thing not addressed is "how do I have both a styled version and a fallback without adding ugly * everywhere"

  320. eta

    for example, spectrum2-discord currently makes user @mentions bold with xhtml-im

  321. jonas’

    eta, this is not about completely re-doing Styling

  322. eta

    right

  323. jonas’

    we have about one month left to properly bring this to a close.

  324. eta

    I mean as an informational document '393 is pretty good

  325. Kev

    Oh, that's an interesting thought.

  326. jonas’

    the best way forward I can come up with is if everyone of us (council) wades through that thread and tries to extract the community consensus and then we act on the mean of that

  327. jonas’

    the Informational track has been proposed before for '393

  328. pep.

    eta, I want to disagree :p

  329. Kev

    Sorry, I'm forgetting things in my old age.

  330. jonas’

    I do not recall who strongly opposed that though; might’ve been sam, might’ve been me.

  331. jonas’

    (which really says something)

  332. pep.

    I'd rather have that somewhere hidden / locked-away never to be seen again

  333. Kev

    I think I've aged about a decade in the last 6 months (I suspect I'm not alone)

  334. daniel

    I think someone said we can’t change tracks

  335. eta

    I mean it is a hack

  336. jonas’ hands more 🍪 to Kev

  337. eta

    but it's a relatively okay one

  338. daniel

    but i'd be fine with keeping it informational and roughly as is

  339. eta

    like vcard-temp

  340. jonas’

    daniel, we can do everything, if we ask board for a '1 override (and they grant it)

  341. Zash

    eta: oh no u didn't!!1

  342. dwd

    I honestly don't know that there's community consensus, even rough, to do anything at all. Including doing nothing.

  343. daniel

    i mean we can try to go through the thread again. but something something vocal miniority and haters gonna hate and stuff

  344. daniel

    so at some point we probably just have to decide something

  345. Kev

    Oh, it looks like <unstyled/> has already made it in. Which, again, I'd forgotten. That improves things significantly, I think.

  346. daniel

    or let the next council deal with it :-)

  347. jonas’

    OK, so, I’ll set up a bunch of votes for next week: 1. Should we find a way to move '393 to Informational and keep it there? 2. If the previous vote should fail, should we take ownership from Sam and rewrite '393 with a mandatory and explicit opt-in? 3. If the previous vote should fail, should we accept '393 as-is? 4. If the previous vote should fail, should we reject '393 as is or accept it as Draft?

  348. daniel

    > Oh, it looks like <unstyled/> has already made it in. Which, again, I'd forgotten. That improves things significantly, I think. +1

  349. dwd

    I don';t think there was consensus for explicit opt-in, actually.

  350. jonas’

    can we agree on that list? and also on everyone swapping this in so that we can bring it to a close?

  351. Zash

    Gonna need to stock up on 🍪

  352. daniel

    yes

  353. pep.

    dwd, there wasn't indeed :/

  354. dwd

    Also popcorn.

  355. jonas’

    I’m not sure if the positive response is to popcorn or my list

  356. daniel

    my 'yes' was regarding your list

  357. dwd

    I *think* there might be (very) rough consensus to have it with an explicit opt-out, and publishing it. Though whether as Informational or Standards Track, I don't know.

  358. jonas’

    I put the votes on next week’s agenda

  359. Kev

    (Don't want to derail the meeting, so ignore this for the moment, but I think there is a strong argument for having a this-is-marked-up, which is not necessarily used for opt-in, because it allows you to strip the formatting, knowing that's what it is, ending up with something more $OTHER_MESSENGER (and more useful, I believe) - maybe not a hill to die on, but I think there isn't a reason it would be bad to tell people it's marked up)

  360. jonas’

    and now I’d like to step away from this, and I also think that we can’t find a solution right now and here

  361. jonas’

    any other AOB?

  362. pep.

    Kev, yes, and an argument for opt-in

  363. dwd

    Kev, https://mail.jabber.org/pipermail/standards/2020-June/037506.html I found reasonably compelling.

  364. Kev

    dwd: I *think* he's looking at using an opt-in, there, which has pros and cons, as opposed to simply an announcement that something is marked up?

  365. jonas’

    I’m taking this as a no

  366. jonas’

    8) Ite Meeting Est

  367. jonas’

    thanks everyone

  368. daniel

    Thank you jonas’

  369. pep.

    There were questions in #988, but I guess I'll poke people on xsf@ later on

  370. Kev

    Ah, no, he does address the third state towards the end.

  371. pep.

    Re datatype prefix

  372. Kev

    dwd: But he's not addressing it from a point of view of it being a known state. Maybe if I called it <strippable/> it would make the point for clearly. So you have three possible states of <strippable/>, <unstyled/> and nowt.

  373. Kev

    dwd: But he's not addressing it from a point of view of it being a known state. Maybe if I called it <strippable/> it would make the point more clearly. So you have three possible states of <strippable/>, <unstyled/> and nowt.

  374. pep.

    I guess I'm less annoyed about the XEP but more about its adoption. Devs thinking this is actually a good solution

  375. dwd

    Kev, A point you indeed raised in the thread.

  376. Kev

    Oh, did I? How refreshing for me to be consistent :)

  377. jonas’

    move that to xsf@ maybe?

  378. daniel

    pep.: isn't the adoption one client

  379. pep.

    yours?

  380. daniel

    And one client that copy pasted the code

  381. dwd

    Kev, I'm basically finding myself on the same rollercoaster I suspect I was on when I first read the thread.

  382. dwd

    Kev, And also, June feels like years ago.

  383. Kev

    What the ... that was THIS YEAR?

  384. daniel

    Which is actually slightly frustrating because Dino and Gajim render it slightly different

  385. daniel

    But not different enough

  386. jonas’

    Time flies like an arrow (fruit flies like a banana, though).

  387. daniel

    (unless either of them 'fixed' this recently)

  388. dwd

    daniel, IIRC, Psi implemented (basically) this about a decade ago.

  389. daniel

    With emphasis on _basically_

  390. pep.

    You mean yet another variant?

  391. eta

    XHTML-IM wasn't that bad

  392. eta ducks

  393. Kev

    I think Psi was the first XMPP client to do this.

  394. Zash

    Gajim also had something like this since time immemorial

  395. dwd

    pep., Part of Sam's intent here was to unify the variants, in fairness.

  396. Kev

    eta: That's the upsetting thing, XHTML-IM *wasn't* that bad.

  397. daniel

    The idea is the same. But the exact implementations vary

  398. daniel

    Which can be annoying in certain cornor cases

  399. dwd

    eta, The problem with XHTML-IM was that virtually every implementation had security flaws.

  400. Kev

    https://mail.jabber.org/pipermail/standards/2020-June/037514.html I think the point I made there still stands, basically, although I had no idea it was only two months ago I raised it.

  401. Kev

    https://mail.jabber.org/pipermail/standards/2020-June/037514.html I think the point I made there still stands, basically, although I had no idea it was only three months ago I raised it.

  402. pep.

    dwd, I think my bitterness about 393 is mostly due to the fact that this came up right after XHTML-IM was "killed", and proposed as some kind of replacement that it isn't

  403. daniel

    I don't recall the time line being in that order

  404. Zash

    And the irony in literally everything else (outside XMPP) uses something like XHTML-IM, but embedded in JSON

  405. pep.

    yeah

  406. eta

    yeah exactly

  407. Kev

    Zash: Ah, although with one major difference, I think.

  408. eta

    dwd: this is only because people just shoved the XHTML into a webview or something stupid

  409. Kev

    Zash: Not duplicating the body (maybe that's only a concern for us, but it's a major concern when you have two different representations that could have completely different content, shown to different users)

  410. eta

    like if you tree walk the XHTML you don't have this problem

  411. Zash

    Kev: Matrix duplicates the body.

  412. Kev

    eta: I think it's more than that. You can be trying quite hard to not be stupid, and still fall foul of things.

  413. Zash

    And also tripples it if you make a correction iirc.

  414. daniel

    I think the fault here is that xhtml-im was too broad and invited doing exactly that (putting it in a web view)

  415. pep.

    daniel, too broad? there's a nice whitelist there

  416. daniel

    Or more limited scope (same feature set as 393) could have prevented that

  417. eta

    Kev: yeah, okay, stupid is an unnecessarily caustic word :)

  418. dwd

    eta, Yes, but while we know what people are meant to do, and even designed XHTML-IM to support same, nobody did it that way at first.

  419. daniel

    pep.: it has css

  420. Zash

    daniel: tbf, the css also has a whitelist

  421. pep.

    CSS1 yeah

  422. daniel

    But I'm not gonna write an css parser

  423. eta

    but something that is actually XML based instead would be bettee

  424. eta

    r*

  425. jonas’

    I strongly suggest to move this to xsf@

  426. eta

    like even if it's <bold>whatever</>

  427. daniel

    When the alternative of putting it an a web view is so easy

  428. pep.

    jonas’, I'd just try to kill the chat :p

  429. jonas’

    pep., I could, but it’d take down xsf@ with it :>

  430. pep.

    *disband*

  431. pep.

    (both!)

  432. debacle has left

  433. sonny has left

  434. sonny has joined

  435. sonny has left

  436. sonny has joined

  437. sonny has left

  438. sonny has joined

  439. neox has joined

  440. Lance has joined

  441. sonny has left

  442. sonny has joined

  443. sonny has left

  444. sonny has joined

  445. kusoneko has left

  446. kusoneko has joined

  447. sonny has left

  448. kusoneko has left

  449. kusoneko has joined

  450. kusoneko has left

  451. kusoneko has joined

  452. sonny has joined

  453. sonny has left

  454. debacle has joined

  455. sonny has joined

  456. sonny has left

  457. sonny has joined

  458. sonny has left

  459. sonny has joined

  460. sonny has left

  461. sonny has joined

  462. sonny has left

  463. Tobias has left

  464. Wojtek has left

  465. Wojtek has joined

  466. sonny has joined

  467. sonny has left

  468. sonny has joined

  469. sonny has left

  470. sonny has joined

  471. stpeter has left

  472. debacle has left

  473. stpeter has joined

  474. sonny has left

  475. Wojtek has left

  476. sonny has joined

  477. sonny has left

  478. sonny has joined

  479. sonny has left

  480. neox has left

  481. SouL has left

  482. sonny has joined

  483. sonny has left

  484. sonny has joined

  485. stpeter has left