jdev - 2023-01-26


  1. Beherit has left

  2. rubi has left

  3. rubi has joined

  4. adx has left

  5. sponji has left

  6. selurvedu has joined

  7. PapaTutuWawa has left

  8. TheCoffeMaker has left

  9. TheCoffeMaker has joined

  10. Patiga has left

  11. krit has left

  12. Patiga has joined

  13. krit has joined

  14. dezant has left

  15. dezant has joined

  16. Ingolf has left

  17. Ingolf has joined

  18. snow has joined

  19. TheCoffeMaker has left

  20. TheCoffeMaker has joined

  21. antranigv has joined

  22. antranigv has left

  23. antranigv has joined

  24. antranigv has left

  25. antranigv has joined

  26. dezant has left

  27. dezant has joined

  28. atomicwatch has left

  29. atomicwatch has joined

  30. moparisthebest has left

  31. moparisthebest has joined

  32. dezant has left

  33. dezant has joined

  34. antranigv has left

  35. atomicwatch has left

  36. jgart has joined

  37. atomicwatch has joined

  38. SouL has left

  39. snow has left

  40. snow has joined

  41. Yagizа has joined

  42. atomicwatch has left

  43. atomicwatch has joined

  44. rubi has left

  45. rubi has joined

  46. atomicwatch has left

  47. Alex has left

  48. atomicwatch has joined

  49. selurvedu has left

  50. dezant has left

  51. dezant has joined

  52. SouL has joined

  53. Maranda[x] has joined

  54. atomicwatch has left

  55. moparisthebest has left

  56. atomicwatch has joined

  57. atomicwatch has left

  58. hearty has joined

  59. spiral has left

  60. Menel has joined

  61. dezant has left

  62. dezant has joined

  63. atomicwatch has joined

  64. moparisthebest has joined

  65. Trung has joined

  66. dezant has left

  67. dezant has joined

  68. dezant has left

  69. dezant has joined

  70. SouL has left

  71. SouL has joined

  72. Menel has left

  73. spiral has joined

  74. dezant has left

  75. dezant has joined

  76. dezant has left

  77. dezant has joined

  78. Menel has joined

  79. dezant has left

  80. dezant has joined

  81. spiral has left

  82. spiral has joined

  83. snow has left

  84. mirux has joined

  85. Beherit has joined

  86. Schimon_ has joined

  87. Menel has left

  88. Menel has joined

  89. atomicwatch has left

  90. TheCoffeMaker has left

  91. TheCoffeMaker has joined

  92. Millesimus has left

  93. Millesimus has joined

  94. spiral has left

  95. spiral has joined

  96. wurstsalat has joined

  97. atomicwatch has joined

  98. TheCoffeMaker has left

  99. nicoco has joined

  100. TheCoffeMaker has joined

  101. atomicwatch has left

  102. atomicwatch has joined

  103. hearty has left

  104. hearty has joined

  105. TheCoffeMaker has left

  106. MSavoritias (fae,ve) has joined

  107. TheCoffeMaker has joined

  108. TheCoffeMaker has left

  109. SouL has left

  110. SouL has joined

  111. TheCoffeMaker has joined

  112. atomicwatch has left

  113. atomicwatch has joined

  114. Schimon_ has left

  115. Schimon_ has joined

  116. goffi has joined

  117. Laura has left

  118. rubi has left

  119. rubi has joined

  120. TheCoffeMaker has left

  121. atomicwatch has left

  122. Mario Sabatino has joined

  123. TheCoffeMaker has joined

  124. atomicwatch has joined

  125. goffi has left

  126. goffi has joined

  127. Laura has joined

  128. pulkomandy has left

  129. TheCoffeMaker has left

  130. TheCoffeMaker has joined

  131. nicoco has left

  132. nicoco has joined

  133. TheCoffeMaker has left

  134. TheCoffeMaker has joined

  135. rubi has left

  136. rubi has joined

  137. Kev has joined

  138. Beherit has left

  139. TheCoffeMaker has left

  140. TheCoffeMaker has joined

  141. rubi has left

  142. rubi has joined

  143. spiral has left

  144. spiral has joined

  145. TheCoffeMaker has left

  146. TheCoffeMaker has joined

  147. spiral has left

  148. Beherit has joined

  149. spiral has joined

  150. larma has joined

  151. TheCoffeMaker has left

  152. TheCoffeMaker has joined

  153. adx has joined

  154. TheCoffeMaker has left

  155. TheCoffeMaker has joined

  156. Alex has joined

  157. spiral has left

  158. spiral has joined

  159. Ingolf has left

  160. Ingolf has joined

  161. Alex has left

  162. Alex has joined

  163. larma has left

  164. larma has joined

  165. Dele Olajide has joined

  166. TheCoffeMaker has left

  167. Vaulor has left

  168. larma has left

  169. Vaulor has joined

  170. larma has joined

  171. TheCoffeMaker has joined

  172. gregory has left

  173. gregory has joined

  174. xecks has left

  175. xecks has joined

  176. TheCoffeMaker has left

  177. TheCoffeMaker has joined

  178. Arne has joined

  179. SouL has left

  180. Arne

    Hi, I'm thinking about applying for a membership in the XMPP Standards Foundation. Would anyone create an wiki account for me with the Nickname "Arne"? Thank you!

  181. SouL has joined

  182. Ge0rG

    Arne: I can do that, please also send me your email address via DM

  183. TheCoffeMaker has left

  184. TheCoffeMaker has joined

  185. dezant has left

  186. dezant has joined

  187. Arne

    Ge0rG it's arne-bruen@monocles.de thanks

  188. Ge0rG

    Arne: > The user account for Arne (talk) has been created.

  189. Ge0rG

    please check your inbox (and spam)

  190. Arne

    Received. Thanks!

  191. antranigv has joined

  192. atomicwatch has left

  193. atomicwatch has joined

  194. atomicwatch has left

  195. atomicwatch has joined

  196. pulkomandy has joined

  197. spiral has left

  198. spiral has joined

  199. TheCoffeMaker has left

  200. TheCoffeMaker has joined

  201. Laura has left

  202. larma has left

  203. larma has joined

  204. larma has left

  205. larma has joined

  206. larma has left

  207. larma has joined

  208. pulkomandy has left

  209. spiral has left

  210. larma has left

  211. spiral has joined

  212. larma has joined

  213. larma has left

  214. larma has joined

  215. PapaTutuWawa has joined

  216. TheCoffeMaker has left

  217. dezant has left

  218. dezant has joined

  219. techmetx11 has left

  220. techmetx11 has joined

  221. atomicwatch has left

  222. atomicwatch has joined

  223. TheCoffeMaker has joined

  224. TheCoffeMaker has left

  225. TheCoffeMaker has joined

  226. Laura has joined

  227. TheCoffeMaker has left

  228. TheCoffeMaker has joined

  229. Menel has left

  230. Menel has joined

  231. TheCoffeMaker has left

  232. nicoco

    if I'm an entity not implementing last message correction, is it OK to reply to an LMC-containing message with <message type=error>? The statu quo seems to be "just display the message body as a new message", but I am wondering if there something inherently wrong with replying with <message t=error>

  233. MattJ

    What's the benefit?

  234. TheCoffeMaker has joined

  235. MattJ

    The reason it's designed the way it is, is so that if someone doesn't support the XEP they still get to see the corrected message

  236. nicoco

    yes, I figured. it's how slidge does it for legacy services that don't support LMC, but it's been confusing to some users. I'll just make the gateway component send a message informing the user that LMC does not work on XXX and that a new message has been sent instead. (well unless the legacy service supports retraction in this case I can retract/send a new one)

  237. nicoco

    I agree that there is no point, I was just trying to think what the "least confusing UX" could be.

  238. Zash

    Hmmmmmmmmmmm, <error type=continue>?

  239. Zash

    I'm not aware of anything anywhere using type=continue, ever, in the entire history of XMPP.

  240. nicoco

    I have found at least one client that does not display any hint that the correction stanza has been replied with an error, I think that's not good because I guess the stanza can have been rejected for another reason, so it would make sense to show in the UI that the correction did *not* work. I'll open a ticket :)

  241. Zash

    Yes, improve error handling!

  242. MattJ

    I agree, errors are possible

  243. Zash

    Would <error type=continue> be appropriate for cases where you strip some extension and carry on?

  244. flow assumes that many clients are not properly reporting xmpp-level errors to the user (for example, because it's hard to do so, without confusing the user)

  245. Kev

    What to do with errors as a client is *hard*.

  246. Kev

    What flow says :)

  247. flow

    yeay \o/

  248. TheCoffeMaker has left

  249. nicoco

    yes. this "LMC error" case is indeed tricky. in general I find GUIs extremely hard to code, and user feedback about GUIs "surprising", so I'm not blaming anyone =)

  250. MattJ

    Yep, I'm not saying it's not hard, just that it should be handled :)

  251. nicoco

    since we're talking error handling, xep 0086 is "deprecated" but I still use https://xmpp.org/extensions/xep-0086.html#table-1 to decide error conditions and types. am I going to go the XMPP jail for this?

  252. Zash

    🚨️🚨️🚨️ GET THEM!

  253. MattJ

    nicoco, yes, you should use RFC 6120 to determine those

  254. MattJ

    If it matches, you're fine

  255. MattJ

    or if you use common sense, you'll probably also be fine :)

  256. TheCoffeMaker has joined

  257. Zash

    Bookmark https://xmpp.org/rfcs/rfc6120.html#stanzas-error

  258. MattJ

    If you use the 'code' attribute, go directly to XMPP jail, do not pass Go, do not collect compliance badges

  259. Zash hides the util.error `code` support

  260. flow hands out "get out of xmpp jail" cards

  261. pep.

    Does /me usage get you a "get in the geek circle" card? :P

  262. nicoco

    oh thanks for the link, this is a bit better than this obscure table. Some subtleties like difference registration-required and subscription-required are a bit confusing to me, but I need to read in details

  263. flow

    no, just in the "old timer geek circle" (obviously)

  264. nicoco

    btw, since we're mentioning error handling, slixmpp tends to create stanzas like this: ```xml <message xmlns=jabber:component:accept> <error xmlns=jabber:client>... ``` that's a slixmpp bug, right? no reason to switch to another namespace in the error, it should just be <error> here, right?

  265. pep.

    I'd say that's a bug yeah, maybe someone can confirm

  266. MattJ

    Yes, a bug. The jabber:component:accept namespace has its own <error> (with exactly the same format as jabber:client)

  267. wurstsalat

    > do not collect compliance badges :D

  268. Zash

    Unify the namespaces!

  269. nicoco

    pep. this happens when I just `raise XMPPError('condition', 'text')` in a handler which is very convenient, but apparently does not handle the component case well. I tried to fix but got lost in low level stream stuff that I don't master at all. just saying that in case you want to have a look :P

  270. pep.

    I also probably don't have the knowledge to dig in there.. poke mathieui :x

  271. Alex has left

  272. antranigv has left

  273. nicoco

    Hehe OK, I will start by opening an issue I guess.

  274. TheCoffeMaker has left

  275. Link Mauve

    larma, moparisthebest, fyi biboumi’s limits aren’t in chars per messages, but in bytes per IRC command, which would make advertising that to the XMPP client very awkward. For instance, the recipient’s name is also part of the limit.

  276. Alex has joined

  277. TheCoffeMaker has joined

  278. Link Mauve

    larma, another interesting use case I haven’t seen mentioned in this discussion is game MUCs, where it is an expected feature that not all users receive the same messages (or truth as you called it), and that your messages (e.g. “go left”) will get rewritten or even silently discarded (e.g. “your character went to the left room” from the narrator).

  279. Link Mauve

    You can’t encode this kind of rules in a generic protocol.

  280. larma

    Not sure what exactly a game MUC is supposed to be, but if it's not a groupchat, that usecase is totally out of scope of the MUC protocol

  281. Link Mauve

    larma, https://en.wikipedia.org/wiki/MUD

  282. Link Mauve

    It is a groupchat, just for a different usecase than what we’re using here.

  283. spiral has left

  284. larma

    Is it a groupchat or is it "you send messages to some server. multiple people are interacting with the same server to play a game"

  285. spiral has joined

  286. Link Mauve

    Why does it matter?

  287. larma

    I know text-based, dial-in multi user games, but I wouldn't consider this as a MUC

  288. larma

    And that matters because you're complaining about MUC not being compatible with something that MUC is not supposed to be used for

  289. MattJ

    Always trying to spoil our fun

  290. larma

    If you'd realize this by just having a "bot" user, that people write and get messages with information about the other players, it would work as good without having any compatibility issues

  291. larma

    If you'd implement this by just having a "bot" user, that people write and get messages with information about the other players, it would work as good without having any compatibility issues

  292. PapaTutuWawa has left

  293. MattJ

    xmoo allowed you to navigate between "rooms" and the presence list would update according to who was in the same room

  294. larma

    which you can also entirely do without MUC

  295. larma

    presences work with normal users as well 😉

  296. Zash

    and without XMPP

  297. pep.

    larma, so if I wanted some groupchat-looking thing for my game I'd need to reimplement almost all MUC and not call it MUC?

  298. MattJ

    Clients wouldn't render that, or I don't know what you mean

  299. pep.

    I mean I'm fine, we can have extensions on top of MUC that say "This is MUC+foo" and it behaves this way

  300. larma

    In Dino and Gajim I can see the list of currently online devices

  301. larma

    Not sure about others

  302. larma

    pep., IMO the main idea behind MUC is "Send a message to the service, the service forwards that message (as is) to all participants in the room". If you're not doing that anymore, it's not MUC

  303. TheCoffeMaker has left

  304. selurvedu has joined

  305. Kev

    MUCs modifying the messages that are sent to them is a very long-standing thing in XMPP.

  306. larma

    Kev, this is not about what is a long-standing thing but what is a good idea 😉

  307. Kev

    Be it pastebins, security labelling, whatever.

  308. larma

    There may be valid cases where special behavior of a MUC beyond forwarding are desired

  309. larma

    but that's not what we primarily design the specification around

  310. Kev

    It's not, but it works fine with it.

  311. larma

    Except when it doesn't

  312. larma

    I mean, security labels and pastebin are probably not very invasive, so they're unlikely to cause big harm

  313. larma

    But forwarding a message only to a subset of occupants or modifying it differently by recipient is going to cause trouble with all kinds of extensions we have in MUC nowadays that are designed around the assumption that this wouldn't happen

  314. norayr has left

  315. larma

    > Messages sent within multi-user chat rooms are of a special type "groupchat" and are addressed to the room itself (room@service), then reflected to all occupants. This is from the requirements of XEP-0045

  316. MattJ

    Sure

  317. MattJ

    FWIW in all this recent discussion about this kind of thing, I don't disagree much with what you've said

  318. MattJ

    I'm the original author of mod_pastebin and a couple of other modules that do "interesting things"

  319. MattJ

    I don't regret writing them, and many of them are innovative, fun and sometimes even useful

  320. MattJ

    But if a client follows the spec, and doesn't work with them, I don't consider that a bug with the client

  321. larma

    (beside my opinion about these things being not nice and also definitely not in the spirit of the spec, we should probaly improve support for these things in Dino for compatibility reasons)

  322. MattJ

    If the module (unintentionally) doesn't follow the spec, it may well be a bug with the module

  323. norayr has joined

  324. MattJ

    Sometimes we break certain rules on purpose - I'm pretty sure xmoo violated many sentences in XEP-0045. But it worked in practically all clients, and it was fun to build.

  325. selurvedu has left

  326. TheCoffeMaker has joined

  327. pep.

    What's xmoo?

  328. MattJ

    The pastebin thing... it worked because most clients do just have one hook that handles messages from the MUC, and they use this to update their display/history. I doubt it was even a conscious decision by many of them to treat the MUC as the source of truth, just a convenient implementation approach that avoids the need for tracking/deduplicating reflections. A number of clients didn't/don't work that way, and although it's inconvenient for a user of that module, that's not a bug in those clients.

  329. antranigv has joined

  330. atomicwatch has left

  331. lovetox has left

  332. atomicwatch has joined

  333. mirux has left

  334. mirux has joined

  335. Dele Olajide has left

  336. MattJ

    pep., something like Link Mauve described just now, see also https://en.wikipedia.org/wiki/MOO

  337. pep.

    Ok

  338. MattJ

    It relied on various non-standard behaviours that happened to work in clients. For example, messages from non-occupants, and messages from the room bare JID

  339. MattJ

    E.g. you might type "stroke cat" and it would reply <message type="groupchat" from="room@server/cat"><body>/me purrs</body></message>

  340. lovetox has joined

  341. Kev

    Pretty sure 45 allows messages from non-occupants, at least.

  342. Zash

    That's what the on-join history looks like, so yeah

  343. Kev

    """ an implementation MAY allow users with certain privileges (e.g., a room owner, room admin, or service-level admin) to send messages to the room even if those users are not occupants """

  344. PapaTutuWawa has joined

  345. nicoco

    back to my boring namespaces issues, is there a list of cases where a component need to sends stanzas where some (direct or indirect) children elements have xmlns=jabber:client? everything's that "forwarded" has to preserve the original namespace and that's it, right?

  346. Kev

    If you're working out when you should rewrite namespaces to :component, I think the sensible rule is that once there is a namespace that isn't the root namespace of the stanza between you and the stanza root in the hierarchy, your namespace should be left alone.

  347. Zash

    Allowing out-of-room entities to send messages to MUC rooms can be ... tricky, implementation wise.

  348. me9 has joined

  349. nicoco

    Kev: thanks. so I send from a client with <jabber:client> and then the MUC "echoes" my message but with <jabber:accept:component>, that's OK? same for MUC MAM or history-on-join, they have no reason to have jabber:client anywhere. I didn't have any trouble with this btw, but I'd like to avoid things that "accidentally work" and do things the right way =)

  350. Kev

    I don't follow the question, sorry.

  351. flow

    nicoco, xmpp has the (IMHO) design flaw, that stanza namespaces are hop related and change during the transmission of a stanza. clients should always only see the jabber:client namespace for (top-level) stanzas

  352. thomaslewis has joined

  353. flow

    for example, if the muc is a component, then the reflected message will start with jabber:accept:component, when routed to the components server. if the server then routes the message to another server, it will have the jabber:server namespace, and if the final server routes it to the client, then the message will be under the jabber:client namespace

  354. Kev

    You should only receive stanzas in 'your' namespace. It's only a server that has to transform when switching between clients, servers and components.

  355. Dele Olajide has joined

  356. Vaulor has left

  357. Vaulor has joined

  358. flow

    right, the namespace transformation is only performed by xmpp servers (at least, I can't think of a counter example)

  359. selurvedu has joined

  360. thomaslewis has left

  361. flow

    right, the namespace transformation is only performed by xmpp servers (at least I can't think of a counter example)

  362. goffi has left

  363. goffi has joined

  364. pep.

    Yeah, here in slix it's just because it allows emitting multiple namespaces and does it badly

  365. pep.

    (client/component)

  366. oxtyped has joined

  367. stefan has left

  368. stefan has joined

  369. Wojtek has joined

  370. larma has left

  371. thomaslewis has joined

  372. thomaslewis has left

  373. TheCoffeMaker has left

  374. qy

    https://repology.org/project/libomemo-c/versions it's spreading

  375. atomicwatch has left

  376. TheCoffeMaker has joined

  377. thomaslewis has joined

  378. thomaslewis has left

  379. selurvedu has left

  380. selurvedu has joined

  381. nicoco

    thanks kev and flow. I think there are some bogus jabber:client namespaced (non-top) elements in what slidge sends then. apparently it's not been a problem for clients to handle but I'll change that. I think the only case where I need to make sure I use xmlns=jabber:client is for "messages sent on behalf of normal xmpp accounts", as per https://xmpp.org/extensions/xep-0356.html#sending_mess

  382. yarmo has left

  383. Kev

    Inside the <forwarded/> should not be in :component, correct.

  384. Kev

    But every top level stanza you send, as a component, should be.

  385. yarmo has joined

  386. hearty has left

  387. atomicwatch has joined

  388. nicoco

    yes, for the top-level no problem, always :component. what about MAM replies? what shold message/result/forwared/message use? right now slidge does that: ```xml <message xmlns='jabber:component:accept'> <result xmlns='urn:xmpp:mam:2'> <forwarded xmlns='urn:xmpp:forward:0'> <message xmlns='jabber:client'> <body> ``` clients seem to be happy with that, but is that the *right* way?

  389. Kev

    Yes.

  390. Zash

    Probably easiest to always go with `jabber:client` in the inner forwarded. When would you ever forward a `jabber:server` or component message and who would care?

  391. TheCoffeMaker has left

  392. Link Mauve has left

  393. Kev

    For non-specialist use, I don't think you would.

  394. pep.

    Zash, for when MUC has modified the message and thus is now no jabber:client anymore but :component :P

  395. hearty has joined

  396. nicoco

    but for on-join history it has to be: ``` <message type="groupchat" xmlns="jabber:component:accept"> <body> ``` no client at all here

  397. Kev

    Because every stanza you send to the server from your component is in :component. The server then rewrites to :server or :client as appropriate.

  398. nicoco

    I understand that the client will neven see this :component xmlns because the server will change it, but this is what slidge should send above, isn't it?

  399. nicoco

    again, all of this seems to be working, but I'd like to avoid things working just because clients are tolerant, since they may stop at any point =)

  400. Kev

    You'd typically put the xmlns on the stream element for jabber:component:accept, and then not include a namespace on the stanzas, but the end result is the same, yes.

  401. nicoco

    alright. thanks for your patience. in conclusion, my slixmpp hacks for what's inside forwarded were justified. good!

  402. TheCoffeMaker has joined

  403. goffi has left

  404. goffi has joined

  405. pep.

    Kev, that's for the serializer to sort out, the applicative layer may require namespaces

  406. paul has left

  407. pep.

    In minidom (rust) we require that everything be namespaced for example, even though obviously we'll deduplicate where we can

  408. Zash

    Prosody also internally has no xmlns (or `nil`) on stanzas and rely on inheriting the namespace of the stream when sending them.

  409. Kev

    > In minidom (rust) we require that everything be namespaced for example, even though obviously we'll deduplicate where we can I know, I had to work around that issue just the other day.

  410. pep.

    issue?

  411. pep.

    I think it's a feature :P

  412. Kev

    Disallowing documents without a root namespace.

  413. pep.

    Yeah

  414. Zash

    Explicit > Implicit, but muh convenience!

  415. pep.

    I have specifically added a new endpoint for this that you may like

  416. pep.

    https://gitlab.com/xmpp-rs/xmpp-rs/-/blob/main/minidom/src/element.rs#L349

  417. Kev

    I'm not sure that helps me - it's not that my root was prefixed, it's that my root has no namespace.

  418. pep.

    Ah well

  419. pep.

    That's not a use-case for XMPP then

  420. deimos has left

  421. deimos has joined

  422. Kev

    Not actually true, but it doesn't matter, I'm doing hacky string manipulation before feeding into the parser to workaround the issue.

  423. TheCoffeMaker has left

  424. pep.

    Well if it were XMPP you'd have at least the None case with jabber:client or the like

  425. oxtyped has left

  426. TheCoffeMaker has joined

  427. Kev has left

  428. Kev has joined

  429. norayr has left

  430. Dele Olajide has left

  431. TheCoffeMaker has left

  432. larma has joined

  433. TheCoffeMaker has joined

  434. selurvedu has left

  435. atomicwatch has left

  436. pulkomandy has joined

  437. Schimon_ has left

  438. Schimon_ has joined

  439. norayr has joined

  440. paul has joined

  441. bootlicker has left

  442. atomicwatch has joined

  443. atomicwatch has left

  444. antranigv has left

  445. Patiga has left

  446. antranigv has joined

  447. atomicwatch has joined

  448. atomicwatch has left

  449. Dele Olajide has joined

  450. nik has joined

  451. nik has left

  452. nik has joined

  453. snow has joined

  454. antranigv has left

  455. kapad has joined

  456. atomicwatch has joined

  457. atomicwatch has left

  458. Laura has left

  459. marc has left

  460. marc has joined

  461. Link Mauve has joined

  462. Wojtek has left

  463. atomicwatch has joined

  464. nik has left

  465. norayr has left

  466. antranigv has joined

  467. xnamed has left

  468. nik has joined

  469. dezant has left

  470. xnamed has joined

  471. nik has left

  472. larma has left

  473. Laura has joined

  474. PapaTutuWawa has left

  475. xnamed has left

  476. dezant has joined

  477. Trung has left

  478. xnamed has joined

  479. atomicwatch has left

  480. MattJ/web has joined

  481. atomicwatch has joined

  482. atomicwatch has left

  483. xnamed has left

  484. MattJ/web has left

  485. larma has joined

  486. atomicwatch has joined

  487. atomicwatch has left

  488. atomicwatch has joined

  489. atomicwatch has left

  490. Dele Olajide has left

  491. snow has left

  492. atomicwatch has joined

  493. atomicwatch has left

  494. atomicwatch has joined

  495. Wojtek has joined

  496. snow has joined

  497. PapaTutuWawa has joined

  498. bootlicker has joined

  499. xnamed has joined

  500. techmetx11 has left

  501. xnamed has left

  502. kapad has left

  503. Dele Olajide has joined

  504. Dele Olajide has left

  505. Yagizа has left

  506. antranigv has left

  507. Patiga has joined

  508. SouL has left

  509. antranigv has joined

  510. antranigv has left

  511. hearty has left

  512. Wojtek has left

  513. SouL has joined

  514. Schimon_ has left

  515. antranigv has joined

  516. antranigv has left

  517. hearty has joined

  518. Trung has joined

  519. Vaulor has left

  520. Trung has left

  521. antranigv has joined

  522. antranigv has left

  523. norayr has joined

  524. norayr has left

  525. norayr has joined

  526. me9 has left

  527. Arne has left

  528. Vaulor has joined

  529. xnamed has joined

  530. TheCoffeMaker has left

  531. TheCoffeMaker has joined

  532. techmetx11 has joined

  533. mirux has left

  534. mirux has joined

  535. snow has left

  536. MSavoritias (fae,ve) has left

  537. xnamed has left

  538. TheCoffeMaker has left

  539. TheCoffeMaker has joined

  540. xnamed has joined

  541. marc has left

  542. marc has joined

  543. Millesimus has left

  544. TheCoffeMaker has left

  545. Millesimus has joined

  546. TheCoffeMaker has joined

  547. Millesimus has left

  548. mirux has left

  549. qwemnb has joined

  550. qwemnb has left

  551. TheCoffeMaker has left

  552. Arne has left

  553. TheCoffeMaker has joined

  554. xnamed has left

  555. Millesimus has joined

  556. nicoco has left

  557. xnamed has joined

  558. TheCoffeMaker has left

  559. spiral has left

  560. spiral has joined

  561. TheCoffeMaker has joined

  562. snow has joined

  563. Millesimus has left

  564. spiral has left

  565. spiral has joined

  566. atomicwatch has left

  567. TheCoffeMaker has left

  568. TheCoffeMaker has joined

  569. Kev has left

  570. Millesimus has joined

  571. xnamed has left

  572. Mario Sabatino has left

  573. spiral has left

  574. atomicwatch has joined

  575. atomicwatch has left

  576. spiral has joined

  577. PapaTutuWawa has left

  578. snow has left

  579. snow has joined

  580. atomicwatch has joined

  581. xnamed has joined

  582. lovetox has left

  583. xnamed has left

  584. larma has left

  585. Millesimus has left

  586. Menel has left

  587. Menel has joined

  588. snow has left

  589. xnamed has joined

  590. lovetox has joined

  591. atomicwatch has left

  592. Millesimus has joined