XMPP Council - 2022-01-19


  1. neox has joined
  2. Kev has left
  3. Kev has joined
  4. pprrks has left
  5. pprrks has joined
  6. SouL has left
  7. _Liveware Problem_ has left
  8. pprrks has left
  9. pprrks has joined
  10. ChronosX88 has left
  11. ChronosX88 has joined
  12. debacle has left
  13. sonny has left
  14. sonny has joined
  15. pprrks has left
  16. Kev has left
  17. pprrks has joined
  18. Kev has joined
  19. pprrks has left
  20. pprrks has joined
  21. moparisthebest has left
  22. moparisthebest has joined
  23. pprrks has left
  24. pprrks has joined
  25. neox has left
  26. moparisthebest has left
  27. moparisthebest has joined
  28. pprrks has left
  29. pprrks has joined
  30. pprrks has left
  31. pprrks has joined
  32. pprrks has left
  33. pprrks has joined
  34. Kev has left
  35. Kev has joined
  36. pprrks has left
  37. pprrks has joined
  38. pprrks has left
  39. marc0s has left
  40. marc0s has joined
  41. msavoritias has joined
  42. msavoritias has left
  43. msavoritias has joined
  44. marc0s has left
  45. marc0s has joined
  46. me9 has joined
  47. Kev has left
  48. SouL has joined
  49. Kev has joined
  50. me9 has left
  51. SouL has left
  52. SouL has joined
  53. Kev has left
  54. Kev has joined
  55. _Liveware Problem_ has joined
  56. Kev has left
  57. Kev has joined
  58. sonny has left
  59. sonny has joined
  60. Tobias has joined
  61. Kev has left
  62. Kev has joined
  63. debacle has joined
  64. Kev has left
  65. Kev has joined
  66. neox has joined
  67. Ge0rG Today I'd like to AOB a bit about the three not-yet-rejected XEPs from two weeks ago. Sorry that I didn't manage to bring it up earlier, but there is a strategic issue I'm having that I'd like to discuss.
  68. SouL has left
  69. SouL has joined
  70. msavoritias has left
  71. msavoritias has joined
  72. daniel ack
  73. daniel Ge0rG: did you vote on those yet? I didn't record a vote from you
  74. daniel Which might be my fault
  75. Ge0rG daniel: no, I'd like to discuss before casting my votes
  76. larma Ge0rG, we can also do now if it needs me 🙂
  77. Wojtek has joined
  78. Ge0rG larma: given what dwd wrote on the list, I'd like to veto fallbacks and have you merge it into 428.
  79. Tobias has left
  80. Tobias has joined
  81. dwd It'd be very nice to have a clearer understanding of the consensus of the community on the fallback text manipulation bits. I'm quite prepared to be in the rough on that, but currently only me and larma appear to have any opinion at all...
  82. Ge0rG While XEP numbers are cheap, confusing developers with similarly named protocols that cover subtly different use cases is very expensive to us as a community.
  83. Zash As a ... server developer I just want to ... know whether to ignore <body> or not
  84. daniel > daniel: no, I'd like to discuss before casting my votes I think _technically_ the voting period ended yesterday. It's always two weeks, no? I think in this particular instance we can see past that but I think that as chair it's now somewhat my job to enforce the rules even though I'm not fully clear on them myself
  85. Ge0rG dwd: this, together with message references, sounds like a discussion for a day of summit
  86. Ge0rG daniel: IIRC it was 14 days after the day of the initial vote or some such.
  87. Zash Ge0rG, +1 (wrt confusing names being ungood)
  88. larma I totally get the point and I don't mind having it in 428, but I don't think it's subtle difference, given that this difference is what causes a lot of discussion
  89. daniel > daniel: IIRC it was 14 days after the day of the initial vote or some such. Right. But we are on day 15,no?
  90. Ge0rG larma: it's not the difference that causes the discussion but the general approach you suggested
  91. dwd daniel, Voting has usually been considered as two weeks inclusive; so the vote starts at Council Meeting 0, and ends at Council Meeting 2.
  92. Ge0rG larma: so having that discussion is worthwhile regardless of the XEP number it ends in
  93. larma Ge0rG, I mean the discussion about "alternative bodies", which is what this XEP is basically about
  94. dwd larma, Actually, my main problem (as XEP author) is that there hasn't been discussion. Too much would be a problem I'd like to have.
  95. larma Ge0rG, I mean the discussion about "alternative bodies", which is what this ProtoXEP is basically about
  96. Ge0rG Well, from a tactical point of view, I need to veto the XEP to ensure this discussion happens. 😉
  97. daniel > daniel, Voting has usually been considered as two weeks inclusive; so the vote starts at Council Meeting 0, and ends at Council Meeting 2. dwd: OK fair enough. I actually think that makes sense. I just remember one occasion where I wasn't allowed to cast my vote in the second meeting anymore. Not that it matters anymore. But that made me unsure about the rules
  98. larma dwd, It's not like I don't understand your position and I think you understand my position. This is basically about opinions, I don't think any points can be added to the discussion (so, if it wasn't for me being directly involved, I wouldn't reply on this mailing list thread as well, so I can't blame anyone else for not doing it)
  99. dwd "usually". And of course, you're chair so you get to reinterpret the rules. :-)
  100. dwd larma, OK, but that suggests that nobody at all cares about this except you and I...
  101. Zash Could it not rather be that nobody cares about this _right now_?
  102. Ge0rG I think we are already deep in the hole of inconsistent content displays with XHTML-IM and LMC, so we are not making the mess any worse.
  103. dwd Zash, Yes, indeed. But nobody cared when 428 was published either.
  104. larma Do you expect people to answer on the mailing list "I'm on daves side", without any further points made?
  105. Ge0rG Can we make it a popularity contest?
  106. Zash Inb4 someone brings up switching to a discussion platform with a 👍️ button
  107. Ge0rG Zash: We all know that you have simple buttons.
  108. larma Zash, sounds like we just need more clients to implement XEP-444 🙂
  109. dwd larma, Well, I don't view it as sides, but the idea is to design protocols such that we as a community have rough consensus we're doing it right. Very hard to judge that if nobody says anything.
  110. larma dwd, 100% agree
  111. Zash Is assumption of silence equaling agreement less than optimal?
  112. dwd Zash, When there's two conflicting suggestions on the table, then which is the silence assenting to?
  113. larma FWIW, I honestly think that if the fallback+reply-to xep was accepted as is, it will be implemented by some clients. Whereas a reply-to without sensible fallback probably won't. And reply-to is a commonly requested feature
  114. Kev > Do you expect people to answer on the mailing list "I'm on daves side", without any further points made? I tend not to do this, as long as the points I would make have been made.
  115. Ge0rG Kev: how is council going to evaluate which points are more convincing?
  116. dwd larma, I think clients are already doing a reply without any metadata at all, just the markup/down.
  117. larma Kev, yeah that works great if one can rationally conclude from the points made which is the best option, which seems to not be the case here, thus the problem.
  118. larma dwd, exactly, but also nobody really likes that, it's just the best we have because we (the people doing the specifications) don't move forward on this and related discussions 😕
  119. Kev > Kev: how is council going to evaluate which points are more convincing? I don't think decisions should be made based on who is most vocal on the lists.
  120. Kev But where Council would like to judge such a thing, I think asking where people fall is not stupid.
  121. Ge0rG For the record: I think the UX improvements created by replies and body fallback erasure are worth the additional attack surface.
  122. Ge0rG However, I still slightly tend to reject on formal grounds.
  123. Kev > Kev, yeah that works great if one can rationally conclude ... Quite. And I'm afraid I've been off work for the best part of a month until this week, so haven't been monitoring XSF stuff (and pretty much archived it all when I got back). Not that I'm suggesting it's my opinion you're seeking, but if there are threads that want more discussion, maybe they could be bumped with context for why more discussion is desired?
  124. Ge0rG Fallbacks because I really see it as part of 0428, and replies because we still haven't figured out message fastening
  125. dwd larma, Could you simplify the body editing to cover the reply case explicitly, rather than making it quite so generic?
  126. Ge0rG dwd: what's the problem with it being generic? You reverse sort the fallback elements by offset, then remove all the supported ones in one pass
  127. Ge0rG I'm sure we can also make use of fallbacks for SIMS / OOB files
  128. dwd Ge0rG, I think most fallback cases are all-or-nothing. I don't think we want to worry about markdown fallback. Replies I see the benefit, but with a generic pre-display editing capability I just think that's a lot of attack surface for the desired outcome.
  129. larma dwd, I could, but it's really complicated. There is no standard markup for the reply fallback and you need flexibility for internationalization purposes.
  130. Ge0rG Maybe it's even not generic enough, in case some XEP provides different elements under the same namespace that warrant a fallback.
  131. dwd larma, Strip leading characters only?
  132. Ge0rG dwd: the only alternative I see is to embed the fallback body into the fallback element, but that would refute most of the fallback purpose
  133. dwd Ge0rG, Yes, I circled around that thought too.
  134. larma Ge0rG, the string in `for` doesn't strictly need to be the namespace of the element, it can also be `$namespace:$elementname` for example
  135. dwd larma, If you want that, you need two attributes.
  136. larma Ge0rG, the string in `for` doesn't strictly need to be the namespace of the element, it can also be `$namespace:$elementname` for example, in cases where namespace alone is not enough
  137. Ge0rG dwd: could you come up with a convincing attack scenario, where actual message content gets manipulated in an unexpected way in one but not the other implementation?
  138. dwd larma, You can't concatenate a namespace and a local name into a single string.
  139. dwd Ge0rG, Yeah, I came up with a couple on the list.
  140. Ge0rG dwd: back in the 0428 days?
  141. dwd Ge0rG, No, in the last thread.
  142. Ge0rG Alright, will reread.
  143. larma dwd, citing from the ProtoXEP: "The <fallback> element has a 'for' attribute with an identifier of the specification the fallback is for. [...] The exact behavior for a compatibility fallback should be defined in the respective specification." aka. it doesn't say it must be the namespace, it can be literally anything right now.
  144. dwd Ge0rG, Reply fallbacks, for instance, allow you to not only strip the reply, but edit the message you're sending.
  145. dwd larma, Right, yes, you can have arbitrary identifiers there. But you can't just have $namespace:$element.
  146. Ge0rG dwd: edit the embedded fallback quote?
  147. dwd Ge0rG, Yes, but also the message you're sending in reply.
  148. Ge0rG dwd: LMC does so as well
  149. larma dwd, what I meant is, the specification for $element in $namespace can just declare that $namespace:$element is what should be in `for` attribute. It doesn't work in the generic case, but it does when specified like this.
  150. Ge0rG Yeah, so `for` must be the namespace or start with the namespace
  151. dwd Ge0rG, LMC replaces messages, so the entire message before and after edits is always obvious. This means that if you have content-based spam filtering, that would be unaffected.
  152. Ge0rG dwd: and XHTML-IM allows to send two conflicting messages
  153. dwd Ge0rG, Yes indeed, and I (and others) warned about that a few summits back.
  154. Ge0rG dwd: the only solution I can see for cases with audit trail requirements is to store the full original xml
  155. dwd But we also need to try every combination of fallback editing in order to figure out what the outcome might be.
  156. Ge0rG dwd: who is "we" in that scenario?
  157. larma dwd, would it make you happy if in the reply-to xep we state that the fallback as specified via the fallback xep should only be removed if it is a single continuous character sequence starting before the first character of the body and ending after a newline character?
  158. larma That would make abuse harder but still give enough flexibility
  159. larma That would make abuse harder but still give enough flexibility for practical use
  160. dwd larma, So removal of a prefix only?
  161. dwd larma, That would be fine by me. There is still an attack surface but much much smaller.
  162. larma exactly, but still use the fallback xep so that non-supporting clients still now it's a fallback (without removing it)
  163. larma exactly, but still use the fallback xep so that non-supporting clients still now it's a fallback (without removing it, they can still dim it or whatever in this case)
  164. Ge0rG But that limits fallback to one element per message, right?
  165. dwd Ge0rG, For now. Operational experience may suggest we need to expand it.
  166. larma Ge0rG, no, that's a rule specific for reply-to (and will be in reply-to XEP), other XEPs may have different rules.
  167. Ge0rG What if I want to reply-to to multiple messages?
  168. dwd larma, Why not just start with only supporting prefix removal? It is the only compelling case we have right now. I'd be concerned that rule would simply be ignored.
  169. larma Thinking of, for example, message markup (the one that is not styling aka markdown) could declare that only single characters that would trigger a message styling start or end can be removed, etc
  170. dwd larma, That's unenforceable by definition.
  171. Ge0rG dwd: what about replying-to a message with an inline file indicated by OOB?
  172. Ge0rG OOB would remove postfixes of the message, reply-to prefixes
  173. larma Ge0rG, that's out of scope for this XEP (the solution: send two messages)
  174. larma Ge0rG, that (reply to two messages) is out of scope for this XEP (the solution: send two messages)
  175. Ge0rG larma: well, reypl-to-two was the first synthetic corner case example I was able to come up with
  176. larma (this is what I see in most other messengers, I don't know any that supports replying to two messages in one)
  177. larma dwd, I disagree that it's unenforcable by definition. Message styling has clear rules when characters can trigger styling. Message markup can refer to those rules.
  178. dwd larma, Sure, but to support that on the receiving end you'd need to understand the rules you don't implement.
  179. larma dwd, you are assuming that I don't implement this rules
  180. dwd larma, Yes, because if you do you know what characters are markup.
  181. Ge0rG my point is: if we define the fallback semantics as "strip the first N body characters for the <namespace> element", and we end up with multiple fallback elements inside the stanza, we still have selective removal of body parts if a receiving client implements the fallback #2 but not fallback #1 namespace
  182. Ge0rG dwd: you only strip the fallback if you know the rules.
  183. larma dwd, markup and styling don't have exactly the same feature set, so it makes sense to support both at the same time and still declare styling as a fallback.
  184. dwd Ge0rG, Yes, but if you know what characters are and are not markup, in order to know whether the rules are legal, then you *also* know which characters to strip anyway, right?
  185. larma dwd, styling does not strip characters
  186. larma > It is RECOMMENDED that styling directives be displayed and formatted in the same manner as the text they apply to. For example, the string "*emphasis*" would be rendered as "*emphasis*".
  187. larma (the bold got loss because I couldn't use message markup to make it bold :D)
  188. larma (the bold got lost because I couldn't use message markup to make it bold :D)
  189. larma (the bold in the second example string got lost because I couldn't use message markup to make it bold :D)
  190. larma in case it's unclear why this is needed: You might trigger those styling directive accidentally when typing formulars etc, so stripping them will render those messages unreadable
  191. Ge0rG Trying to solve a security issue by adding complexity is a huge red flag.
  192. dwd larma, OK, so we're talking a client that supports XEP-0393, and therefore knows which characters form a "styling directive", but you're using a fallback directive for an identifier it understands to remove those, to cover the case where a user naively types characters such that they do form a span but that span is unintentional, from a client that also does understand XEP-0393?
  193. Ge0rG So I'm still torn somewhere between "only allow a prefix of the message to be stripped", "allow each fallback element to iteratively strip a prefix of the (remaining) message, as long as you support all preceding fallbacks" and "let each fallback strip whatever it wants"
  194. dwd larma, I'm going to go with "niche".
  195. larma dwd, maybe my example was a bit to unclear. Let's say I want to write "This is important" and make the important bold. With message markup (0394) I can just make the important bold and that's it. With Message styling (0393) I need to add styling directives (asterisks) into my body, but that's still better to not make it bold. So I will send "This is *important*" to have a fallback for legacy clients and trigger message styling. But then I also add 0394 markup for the word important and add a fallback element that says that the two asterisks are fallback, so I client supporting 0394 will not display the asterisks but still make it bold - which is what I wanted in first place.
  196. larma dwd, maybe my example was a bit to unclear. Let's say I want to write "This is important" and make the "important" bold. With message markup (0394) I can just make the important bold and that's it. With Message styling (0393) I need to add styling directives (asterisks) into my body, but that's still better to not make it bold. So I will send "This is *important*" to have a fallback for legacy clients and trigger message styling. But then I also add 0394 markup for the word important and add a fallback element that says that the two asterisks are fallback, so I client supporting 0394 will not display the asterisks but still make it bold - which is what I wanted in first place.
  197. larma dwd, maybe my example was a bit to unclear. Let's say I want to write "This is important" and make the "important" bold. With message markup (0394) I can just make the important bold and that's it. With Message styling (0393) I need to add styling directives (asterisks) into my body, but that's still better to not make it bold. So I will send "This is *important*" to have a fallback for legacy clients and trigger message styling. But then I also add 0394 markup for the word important and add a fallback element that says that the two asterisks are fallback, so a client supporting 0394 will not display the asterisks but still make it bold - which is what I wanted in first place.
  198. dwd OK, so the receiving client supports 394 only, and cannot tell if the fallback editing for the lack of 393 is legitimate or not?
  199. daniel fwiw i have 393 in it's current form (w/o fallback or ignore tags or anything) deployed to ~6 million users and from all the complaints i get daily from users not one has ever complained about the formatting
  200. larma If a receiving client does not support 393 and don't want to implement its rules to check if the fallback can be removed, they can either decide to remove it no matter what (risking abuse), make simplified rules (e.g. only single characters can be removed, still risking abuse but making it less likely) or just not remove (which is still better than nothing). Most clients though will support 393 and/or implement its rules in the near future, so I don't think it's a big deal.
  201. larma daniel, FWIW, you are a mobile client and I hardly know any mobile client that supports proper rich text (and not just markdownish), because how would you Ctrl-B to make text bold without a keyboard 😀
  202. larma Also, nothing is wrong with moving the markdownish logic into the sending client and send using 0394-like markup only on wire.
  203. Zash Less than nothing wrong, it'd be pretty good.
  204. larma Zash, yeah, that's kinda my longterm goal, but it's a long way to get there.
  205. larma and without some fallback mechanism, transition is gonna be hard...
  206. Zash Server-side xhtml-im? 😀
  207. larma server-side e2e message decryption?
  208. Zash mod_omemo you say?
  209. Zash for meeeeeee, the self-hosted on a single user server, that'd be pretty great
  210. larma I guess we're kinda getting off-topic here. Point is, fallback for 0394-like message markup is part of design considerations in my fallback proto xep (it even is in the second example) and a restriction to prefix-only would make that usecase impossible.
  211. larma If we reach consensus that what I proposed in the proto xep should be part of 0428 instead, I certainly can prepare a PR to rewrite 90% of 0428 - it still feels weird to me to bluntly modify the original meaning of that XEP but I can deal with it (and afaik nobody implemented 0428 as it is right now, so apparently it wasn't very useful anyway)
  212. Zash Feature creep indeed
  213. ChronosX88 has left
  214. ChronosX88 has joined
  215. Tobias has left
  216. sonny has left
  217. sonny has joined
  218. sonny has left
  219. sonny has joined
  220. Ge0rG dwd: is larma's proposal okay with you?
  221. dwd Amusingly, I'm working on server-side e2ee decryption right now. And for improving security, too.
  222. dwd Ge0rG, I'd really appreciate a message to the list outlining it, so we can see what other people feel about it. I worry it's still more complex than I'd like, but it's movement in the right direction at least.
  223. dwd Ge0rG, But to be clear, my view is much less important than consensus.
  224. Ge0rG Unfortunately, I've been asleep for the last two weeks, so I have a pressing deadline to veto or not-veto the proto-XEP today.
  225. dwd Ge0rG, I *thought* we'd agreed that we should fold both proposals into '428?
  226. larma Ge0rG, you can always veto and if necessary we put it up for vote again
  227. Ge0rG But given the previous communications on list from you two, it looks like we can arrive at a 0428 containing a significant subset of the proto-XEP
  228. Ge0rG larma: right, but it's also a bad practice to just re-cast a vote without significantly changed circumstances.
  229. larma though I agree that it feels like we're going to merge everything into 0428
  230. larma Ge0rG, yeah, but "merging in 0428 did not work out" would be changed circumstances, no?
  231. Ge0rG So I'm going to veto Compatibility Fallbacks.
  232. Ge0rG larma: good point
  233. Tobias has joined
  234. Ge0rG larma: I'm also _most probably_ going to veto call-invites, because it has _very significant_ overlap with 0353 and is missing a clear rationale what's different. If it is only about embedding a URI of an external conference system / phone number, then maybe we can find a way to stuff that URI into 0353 or into Jingle?
  235. Ge0rG And I've been thinking whether to also veto Replies because of a lack of rationale (how it differentiates from threads et al) and the message referencing mess that we are in, but the former was already suggested for later in the process and the latter is not the protoXEP authors' fault
  236. Ge0rG So I'm probably going to +0 Replies.
  237. larma call invites is mostly about: - not being about establishing a jingle connection but a call, which may include multiple participants (jingle connections are always between two entities) - extensibility and fallbacks for various connection methods What it's primarily intended for right now, is to initiate a Muji group call as described in https://github.com/xsf/xeps/pull/1139
  238. larma reply-to is referencing the fallbacks proto xep so I don't think it makes a lot of sense to accept it before the fallbacks update
  239. flow there has been some work on multi party jingle, like xep272, fwiw
  240. Ge0rG larma: I'm pretty sure that 0353 is also mostly about calls (at least 1:1) and not so much about file transfers, and it would be beneficial to see if you can do Muji over 0353 as well
  241. Ge0rG larma: the wire format of reply-to can be completely rewritten in experimental, I'm only concerned about assigning XEP numbers to duplicate functionality.
  242. daniel i think 353 makes a lot of sense for file transfer as well. if it weren't for my crappy jingle-ft implementation (that's completely independent of the newly written jingle rtp implementation) i'd happly use 353 for ft as well
  243. daniel That's not to say it couldn't also be used for muji
  244. larma I agree with daniel that it is kinda weird to remove a feature from a XEP that was there just because it isn't used in practice (yet)
  245. larma I agree with daniel that would be kinda weird to remove a feature from a XEP that was there just because it isn't used in practice (yet)
  246. Ge0rG I wasn't going to suggest removing FT from 0353
  247. dwd At this point, we're probably best off discussing somewhere else, but can't the Muji extensions fit within the <propose/> of the intent message in '353?
  248. larma Trying to merge 353 with FT and generic any-transport call invites seems a little bit weird to me
  249. Ge0rG larma: I haven't looked into the muji wire protocol, but what would be wrong about embedding it into 0353?
  250. larma dwd, right now those elements in there are jingle description. If you put an element there that is not a known jingle description to the recipient, they should not be able to accept the call.
  251. larma dwd, right now those elements in <propose/> are jingle description elements. If you put an element there that is not a known jingle description to the recipient, they should not be able to accept the call.
  252. daniel i don’t know enough about muji to make a call on whether or not it can be fit into 353. but i'm too (taking my council hat off here for a second) sceptical of the new proposed xep that ignores the existance of 353
  253. Ge0rG daniel: I'm with you here. I'm going to veto call-invites until it comes back with a water-tight rationale for why 0353 absolutely can't be used
  254. Ge0rG but my preferred outcome is actually merging muji calls into 0353
  255. larma FWIW, I tried to merge in 353 first, it just didn't work out
  256. Ge0rG because it really looks like it's reinventing all of the 353 wire protocol, with different names.
  257. Ge0rG I'd also be okay with a 353' protoXEP that re-uses 0353 wire protocol and defines a new child element for it
  258. dwd Ge0rG, I'd suggest working with Thilo, who seems very active in this space.
  259. larma (council hat off) as this is probably not going to work out before our next Dino release, we'll have to release out-of-spec behavior to get group calls live
  260. larma dwd, guess who I've talked to about this topic a lot already...
  261. daniel larma: can you put it into some weird Dino namespace that's not a even a valid uri?
  262. Zash no no noooooooo
  263. daniel And then have it become a widely deployed thing
  264. larma daniel, sure, would probably be what we're going to do, but I really don't like it
  265. dwd daniel, Please no.
  266. Zash yeets a bath tub in the general direction of daniel
  267. larma Another thing that I wanted to point out, is that call invites can even use 353 as a means to discover full jid (because that is not part of call invites as it doesn't work properly in MUCs due to this nick sharing thing)
  268. larma Another thing that I wanted to point out, is that call invites can even use 353 as a means to discover full jid (because that is not part of call invites as it doesn't work properly in MUCs due to this multi session nick thing)
  269. Ge0rG has left
  270. larma Also 353 with the latest changes moved even more towards 1:1 only because of the tie breaking which doesn't work outside 1:1 and wouldn't even work for call invites (because those can be invites to two different calls)
  271. larma Maybe another solution would be to restrict the proto xep explicitly to be not used for direct 1:1 calls?
  272. larma so there is no feature overlap anymore
  273. Ge0rG has joined
  274. Ge0rG daniel: let me tell you a tale of app-specific namespaces. ``` count pep node 20969 pep_eu.siacs.conversations.axolotl.devicelist 879 pep_eu.siacs.xmpp_messenger.axolotl.devicelist 201 pep_com.KDJStudios.XMPPJabberClient.axolotl.devicelist 148 pep_eu.siacs.storizima.axolotl.devicelist 118 pep_com.yaari.storizim.axolotl.devicelist 107 pep_mob.titecs.cackle.axolotl.devicelist 15 pep_com.kwikchat.app.axolotl.devicelist 7 pep_de.nxmedia.app.android.c0nnect.axolotl.devicelist 5 pep_com.securedsoftware.vaultim.axolotl.devicelist 4 pep_com.a3india.conversations.axolotl.devicelist 3 pep_lu.pgd.conversations.axolotl.devicelist 3 pep_com.onionsearchengine.onionmessenger.axolotl.devicelist 3 pep_chat.conab.gov.br.axolotl.devicelist 2 pep_xyz.glidermessenger.glider.axolotl.devicelist 2 pep_de.tengu.chat.axolotl.devicelist ```
  275. daniel the most painfull thing about this is that people who fork Conversations clearly don’t know how to change the application id
  276. larma luckily, we don't have a ton of forks just to add ads and be free in the play store 😀
  277. jonas’ what the holy backlog
  278. daniel Ge0rG, also this was very obviously (maybe not that obviously?) a joke on how not to repeat the mistakes omemo made
  279. daniel or I made to be more specific
  280. larma I really would prefer if we find a solution before the Dino release date, because that Dino version is going to be in Ubuntu LTS 22.04 and thus be around for at least 4 years, so we have to maintain backwards compatibility with it 😕
  281. moparisthebest has left
  282. Zash mumbles something annoyed about the 10 year extended support period
  283. Ge0rG larma: when is the dino release date?
  284. Zash something something oldoldstable
  285. vanitasvitae_ Ge0rG: hehehe
  286. Zash larma, and remember to release without any security issues whatsoever, since they're not fixing those
  287. larma Ge0rG, Ubuntu imports from Debian testing before February 24, we are aiming early February to make sure it gets into Debian testing on time.
  288. larma FWIW, if we don't do a release, Ubuntu will package some random version from our git that is currently in testing 😕
  289. larma Zash, not entirely true: https://launchpad.net/ubuntu/+source/dino-im/0.0.git20180130-1ubuntu0.1
  290. Zash who did you have to bribe for that?
  291. larma It's important that you get CVEs, that's the only language understood by Ubuntu security team
  292. Ge0rG larma: I'm very sorry that I've been sitting on this for the last two weeks. In case you run into time constraints because I'm blocking on something, feel free to ping and pressure me into deciding sooner :)
  293. Zash My understanding is that their policy for software in 'universe' is "lol, do it yourself"
  294. Tobias has left
  295. jonas’ oh no the markup wars are back
  296. Ge0rG larma: but I still think that having one XEP for 1:1 call initiation and a completely separate XEP for 1:N call initiation that's using completely different wire format is extremely unfortunate
  297. jonas’ so I am roughly on daves side w.r.t. the removal of stuff
  298. larma jonas’ is still reading backlog 😀
  299. jonas’ no, just back from that
  300. jonas’ I won't have the time today to read through all of the discussion on list (again)
  301. jonas’ I would like to point out that reusing wire format for calls is extremely valuable considering the push infrastructure required for stuff like iOS
  302. larma Ge0rG, I do somewhat agree, and I would say it's possible to merge those *if* we agree on getting rid of FT support in 353 and make a bunch of things in 353 optional, but giving that Thilo put so much effort into fleshing out 353 to work great for 1:1, I'm not sure how to proceed here
  303. larma Ge0rG, I do somewhat agree, and I would say it's possible to merge those *if* we agree on getting rid of FT support in 353 and make a bunch of things in 353 optional, but given that Thilo put so much effort into fleshing out 353 to work great for 1:1, I'm not sure how to proceed here
  304. jonas’ so as mostly a bystander in the A/V debate I am quite unhappy that there was apparently no talk with fippo or the 353 maintainers
  305. jonas’ larma: tried talking to thilo in the past two weeks?
  306. jonas’ they said on list they would've liked to talk AIUI
  307. Ge0rG larma: why would you want to remove FT from 353?
  308. larma jonas’, yes, talking with Thilo about 353 rework since November
  309. jonas’ they seemed surprised on list about the protoxep though
  310. jonas’ or am I mixing something up?
  311. jonas’ on mobile, cannot search
  312. larma I haven't mentioned to him that we're doing this as an alternative before we uploaded it AFAIK
  313. larma Ge0rG, I don't want to, but it really doesn't work to have a call invites (generic and independent of transport method) and Jingle File Transfers in the same XEP
  314. Zash Mmmmmulti-destination Jingle File Transfer?
  315. larma either we make the XEP about a transport method (Jingle) or about a content type (Calls)
  316. jonas’ larma: that sounds right
  317. jonas’ or something I could get behind on
  318. jonas’ might be worth turning 353 around to focus on calls
  319. jonas’ afk now
  320. Wojtek has left
  321. Tobias has joined
  322. Wojtek has joined
  323. larma Yes either 353 is changed to Calls only, with Jingle just one means of transport, or is kept as is (generic method for Jingle) and then we need a new generic thing for calls. I personally would prefer the XEP for calls and for Files (we already have SIMS/SFT for that) independent, but unfortunately 353 currently is for transport method, so this would shift its current feature set
  324. moparisthebest has joined
  325. larma So, *if* we agree on changing 353 to be calls only (not FT) and independent of Jingle, I guess I will find a way to figure things out with Thilo to get this done on time for Dino
  326. larma So, *if* we agree on changing 353 to be calls only (not FT or XML streams or any other Jingle content it currently supports) and independent of Jingle, I guess I will find a way to figure things out with Thilo to get this done on time for Dino
  327. _Liveware Problem_ has left
  328. Ge0rG larma, daniel: are FT initiation semantics different from call initiation semantics?
  329. larma In Jingle or in other transport methods?
  330. Ge0rG in jingle
  331. larma The major difference I would see is that the intent is different. For Calls, you want to accept them on at most one device and you want to be able to cancel the ringing on all devices from just one device. For FT, you might want to receive the file on multiple devices and rejecting the file on one device does not rule out that you still want to retrieve it on another device
  332. larma So the semantics of JMI don't really fit the typical UX for file transfers I'd expect
  333. Kev (FWIW, ignoring technical issues, the flow for a user of files vs calls are completely different)
  334. Kev (FWIW, ignoring technical issues, I agree that the flow for a user of files vs calls are completely different)
  335. Kev (In fact, I'm not at all convinced that P2P one-off file transfer is the most useful thing for most people)
  336. daniel I think it depends. If you are thinking about inline media then yes. If you are thinking about capital F Files then jmi can be fine
  337. daniel Here is this Linux ISO image. What Client would you like to receive this on. Surely not all of them
  338. larma SIMS/SFT solve this by not actually starting a jingle file transfer, but telling the recipient where to fetch the file from (which can result in multiple independent Jingle FT)
  339. Kev daniel: Sure, but that ISO is probably also not time-sensitive in the way that a call is.
  340. _Liveware Problem_ has joined
  341. daniel No. But I still would like to have the offer on all my clients and then decide which device should receive it
  342. larma SIMS/SFS solve this by not actually starting a jingle file transfer, but telling the recipient where to fetch the file from (which can result in multiple independent Jingle FT)
  343. larma daniel, which you can with SFS
  344. daniel i guess... but i kind like to keep a universal way to establish a jingle session w/o a specific resource. because jingle is universal and not just files and calls
  345. daniel if we take 353 away and only solve files and calls then we don’t have this anymore
  346. dwd So... Do we have/want a concept of a data channel, like WebRTC does, and if so, where would this fit in? Anywhere?
  347. jonas’ generalism is often a fallacy
  348. larma daniel, well that was my thinking as well, but in the meantime, everyone told me that 353 is not really meant to be used for anything but calls 😕
  349. Kev > generalism is often a fallacy That seems over-general of you.
  350. jonas’ we have the acute requirement of making call initiations immediately visible even on push-only devices, so having those easily recognizable for the server is crucial
  351. dwd jonas’, Well, too much generalism and you don't have anything concretely useful, yes. Too little, and you don't have anything generally useful.
  352. daniel larma: who is everyone
  353. larma dwd, webrtc data channels are a jingle transport method (the current XEP is broken, but nobody seems to care)
  354. larma dwd, webrtc data channels are a jingle transport method (the current XEP is broken, but nobody seems to care) and thus is not relevant here
  355. larma daniel, well, it seems to be a popular opinion
  356. larma Not going to name people 😀
  357. Ge0rG What have I initiated?
  358. dwd larma, I'm thinking less of the transport itself, and more the concept that two XMPP entities may wish to setup a binary p2p channel. WebRTC-land systems build p2p file transfer from this. I'm wondering if this concept would fit semantically into 353, or something else entirely.
  359. jonas’ Ge0rG, also, why here, it would've been much better to have this in xsf@ for visibility.
  360. daniel Fwiw I would probably care. One of these days I would really like to fix my jingle ft implemention and support webrtc based file transfer (in addition to the current ones)
  361. dwd jonas’, We sort of started here and it's continued.
  362. Ge0rG jonas’: it all started out as "I need to decide what to veto today"
  363. daniel But I absolutely don't have the time and energy for that
  364. jonas’ (maybe we should revisit the "merge council@ into xsf@" idea)
  365. daniel So it's not not caring
  366. Kev > (maybe we should revisit the "merge council@ into xsf@" idea) I'm still on 'please don't' for that :)
  367. jonas’ sorry, you're not on council
  368. larma dwd, it works with SFS (XEP-0447) for as long as both sides support the corresponding transport method
  369. Ge0rG I like having this place for Council meetings and discussions, sorry for accidentally escalating general protocol discussions.
  370. larma maybe we should all just stop talking here and continue at xsf@, without giving any context there whatsoever? 😀
  371. Kev > sorry, you're not on council That's uncalled for.
  372. larma unless it's council meeting of course
  373. larma daniel, yes, I only know because I cared once but then lacked energy and time to fix it
  374. jonas’ I mean the good thing is that people can read up on logs.xmpp.org, but IME trying to transfer a conversation from one place to another is quite lossy
  375. jonas’ Kev, sorry, but I'm not sure why this matters for anyone except council
  376. Kev It matters *most* for people who aren't Council.
  377. Kev Having council meetings in council@ means that anyone who wants to observe Council needs to only watch for council@ to pop up with activity in their roster to know Council are active.
  378. Sam ^
  379. Sam Or +1 or whatever annoying notification we're generating these days.
  380. Kev AOL
  381. jonas’ Kev, right, that makes sense
  382. _Liveware Problem_ has left
  383. pprrks has joined
  384. pprrks has left
  385. pprrks has joined
  386. SouL has left
  387. vaulor has left
  388. vaulor has joined
  389. SouL has joined
  390. pprrks has left
  391. _Liveware Problem_ has joined
  392. pprrks has joined
  393. pprrks has left
  394. pprrks has joined
  395. Wojtek has left
  396. Wojtek has joined
  397. Tobias has left
  398. sonny has left
  399. sonny has joined
  400. Tobias has joined
  401. moparisthebest almost that time
  402. Ge0rG moparisthebest: you are waaaaay too early
  403. Ge0rG triggers NTP resync, just in case
  404. moparisthebest my opinion on the whole jingle thing is roughly in a contest between "it might be nice if..." vs "running code" the "running code" should always win, ie, accept the protoxep
  405. jonas’ moparisthebest, normally I'd agree
  406. jonas’ however! the running code is, AFAIK, not taking mobile and the push challenges into account
  407. jonas’ where building upon the '353 payload would be preferable
  408. moparisthebest Ge0rG, 6 minutes from now no ?
  409. jonas’ way too early!
  410. jonas’ I propose we settle this debate in a round of hedgewars
  411. moparisthebest ah ok, you had me worried some DST thing happened :)
  412. moparisthebest my calendar alarm is what didn't go off 2 weeks ago, so I resorted to a standard alarm, but that doesn't take DST into account :'(
  413. moparisthebest I hate computers, or timezones, or both
  414. jonas’ we typically discuss DST a week before it happens
  415. daniel It's time
  416. daniel 1) Roll call
  417. moparisthebest o/
  418. jonas’ escapes out of hedgewars
  419. jonas’ o/
  420. Ge0rG .o/
  421. larma 👋️
  422. daniel 2) Agenda Bashing
  423. daniel Ge0rG, wanted to propose an AOB. but since this effects pending votes (which comes before AOB) we should probably discuss now
  424. jonas’ ack
  425. daniel if there is anything left to discuss after the earlier discussion
  426. Ge0rG I have a feeling that most of my AOB has been covered.
  427. jonas’ I had to read the discussion in a tram on my way home, and I'm a bit dizzy now
  428. Ge0rG But yeah, I'd like to give a summary as a pre-pending-votes AOB block
  429. jonas’ yes please
  430. daniel Ge0rG, go ahead then
  431. Ge0rG There was a set of three proto XEPs proposed two weeks ago, covering some ground that has already been proposed / implemented in other XEPs
  432. Ge0rG https://xmpp.org/extensions/inbox/replies.html is yet another mechanism to reference messages, in addition to references, fastening and what else we have.
  433. Ge0rG However, I think that it adds UX value and will probably play well with some sort of revised fallback, so I'm generally +1 on that, even though slightly hesitant because of the message-reference mess that we are in
  434. Ge0rG compatibility-fallback provides additional semantics to what we have in XEP-0428, while looking vaguely similar from the XEP title, and given that dwd agrees about merging the two and sorting out the exact security considerations on the way, I think it's better to reject this one.
  435. Ge0rG And call-invites is something that overlaps very much of 0353 and where it really wasn't made clear why it can't be achieved from 0353. The discussion that we have had in here about it made the points clear, and reinfoced my feeling that this should be merged into 0353 to focus on calls (1:1 and groups) and not have a dedicated wire protocol for the same UX semantics
  436. Ge0rG Thanks everybody for the productive discussion earlier today and for helping me make up my mind
  437. moparisthebest quite different UX was the takeaway I had
  438. Ge0rG moparisthebest: different UX between 0353 and call-invites?
  439. moparisthebest very different UX between "generic jingle(ie file sharing) invites" vs "call invites" yes
  440. daniel Ge0rG, I agree with your critism. However > Note well that no special criteria (other than acceptance by the Approving Body and minimal formatting compliance) need to be met in order for a XEP to be granted a status of Experimental. The granting of Experimental status must not be construed as indicating any level of approval by the XSF, the XMPP Council, or the XMPP developer community.
  441. jonas’ moparisthebest, my take away was "in theory that, in practice '353 is mostly used for calls and in addition you wouldn't want to get push notifications for a file offer in contrast to a call on iOS (where those tend to be loud)"
  442. moparisthebest I'm not sure you wouldn't want a push notification for a file transfer you've been waiting for but that's starting to go down a rabbit hole...
  443. larma moparisthebest, at least you probably want to handle them differently
  444. jonas’ moparisthebest, yes, though it makes sense to treat them differently still
  445. jonas’ iOS is weird with call UI requirements for voice pushes
  446. moparisthebest to me, if the decision is "well we are going to need another XEP anyway, but maybe some things in this new one and 353 could be shuffled around" then accepting is the right thing to do
  447. jonas’ right
  448. marc0s has left
  449. marc0s has joined
  450. jonas’ larma, what do you think here?
  451. jonas’ daniel, do we want to extend the voting period by a week to give larma a chance to sync with thilo and primarily affected client devs about the options for '353?
  452. moparisthebest that sounds like a good idea to me...
  453. daniel sure.
  454. jonas’ because I think the way forward depends on the agreement and commitment of a few parties anyway
  455. jonas’ larma, do you think that'd be useful?
  456. jonas’ I seem to recall that Ge0rG will be AFK next week though, which makes that a bit complex
  457. moparisthebest extend 2 weeks ?
  458. Zash if you're moving towards communicating semantics instead of transport methods, then that sounds awesome
  459. Ge0rG Three weeks.
  460. daniel reject and resubmit is virtually the same thing though, no?
  461. larma I think Jingle File Transfer are best done not using 0353 but 0447. AFAIK we can do three things over Jingle: Calls, File Transfer and XML streams. If we move 0353 to Calls only, we might need something like it for Jingle XML streams in the future, but nobody is doing those anyway.
  462. jonas’ daniel, ack
  463. jonas’ larma, ack
  464. Ge0rG I reject the current proposal anyway because it lacks a rationale that clearly describes how 0353 is unsuitable
  465. jonas’ so whatever works is okay by me—I just would like that dino (who've been doing excellent work with conferencing) don't end up in a dead end here and I want that they have their work valued
  466. daniel ok. i'll ask for votes on the individual xeps in the "pending votes" section
  467. daniel should we move on then?
  468. jonas’ wfm
  469. Ge0rG daniel: yes please
  470. daniel 3) Editor updates
  471. daniel nothing new last week
  472. daniel 4) Items for voting
  473. daniel XEP-0060: Specify pubsub#type to reflect semantic info (https://github.com/xsf/xeps/pull/1148)
  474. jonas’ +1
  475. daniel a) XEP-0060: Specify pubsub#type to reflect semantic info (https://github.com/xsf/xeps/pull/1148)
  476. larma Ge0rG, for the record, I do think the Introduction of the proposal already has some decent words as to why 0353 is different
  477. moparisthebest +1
  478. Ge0rG That looks rather editorial to me, also +1
  479. daniel on list for that one
  480. larma daniel, +1 for me
  481. daniel Ok thank you
  482. daniel b) XEP-0256: Deprecate in favour of XEP-0319 (https://github.com/xsf/xeps/pull/1149)
  483. moparisthebest +1
  484. daniel As someone who implemented 319 and thought it was lacking stuff I'm not sure that 0319 "has won the race"
  485. Ge0rG +1
  486. jonas’ +1
  487. _Liveware Problem_ has left
  488. jonas’ what is it lacking?
  489. Ge0rG oh, I have an AOB for 319
  490. jonas’ they look pretty identical to me
  491. Ge0rG Should it be put into CS'22?
  492. daniel i'm not saying it's better or worse than 256
  493. daniel but it didn’t feel ready
  494. jonas’ apropos what happened to my agenda point about CS'22? :)
  495. jonas’ it's draft tho
  496. daniel and it feels wrong to deprecate something in favor of something that isn't ready
  497. moparisthebest it looked like it just replaced relative time with absolute time to me ?
  498. daniel anyway i'm +0
  499. larma I think 319 lacks functionality to indicate that the timestamp is a rough estimate and not exact, but beside that, I'm +1 on getting rid of 256 so we don't have a duplicate
  500. moparisthebest that's basically always true of a timestamp you recieve from across the network, or, maybe from anywhere...
  501. jonas’ daniel, Ge0rG is also already +1
  502. larma moparisthebest, no what I mean is, I set a timestamp that is rounded to the next full hour for privacy reasons, and I want to be able to tell that it's rounded
  503. larma (Telegram has that feature)
  504. daniel yes i have a bunch of issues with 319 but that's not the right forum for this and probably orthogonal to deprecating 256
  505. daniel anyway moving on
  506. daniel 5) Pending votes
  507. moparisthebest actually that seems like it should be covered in security considerations, but yea going off on a tangent here...
  508. _Liveware Problem_ has joined
  509. daniel Ge0rG, do you want to cast your votes on the three proto xeps now
  510. Ge0rG daniel: yes
  511. jonas’ (four?)
  512. daniel four?
  513. daniel oh yes four
  514. jonas’ at least the SoD doesn't hav… ok :)
  515. Ge0rG https://xmpp.org/extensions/inbox/replies.html +0 I like the idea and the UX, but I dislike the mess we are in regarding message reference mechanisms
  516. Ge0rG https://xmpp.org/extensions/inbox/compatibility-fallback.html -1 This needs to be merged into 0428
  517. Ge0rG https://xmpp.org/extensions/inbox/call-invites.html -1 This should be merged into 0353 unless this merging fails, in which case it needs a better description of why 0353 is not sufficient. The one that it has I've read, but consider it inadequate as it lacks depth
  518. pprrks has left
  519. Ge0rG https://xmpp.org/extensions/inbox/pubsub-ns.html -1 As discussed before this needs to go into pubsub#type
  520. daniel ok thank you Ge0rG
  521. Ge0rG I'm not done yet
  522. jonas’ I'm -1 on the '30 modification
  523. Ge0rG #1145 removes too much from 0030, I've written my feedback to the ML. -1
  524. daniel i was about to call for votes on the 30 mod after that
  525. jonas’ I'm -1 on the '30 modification, supporting the reasons on-list: It is well suited in the PEP add-ons. I like dwd's reasoning that "otherwise trusted" should be taken for that
  526. daniel or now
  527. daniel because everyone is (or was) pending on that
  528. jonas’ I'm -1 on the '30 modification, supporting the reasons on-list: It is well suited in the PEP add-ons. I like dwd's reasoning that "otherwise trusted" should be taken for that as an escape hatch.
  529. moparisthebest also -1 on 30 mod, and I think the XEPs that make it useable for harvesting JIDs need fixed but again, tangent...
  530. jonas’ moparisthebest, rationale for the -1?
  531. moparisthebest we shouldn't allow it to become useable for harvesting JIDs
  532. daniel i'm -1 too see my standards post
  533. moparisthebest I mean, it already is, and that needs fixed, not expanded
  534. jonas’ moparisthebest, suggestions welcome I suppose (though that should go in xsf@)
  535. moparisthebest yep!
  536. daniel larma, do you want to vote now on the 30 mod?
  537. larma -1 here as well, similar reasoning as moparisthebest
  538. daniel ok
  539. larma I also don't think it's needed that you can disco to fetch the pep node 🤷️
  540. daniel 6) Date of Next
  541. Ge0rG +3W WFM
  542. jonas’ +1w wfm
  543. jonas’ happy holidays, Ge0rG
  544. daniel +1w wfm
  545. moparisthebest +1w wfm
  546. Ge0rG thanks very much
  547. larma +1w wfm
  548. daniel 7) AOB
  549. daniel jonas’, had some but we are also over time.
  550. daniel are people fine by extending by 10mins
  551. daniel are people fine by extending by 10mins?
  552. jonas’ ack
  553. Ge0rG +1
  554. larma fine with me
  555. daniel go ahead jonas’
  556. jonas’ we should advance the CS-2022
  557. jonas’ they're still stable and should be moved to final, now that '22 started
  558. jonas’ or should we?
  559. jonas’ anyway, if there are no objections, the editor may issue a CFE
  560. daniel have we moved previous CSes to final?
  561. daniel i actually can't remember
  562. jonas’ we tried…
  563. larma '21 is still Draft/Stable
  564. jonas’ right
  565. jonas’ we should definitely fix that
  566. jonas’ I don't have strong opinions on the Final actually
  567. daniel we could try to move it to final. but i don’t think we have to necessarily
  568. jonas’ given that it's now called stable, I can live with that
  569. daniel i think it provides value as is
  570. daniel plus how would apply the 2 implementations rule?
  571. daniel i don’t think there is even one which fully implements it
  572. jonas’ right
  573. moparisthebest I feel like we should move it to final but I'm not going to cry about it either way :)
  574. Ge0rG I'm sure there is a bunch of implementations of Core Core XMPP.
  575. jonas’ I'll prepare a PR for deprecation of the 2021 one
  576. jonas’ End of AOB from my side
  577. Ge0rG I'm slightly in favor of moving '22 to final
  578. larma thanks jonas’
  579. Tobias has left
  580. larma is it deprecating or obsoleting '21?
  581. jonas’ deprecation needs to come first anyway
  582. jonas’ we can easily vote on both
  583. jonas’ I mean we can right now, if we want
  584. jonas’ which I'd like, given that Ge0rG is AFK for 2w
  585. daniel ok let's do this. we still have 5 minutes :-)
  586. jonas’ I'm +1 on first deprecating and then obsoleting XEP-0443 (CS-2021)
  587. larma +1
  588. daniel (thank you for looking up the xep number :))
  589. daniel +1
  590. Ge0rG +1
  591. jonas’ thank you for blindly believing me and unanimously obsoleting message styling
  592. Tobias has joined
  593. jonas’ ;)
  594. larma 😀
  595. Ge0rG jonas’: we still have Message Fancying
  596. jonas’ moparisthebest, ^
  597. moparisthebest +1
  598. Zash Message Fancying is 𝐹𝑎𝑛𝑐𝑦
  599. jonas’ cool, so that's done
  600. daniel ok
  601. daniel 8) Close
  602. daniel Thank you everyone
  603. jonas’ thanks everyone, productive meeting (with the precursing discussion!)
  604. Ge0rG Thanks daniel
  605. moparisthebest thanks all :)
  606. Ge0rG Yeah, thanks very much for the discussion as well! :)
  607. moparisthebest have a good time Ge0rG !
  608. larma thanks 🙂
  609. _Liveware Problem_ has left
  610. Tobias has left
  611. daniel has left
  612. daniel has joined
  613. Tobias has joined
  614. mdosch has left
  615. mdosch has joined
  616. pprrks has joined
  617. pprrks has left
  618. pprrks has joined
  619. David has left
  620. David has joined
  621. sonny has left
  622. sonny has joined
  623. pprrks has left
  624. pprrks has joined
  625. Kev has left
  626. pprrks has left
  627. pprrks has joined
  628. Kev has joined
  629. Kev has left
  630. Kev has joined
  631. pprrks has left
  632. pprrks has joined
  633. Kev has left
  634. Kev has joined
  635. Wojtek has left
  636. Wojtek has joined
  637. Kev has left
  638. Kev has joined
  639. pprrks has left
  640. pprrks has joined
  641. pprrks has left
  642. pprrks has joined
  643. pprrks has left
  644. pprrks has joined
  645. pprrks has left
  646. pprrks has joined
  647. pprrks has left
  648. pprrks has joined
  649. pprrks has left
  650. pprrks has joined
  651. pprrks has left
  652. pprrks has joined
  653. pprrks has left
  654. pprrks has joined
  655. pprrks has left
  656. pprrks has joined
  657. Wojtek has left
  658. pprrks has left
  659. pprrks has joined
  660. pprrks has left
  661. pprrks has joined
  662. pprrks has left
  663. pprrks has joined
  664. pprrks has left
  665. pprrks has joined
  666. Kev has left
  667. Kev has joined
  668. sonny has left
  669. sonny has joined
  670. pprrks has left
  671. pprrks has joined
  672. Kev has left
  673. msavoritias has left
  674. neox has left
  675. Kev has joined
  676. sonny has left
  677. sonny has joined
  678. pprrks has left
  679. pprrks has joined
  680. Sam has left
  681. Sam has joined
  682. pprrks has left
  683. pprrks has joined
  684. _Liveware Problem_ has joined
  685. pprrks has left
  686. pprrks has joined
  687. pprrks has left
  688. pprrks has joined
  689. _Liveware Problem_ has left
  690. _Liveware Problem_ has joined
  691. Kev has left
  692. Kev has joined
  693. pprrks has left
  694. pprrks has joined
  695. pprrks has left
  696. pprrks has joined
  697. SouL has left
  698. pprrks has left
  699. pprrks has joined
  700. sonny has left
  701. sonny has joined
  702. pprrks has left
  703. pprrks has joined
  704. pprrks has left
  705. pprrks has joined
  706. pprrks has left
  707. pprrks has joined
  708. marc0s has left
  709. marc0s has joined
  710. pprrks has left
  711. pprrks has joined
  712. pprrks has left
  713. pprrks has joined
  714. ChronosX88 has left
  715. ChronosX88 has joined
  716. _Liveware Problem_ has left
  717. _Liveware Problem_ has joined
  718. ChronosX88 has left
  719. ChronosX88 has joined
  720. pprrks has left
  721. pprrks has joined
  722. pprrks has left
  723. pprrks has joined
  724. pprrks has left
  725. pprrks has joined
  726. pprrks has left
  727. sonny has left
  728. sonny has joined
  729. pprrks has joined
  730. sonny has left
  731. sonny has joined
  732. pprrks has left
  733. pprrks has joined
  734. pprrks has left
  735. pprrks has joined
  736. pprrks has left
  737. pprrks has joined
  738. pprrks has left
  739. pprrks has joined