XSF Discussion - 2020-02-05

  1. pdurbin has joined

  2. mukt2 has left

  3. mimi89999 has left

  4. mimi89999 has joined

  5. mukt2 has joined

  6. mukt2 has left

  7. calvin has left

  8. calvin has joined

  9. pdurbin has left

  10. debacle has left

  11. Marc has left

  12. Marc has joined

  13. mukt2 has joined

  14. calvin has left

  15. mukt2 has left

  16. alameyo has left

  17. alameyo has joined

  18. mukt2 has joined

  19. alameyo has left

  20. alameyo has joined

  21. mukt2 has left

  22. stpeter has left

  23. mukt2 has joined

  24. adiaholic has joined

  25. stpeter has joined

  26. mukt2 has left

  27. mukt2 has joined

  28. karoshi has left

  29. lskdjf has left

  30. david has left

  31. david has joined

  32. adiaholic has left

  33. adiaholic has joined

  34. stpeter has left

  35. mukt2 has left

  36. pdurbin has joined

  37. stpeter has joined

  38. Maranda has left

  39. pdurbin has left

  40. Maranda has joined

  41. andrey.g has joined

  42. adiaholic has left

  43. stpeter has left

  44. andrey.g has left

  45. mathijs has left

  46. adiaholic has joined

  47. mathijs has joined

  48. andrey.g has joined

  49. stpeter has joined

  50. mukt2 has joined

  51. mathijs has left

  52. mathijs has joined

  53. mukt2 has left

  54. stpeter has left

  55. Yagiza has joined

  56. stpeter has joined

  57. pdurbin has joined

  58. mukt2 has joined

  59. stpeter has left

  60. Tobias has joined

  61. gav has left

  62. stpeter has joined

  63. mukt2 has left

  64. mukt2 has joined

  65. stpeter has left

  66. mukt2 has left

  67. mukt2 has joined

  68. mukt2 has left

  69. mukt2 has joined

  70. stpeter has joined

  71. mukt2 has left

  72. pdurbin has left

  73. mukt2 has joined

  74. pdurbin has joined

  75. adiaholic has left

  76. adiaholic has joined

  77. stpeter has left

  78. mukt2 has left

  79. mukt2 has joined

  80. andy has joined

  81. andy has left

  82. stpeter has joined

  83. Nekit has joined

  84. mukt2 has left

  85. lorddavidiii has joined

  86. stpeter has left

  87. Max has left

  88. Max has joined

  89. mukt2 has joined

  90. Max has left

  91. Max has joined

  92. Max has left

  93. Max has joined

  94. waqas has joined

  95. stpeter has joined

  96. lorddavidiii has left

  97. lorddavidiii has joined

  98. lorddavidiii has left

  99. lorddavidiii has joined

  100. paul has joined

  101. stpeter has left

  102. paul has left

  103. adiaholic has left

  104. adiaholic has joined

  105. paul has joined

  106. david has left

  107. mukt2 has left

  108. mukt2 has joined

  109. stpeter has joined

  110. david has joined

  111. j.r has left

  112. stpeter has left

  113. j.r has joined

  114. wurstsalat has joined

  115. mukt2 has left

  116. mukt2 has joined

  117. stpeter has joined

  118. adiaholic has left

  119. adiaholic has joined

  120. Extarv has left

  121. Extarv has joined

  122. winfried

    Zash: free and open flu?

  123. mukt2 has left

  124. mimi89999 has left

  125. mimi89999 has joined

  126. stpeter has left

  127. karoshi has joined

  128. j.r has left

  129. stpeter has joined

  130. flow

    more like: free andn openly distributed epidemic

  131. aj has joined

  132. afrogeek has joined

  133. aj has left

  134. afrogeek has left

  135. stpeter has left

  136. afrogeek has joined

  137. afrogeek has left

  138. waqas has left

  139. debacle has joined

  140. Steve Kille has left

  141. stpeter has joined

  142. afrogeek has joined

  143. moparisthebest has left

  144. moparisthebest has joined

  145. lorddavidiii has left

  146. mimi89999 has left

  147. mimi89999 has joined

  148. Steve Kille has joined

  149. afrogeek has left

  150. lorddavidiii has joined

  151. afrogeek has joined

  152. stpeter has left

  153. afrogeek has left

  154. afrogeek has joined

  155. afrogeek has left

  156. afrogeek has joined

  157. dwd

    Yeah, kind of wishing this were a more restrictive licence.

  158. Marc has left

  159. afrogeek has left

  160. stpeter has joined

  161. afrogeek has joined

  162. adiaholic has left

  163. Marc has joined

  164. Guus

    How are you feeling today, dwd ?

  165. j.r has joined

  166. dwd

    Terrible. But nothing that can't be fixed. Doctors coming later this morning.

  167. Max has left

  168. Max has joined

  169. afrogeek has left

  170. Max has left

  171. Max has joined

  172. mathijs has left

  173. afrogeek has joined

  174. mathijs has joined

  175. Max has left

  176. ralphm

    I hear Guus lost 3 kg, so look on the bright side :/ Hope you feel better soon.

  177. Max has joined

  178. Guus

    (almost 4, actually)

  179. mathijs has left

  180. mathijs has joined

  181. Guus

    I hope you feel better soon, Dave.

  182. Guus

    when did this start? Only after you got back?

  183. afrogeek has left

  184. Max has left

  185. Max has joined

  186. stpeter has left

  187. j.r has left

  188. mathijs has left

  189. mathijs has joined

  190. mathijs has left

  191. mathijs has joined

  192. afrogeek has joined

  193. Steve Kille has left

  194. stpeter has joined

  195. afrogeek has left

  196. afrogeek has joined

  197. mathijs has left

  198. mathijs has joined

  199. afrogeek has left

  200. mathijs has left

  201. mathijs has joined

  202. afrogeek has joined

  203. stpeter has left

  204. afrogeek has left

  205. afrogeek has joined

  206. mimi89999 has left

  207. mimi89999 has joined

  208. afrogeek has left

  209. lskdjf has joined

  210. afrogeek has joined

  211. mimi89999 has left

  212. mimi89999 has joined

  213. stpeter has joined

  214. afrogeek has left

  215. adiaholic has joined

  216. afrogeek has joined

  217. mimi89999 has left

  218. mimi89999 has joined

  219. afrogeek has left

  220. afrogeek has joined

  221. stpeter has left

  222. afrogeek has left

  223. APach has left

  224. eevvoor has joined

  225. APach has joined

  226. pdurbin has left

  227. stpeter has joined

  228. debacle has left

  229. Dele Olajide has joined

  230. stpeter has left

  231. larma has left

  232. debacle has joined

  233. stpeter has joined

  234. eevvoor

    my colleague lost purse and smartphone on the way back of FOSDEM. He travelled the whole monday due to lost identity. But he is healthy.

  235. stpeter has left

  236. pep.

    I was surprised at some point because my bag had been moved from one place behind the booth to another part of the booth (behind the Matrix people!!) and under a pile of bags :x

  237. ralphm

    pep., you're welcome. I think I've made it clear the lounge was not a bag storage facility, so I regularly moved stray bags there.

  238. pep.

    I probably wasn't there when you said that, but ok

  239. ralphm

    I think I mentioned it at the Summit, too, but no worries.

  240. intosi

    That's something we say every year, in quite some abundance.

  241. ralphm

    Most of them were from the Matrix people.

  242. pep.

    intosi, not all of us have been involved for the same amount of time

  243. goffi has joined

  244. pep.

    Also that's a FOSDEM-specific thing, because I've been running other conferences and it usually works well that way :)

  245. ralphm

    Having bags behind a booth is typical indeed, but destroys the concept of a lounge. That's why I mentioned it at the end of the summit.

  246. ralphm

    (there were other factors that caused the lounge to not work this year, but that's a different discussion that I don't have time for to go into now)

  247. stpeter has joined

  248. eevvoor has left

  249. stpeter has left

  250. larma has joined

  251. larma has left

  252. larma has joined

  253. Kev has joined

  254. stpeter has joined

  255. pdurbin has joined

  256. pdurbin has left

  257. Marc has left

  258. Marc has joined

  259. stpeter has left

  260. eevvoor has joined

  261. stpeter has joined

  262. j.r has joined

  263. stpeter has left

  264. j.r has left

  265. Guus

    https://xmpp.org/extensions/xep-0424.html section 5: > Some clients may have been offline while the retraction was issued. The archiving service therefore MUST store the retraction message, regardless of whether the original message is deleted or replaced with a tombstone. This adds a server-sided restriction to this otherwise client-sided XEP, which I dislike. If the MAM implementation on the server does not follow this, retraction is very flaky (MAM retrieval will return the original message, but not the retraction). However, server support is not clearly signalled for in the XEP (service discovery examples imply that only partners are queried). Am I missing something?

  266. Guus

    (as the retraction message has no body, that message might not be archived by MAM implementations that are not aware of XEP-0424)

  267. pep.

    Maybe adding a store hint to the XEP would help?

  268. xsf has joined

  269. stpeter has joined

  270. xsf has left

  271. xsf has joined

  272. Dele Olajide has left

  273. Dele Olajide has joined

  274. flow

    but aren't hints deprecated?

  275. larma

    flow, it's deferred

  276. Ge0rG

    but it was very much disliked by the Council that decided on it last time

  277. j.r has joined

  278. larma

    There is no replacement for it other than fallback bodies which is stupid for things like retraction really

  279. lorddavidiii has left

  280. lorddavidiii has joined

  281. ralphm

    larma: fwiw, so is MAM itself (deferred) :-D

  282. Ge0rG

    there were two issues with Hints: a) you can't properly add hints later on; b) each hint has implications to a certain other XEP, and thus should better be described in that "master" XEP

  283. larma

    what do you mean by a)? And I agree to b) but that just means we need to update MAM instead of saying we don't do hints anymore

  284. Ge0rG

    larma: 334 contains the exhaustive list of hints. If you add a new hint, you need to version-bump Hints

  285. Ge0rG

    and if you don't version-bump, you can't have hints with new semantics that require special processing

  286. ralphm


  287. MattJ

    or just make another XEP with whatever other hints

  288. Ge0rG

    "Hints 4, this time it's serious"?

  289. pep.

    MattJ, same issue?

  290. MattJ

    What issue?

  291. MattJ

    The whole point is btw that they are "hints", it's meant to not be a disaster if they aren't followed

  292. pep.

    Not saying I understand what Ge0rG is saying, but bumping a XEP or creating a new one is technically equivalent in general

  293. MattJ

    They are also meant to be semantic, rather than tied to specific protocols

  294. Ge0rG

    pep.: with a new XEP, you don't auto-deprecate the old one, so you end up with five different Hints XEPs that all contain different hints

  295. MattJ

    So no-copy is not tied to Carbons, but any copying-to-other-resources mechanism

  296. pep.

    Ge0rG, even better!? :p

  297. larma

    Usually the hint should be in the XEP it belongs to, but now MAM and carbons don't have hints and those in 334 are widely supported and thus a de-facto standard. Also moving <store /> to MAM would mean that any other archiving XEP would need to redefine it and we'd need two hints. So at least for <store /> and related hints we should stay with the current

  298. Ge0rG

    pep.: so why not have each hint in the XEP that contains the actual processing semantics that are affected by the hint?

  299. Ge0rG

    larma: Carbons do have their own "hint"

  300. pep.

    Ge0rG, sure. It's not what I was replying to

  301. xsf has left

  302. xsf has joined

  303. Ge0rG

    but I think that Carbons and MAM are actually good causes to fix message routing and persistence semantics, i.e. IM 2.0

  304. larma

    We started this discussion about store hint 😉

  305. Ge0rG

    msg to bare --> persistent, copy-everywhere message to full --> ephemeral, no Carbon, no MAM, no offline store

  306. ralphm

    We at some point tried to have comprehensive processing rules (https://xmpp.org/extensions/xep-0079.html, AMP) and that was a bit of a failure.

  307. xsf has left

  308. xsf has joined

  309. xsf has left

  310. xsf has joined

  311. xsf has left

  312. Guus

    > There is no replacement for it other than fallback bodies which is stupid for things like retraction really I don't know if this is so stupid. It would make the retraction visible even to clients that do not support it - which makes a huge difference in semantics. Additionally, adding such a body has the side effect of the retraction having a better chance of being archived by existing MAM implementations.

  313. larma

    Ge0rG, I'd be fine with that, but legacy clients do send to full jid so we need to handle them (if we don't want a new IM network that is independent of the current)

  314. xsf has joined

  315. pep.

    Guus, how do you want to show retractions to clients that don't support it?

  316. pep.

    "The message you're still seeing above -- because I don't support retraction -- has been retracted" ?

  317. stpeter has left

  318. Dele Olajide has left

  319. Guus

    pep. basically. I'd include a copy of the retracted body, prefixed with 'retracted' or something.

  320. Guus

    it can be ugly

  321. Dele Olajide has joined

  322. Guus

    that, if anything, motivates client developers to add support. 🙂

  323. pep.

    It is to me, and also useless

  324. Ge0rG

    larma: yes, there would be tagging of IM 2 zones, and conversion from / to hints or somesuch at the 'border'. Incidentally, the same rules as discussed will apply there.

  325. Yagiza has left

  326. pep.

    Guus, you'd be helping the spammer to spam :P

  327. lorddavidiii has left

  328. Yagiza has joined

  329. Ge0rG

    Guus: that's a nice reminder to screenshot the messages!

  330. Guus

    Definitely not useless. A client that receives a retraction, but does not support _or_ show it through a fallback, is dangerous.

  331. xsf has left

  332. xsf has joined

  333. Guus

    both chat participants will have a very different understanding of the correspondence state.

  334. pep.

    Guus, how is it dangerous

  335. lorddavidiii has joined

  336. waqas has joined

  337. pep.

    I think we get into social territory, and I'd rather not

  338. Guus

    If I send you a bunch of messages, and retract one, and I am not aware that your client does not display the fact that I retracted that one message, very nasty stuff can happen.

  339. larma

    Ge0rG, so we do need hints, we just want to get rid of them longerm. Can we please stop with longterm being a reason to do stupid things now?

  340. pep.

    Guus, I could say the same of every single feature that's socially used in context.

  341. pep.

    I still use presence information and talk about it sometimes, should I put that as fallback body somewhere?

  342. Guus

    no, this is not a social thing

  343. Guus

    this is a semantic thing

  344. Ge0rG

    larma: what if we want to use longterm to not do stupid things now?

  345. Guus

    you, as a receiver, missed the fact that I, as the sender, changed the semantics.

  346. pep.

    You removed a spam message for convenience. It's fine if I still see it.

  347. Guus

    spam, sure

  348. pep.

    Or you removed information that I wasn't supposed to see, well too bad.

  349. Guus

    why would I delete my own spam, btw?

  350. pep.

    Not your own

  351. moparisthebest

    also true of any "styling" XEPs right? changed meaning and all that

  352. Guus

    you can only retract your own messages with that XEP, afaik.

  353. pep.

    Ah ok I had moderation in mind, similar case

  354. larma

    Ge0rG, we agree that longterm we do the IM 2 network without (or with less) hints and that the IM Legacy network that we are using now needs hints, so why is that a reason to deprecate hints when it is needed for the network we use now?

  355. Guus

    The fact that the receiver does not get that the information that was not ment to be sent is removed, makes the sender unaware of the fact that it was not ment to see that information.

  356. Guus

    that really has very nasty real-world problems.

  357. xsf has left

  358. xsf has joined

  359. larma

    deprecation before replacement sounds like a stupid concept for me

  360. Guus

    If will lead to situations where people do not _trust_ the messages they receive from XMPP.

  361. Guus

    and that is killing.

  362. Ge0rG

    larma: I told you the reasons I remember for Council not advancing hints.

  363. pep.

    I don't really agree with this assessment

  364. Guus

    pep. suffer from it once, and you will. Trust me on that one.

  365. pep.

    [citation required]

  366. larma

    Ge0rG, I wasn't specifically talking about you, but more about what seems to be a general thing in XSF (there also were voices to deprecate OMEMO without replacement etc)

  367. pep.

    - I don't like XXX - Oops that wasn't for you - retracted: I don't like XXX

  368. pep.


  369. Ge0rG

    larma: regarding Hints, I even do agree with the argumentation

  370. Guus

    pep. now imagine that you didn't type "- Oops that wasn't for you"

  371. pep.

    Guus, so you see twice "I don't like XXX" in clients that don'T support it?

  372. Guus

    (why would you type that, if you expect the receiving entity to receive the retraction)

  373. pep.

    Very much fixing the issue

  374. Guus

    You see: - I dont like XXX - RETRACTED: I dont like XXX which is ugly as hell, but at least has the correct, intended, semantic value.

  375. pep.

    How does that help with anything

  376. Dele Olajide has left

  377. pep.

    Now you've seen twice that XXX (potentially YOU), I don't like.

  378. Dele Olajide has joined

  379. Guus

    For clients that do not support the XEP, the message has been displayed at least once anyways, so there's little additional harm.

  380. xsf has left

  381. pep.

    For clients that do support it the message may be removed, so the fallback is useless

  382. Guus

    If you don't include the fallback message in the retraction, the receiving entity might be completely unaware that the message is retracted.

  383. Guus

    Those would only see: - I don't like XXX

  384. Guus

    (no retraction)

  385. andrey.g has left

  386. larma

    Guus, same as if the retraction message got lost 😉

  387. larma

    legacy clients might not be doing MAM

  388. Guus

    yes, so make sure that the retraction message never gets lost, by adding a fallback body. That way, XEP-support clients will remove/hide the retracted message, while clients that do not support the XEP can at least be trusted to 'receive the meaning'.

  389. Guus

    this is not a MAM issue.

  390. Guus

    the fact that it also makes it more likely that MAM implementations might behave a bit better is a nice side-effect.

  391. Guus

    the fact that it also makes it more likely that existing MAM implementations might behave a bit better is a nice side-effect.

  392. larma

    if my legacy client does not do mam/carbons it is likely to happen that this client does not receive the retraction message at all

  393. pep.

    I really don't like how we've been shoving everything into <body/> lately. This is of course not as bad as 393, as there would be a tag alongside (and hopefully the message would only be used for this), but it seems to be a trend anyway that everything and anything needs to appear in body as well

  394. larma

    let's call my legacy client pidgin, which apparently is the most popular XMPP client

  395. pep.

    It's like we're trying to write protocols on top of XMPP's <body/>

  396. Guus

    we can think of all kinds of situations in which this still would not work - but at the very least, it'd be a considerable improvement of not doing a fallback.

  397. Guus

    pep. I'm very much with you that this is ugly.

  398. Guus

    but I think it is necessary.

  399. adiaholic has left

  400. adiaholic has joined

  401. pep.

    I don't

  402. Guus

    a situation in which a message was retracted by the sender, without the recipient being aware of it, must be avoided.

  403. larma

    Guus, I believe that those clients that work proper today (= not Pidgin and other legacy clients) will support retraction soonish once it's a stable standard

  404. Dele Olajide has left

  405. Guus

    larma: we cannot have an ecosystem that is intentionally broken for some clients, and which is constantly waiting for the more modern clients to pick up the newer features (being broken untill they do).

  406. Dele Olajide has joined

  407. Guus

    we must have a decent fallback.

  408. Guus

    that's why it's called just that, a fallback.

  409. larma

    Guus, we already broke Pidgin effectively

  410. pep.

    Also these fallback things force any implementation to support things they wouldn't want to support

  411. Guus

    They don't force you to do anything

  412. pep.

    In a way yes. Now you're sending me that ugly RETRACTED: foo

  413. pep.

    Or > foo\n<reaction>, or.. some other fallback

  414. Guus

    I stand by my point that it is so much better to show that ugly message instead of receiving a retraction that your client completely ignores.

  415. Guus

    That's simply dangerous

  416. vanitasvitae has left

  417. xsf has joined

  418. vanitasvitae has joined

  419. Guus

    ideally, the recipient shouldn't receive the retraction at all, of course, using service discovery. But how does that work with a user that uses two different clients, of which just one supports retractions?

  420. pep.

    Yes the "send everything to all clients because MAM/carbons" argument

  421. xsf has left

  422. xsf has joined

  423. xsf has left

  424. Guus

    I need to get back to work.

  425. xsf has joined

  426. larma

    (completely unrelated) I started to look into issues of XEP-0385 because of Stickers. My proposed changes are now rather substantial (I'd even want to change the title), should I maybe better make a new XEP instead?

  427. pdurbin has joined

  428. calvin has joined

  429. calvin has left

  430. calvin has joined

  431. xsf has left

  432. andrey.g has joined

  433. flow

    larma, i'd present the "new" xep the community and potentially council and see if there is a clear opinion on that

  434. flow

    also maybe reach out to Tobias the xep385 author

  435. pdurbin has left

  436. Tobias

    larma, what kind of issues?

  437. stpeter has joined

  438. j.r has left

  439. larma

    Tobias, - Focus on media, not generic for any file type - Mixed content, body can not be used as a fallback - Depends on jingle file transfer for the metadata - Uses underspecified URIs - Uses XEP-0372 in underspecified fashion - Number of MUSTs that seem odd to me (must support http file upload and jingle ft, must specify description, media-type and hash)

  440. Tobias

    larma, media basically is any file format, not? i mean images, photos, videos, pdf, etc.. I don't see it limiting the kind of data you share...it only makes recommendations for video/images with regard to what should be supported so there is some interoperability.

  441. Tobias

    underspecified URIs?

  442. Tobias

    you mean these https://tools.ietf.org/html/rfc6920 ?

  443. larma

    It says "inline media sharing" which kind of implies that I can't use it to share an executable for example. The use cases literally only say how to share and receive a photo

  444. larma

    I was referring to the jingle pub uris which can hardly be used for file transfer because they just share a jingle session, but don't specify what those jingle sessions actually are. The client has to guess that it probably is the latest iteration of Jingle File Transfer

  445. larma

    (my proposal changes it to use the jinglepub element defined in XEP-0385 which allows providing a jingle description element)

  446. Tobias

    protocol wise there is nothing limiting the kind of things you can share, might as well share exe, zip, .iso images or whatever.... sure maybe examples are missing but i just went with the most common use case, of sharing audio/video/images.

  447. Tobias

    defined in 385 or 358?

  448. larma

    358, sorry

  449. Tobias


  450. larma

    I am not saying those can't be addresses in 385, but the changes are rather significant. Also the fact that you could use it for every file type IMO doesn't change the intention. The fact that there are SHOULDs for media codecs is an issue for a generic file transfer XEP

  451. Tobias

    the SHOULDs are there for interoperability in user interface

  452. larma

    Tobias, which are only needed for media, not for files

  453. Tobias


  454. larma

    which makes it unsuited for file transfer

  455. ralphm

    larma: FWIW, I didn't consider XEP-0385 to be limited to photos, videos at all. At VEON we considered it for all kinds of static media, as is mentioned in this XEP's introduction.

  456. Tobias

    i don't see how making recommendations for increased interop leads to it being unsuitable to share PDF, ISO, or whatever

  457. ralphm

    larma: On top of that, it is useful to define MTI codecs for common media you can show inline.

  458. larma

    Tobias, because those are SHOULD, which means I as a client SHOULD have a good reason to not implement those codecs

  459. stpeter has left

  460. larma

    The codecs are there because you do imply a user interface (that displays the media inline, as it says in the title). If I don't want to use this, many things in this XEP become obsolete

  461. ralphm

    I do have some concerns with this spec though: I'm not convinved about the 'inline' part, and its reliance on References in the way it is currently done. I think I'd rather have References optional and as a sibling. The inline nature is then also optional (for when you refer to a URL to a picture that is then included in the message, much like Twitter's media entities).

  462. larma

    This is what I'd like to have: https://gist.github.com/mar-v-in/48e0f3466871e6e149d166ad71728d1f

  463. ralphm

    larma: but you agree that having a list of MTI codecs doesn't prevent /other/ types of media to be transferred as 'other files'?

  464. Tobias

    for me it's kind of obvious that if you don't support inline display at all, the MTI recoomendations don't matter

  465. larma

    ralphm, I am not saying it does prevent that, it's just that the overall tone of the XEP is "use this to share media that is displayed inline" instead of "use this to share files"

  466. ralphm

    larma: I like the example, and think that's how XEP-0385 should work. Optionally with References to mark-up the text in the body.

  467. ralphm

    larma: right

  468. nyco-2 has joined

  469. Daniel

    > This is what I'd like to have: https://gist.github.com/mar-v-in/48e0f3466871e6e149d166ad71728d1f +1

  470. Tobias

    i imagined that clients either get it via HTTPS or by https://xmpp.org/extensions/xep-0234.html#requesting from some JID

  471. ralphm

    larma: note that I had a similar usage in my blog post https://ralphm.net/blog/2019/09/09/fastening

  472. waqas has left

  473. ralphm

    (scroll down to the image of a mouse)

  474. ralphm

    (although it is all inside in references, I don't think it has to)

  475. ralphm

    (although it is all inside in references, because it is referring to the previous message, I don't think it has to)

  476. jonas’

    > This is what I'd like to have: https://gist.github.com/mar-v-in/48e0f3466871e6e149d166ad71728d1f +1, though a mechanism for thunbnails would be good

  477. ralphm

    jonas’, that example has a thumbnail?

  478. Tobias

    jonas’, you could just have a 2nd file-transfer element in there for the hash of the thumbnail

  479. larma

    jonas’, I was thinking about thumbnails. Best thing I guess would be to use something like ppm in a data uri, but unfortunately most clients probably wouldn't support ppm out of the box and I think it doesn't even have a mime type

  480. jonas’

    ralphm: right.

  481. jonas’

    however, having two different syntaxes for mimetype etc is weird

  482. jonas’

    sibling file elements would make more sense? would also allow for alternative mime types for the same thing (embedded video for example)

  483. larma

    I was thinking of additional thumbnail as in blurha.sh-like thumbnails

  484. ralphm

    Unfortunately SIMS doesn't explicitly point to https://xmpp.org/extensions/xep-0264.html, but it is exactly what Tobias said.

  485. Tobias

    jonas’, kind of... but with the idea of SIMIS ( hashes of media/files + metadata + source ) it should be easy to extend it to provide sources for the hash of the thumbnail

  486. larma

    according to xep-0264, If the URI scheme is 'cid:' then the identifier MUST refer to a bit of binary data as described in Bits of Binary (XEP-0231) [1]

  487. larma

    so transport is already defined for 264 thumbnails

  488. ralphm

    The nice thing about XEP-0264, I think, is that it builds on Bits of Binary (XEP-0231).

  489. ralphm

    And then have an external storage for the actual, larger, media.

  490. j.r has joined

  491. larma

    The problem with bob thumbnails is that even those are pretty large for some networks (like mobile when you are throttled to 64kbit/s it can be a significant delay to fetch such image first)

  492. ralphm

    larma: if we'd add some kind of identifier to individual <media-sharing/> elements, then you could have a sibling references element to mark up the URL in the body, together with earlier suggestions I made with of having proper child elements in references instead of the current 'type' attribute: <reference start="0" end="100" xmlns="urn:example:reference:0"> <media id="[the id here]"/> </reference>

  493. Tobias

    my motivation for 285 was mostly to have a protocol describing what is shared and less so how (because there have been numerous file transfer protocols in the past). Furthermore, by making it content based (via secure hashes) you can easily cache things or have a small reference to the media in MAM where you know in a couple years that this messages includes an image with a certain hash. How you get the image is out of scope for the spec. Clients will likely have a cache of shared media, servers might help here too.

  494. larma

    ralphm, if we allow content in the body then we can no longer have a fallback body

  495. andy has joined

  496. ralphm

    larma: I looked at your example?

  497. ralphm

    larma: my markup just says: that (fallback) body there has a URL in that, that is actually this media object I'm describing next to me, too.

  498. larma

    That seems unnecessary to me, as that's already what it is supposed to be

  499. larma

    That's like adding <i-behave-standards-compliant /> 😀

  500. ralphm

    larma: I think it gives us both worlds: 1) a readable plain-text message, 2) a fully marked up thing. Compare how Tweets work: there's plain text representation with a bunch of additional meta data (Tweet Entities and more) that make it possible to show a richer version of it.

  501. ralphm

    You then don't "need" a fallback anymore.

  502. larma

    I specifically don't want this to be a complex mixed content message, it should just be a file transfer

  503. lorddavidiii has left

  504. larma

    The fallback in my example will be understood as a file transfer by the majority of clients already, allowing it to be anything else will cause it to no longer be displayed as such

  505. Daniel

    yes. i know what twitter is doing. that certainly has a place. but i also want a method to just share a file

  506. larma

    ^ that

  507. Daniel

    like we do now with xoob; but with more meta information

  508. ralphm

    larma: that's fine. I'm not saying you must, I'm saying you could, when you want to preserve the possibility to do 'inline' media sharing, this is how you could do it.

  509. lorddavidiii has joined

  510. xsf has joined

  511. ralphm

    I.e. adding the <reference/> would be optional, and not needed if you 'just' share a file.

  512. larma

    So that kind of concludes to: I want my proposal to be a new XEP because it does not provide what you call "inline" media sharing

  513. xsf has left

  514. xsf has joined

  515. ralphm

    So it a) removes the references wrapper, with a way to still optionally do references.

  516. ralphm


  517. larma

    (I specifically don't want that as it adds a lot of complexity for a completely different usecase that I don't necessarily want to cover)

  518. ralphm

    And my proposal is such that XEP-0385 can be both what Tobias designed, with a slightly altered format, and what you want.

  519. ralphm

    The references could be left out entirely, or indeed in the References spec. The only thing you'd need is a way to refer to the media sharing element in case there are more than 1.

  520. waqas has joined

  521. larma

    ralphm, it's not about what the protocol can do, it's about the question what clients need to do when implementing it. I want to be able to implement file transfer in a compliant way that doesn't require me to support mixed content

  522. ralphm

    And you can.

  523. Wojtek has joined

  524. ralphm

    My proposal is basically: take XEP-0385, remove the wrapping references element, maybe add an id attribute.

  525. ralphm

    (instead of redoing all of this in a new spec)

  526. ralphm

    Tobias: does that sound right?

  527. larma

    So what do I do if I receive a message like https://gist.github.com/mar-v-in/fff8ff23ef8704229cb3e1dcccf79bfa but don't support mixed media? How do I display it? Just the body or just the file share?

  528. xsf has left

  529. larma

    In my XEP I would just display the file share because the body should only be a fallback so anything in it is expected to be lost.

  530. larma

    In your XEP I'd need to implement mixed media which can be rather complex in some clients

  531. ralphm

    That's a valid point.

  532. calvin has left

  533. ralphm

    I guess I assumed you'd always show the body.

  534. ralphm

    The thing is, if I go with what you suggest, how do we get to a place where we _do_ want a body with references?

  535. larma

    ah ok, that might not have been obvious from the XML I shared

  536. larma

    ralphm, that's why I said that it makes sense to consider this new thing (which I call SFS) something else than SIMS 😉

  537. ralphm

    larma: but then how do you "upgrade" from having just SFS, to something with SFS *and* a body with references?

  538. Daniel

    i guess we can just keep sims

  539. Daniel

    and do either sfs or sims

  540. larma

    it's two different things, there is no straight forward "upgrade" path

  541. Daniel

    it's just two different things

  542. ralphm

    Daniel, having two specifications that do exactly the same thing with different fallback behaviour seems suboptiomal, though.

  543. Daniel

    it's not the same thing

  544. ralphm

    Daniel, having two specifications that do exactly the same thing with different fallback behaviour seems suboptimal, though.

  545. Daniel

    one is twitter. the other one is file transfer

  546. Daniel

    (they can probably share their media meta data format wrapper element)

  547. ralphm

    Daniel: one is sharing media, and having a body that you show, two is sharing media with a body you only show when the media sharing element is not implemented.

  548. krauq has left

  549. larma

    two is not sharing media, two is sharing a file

  550. ralphm

    a file is a medium, I don't understand the difference.

  551. larma

    something that may be impossible to display inline

  552. adiaholic has left

  553. adiaholic has joined

  554. ralphm

    I'm not sure if it is that easy to make a clear division. A rich client could show PDFs or other documents "inline". Like Slack does.

  555. Daniel

    in any case i think it is perfectly fine to try both. if during that experiment we realize that there is a lot of overlap we can still merge one into the other

  556. jonas’

    and ISOs in an inline qemu window

  557. jonas’

    thanks to qemu.js or how it’s called

  558. ralphm

    Daniel, oh, let me be clear: I'm a firm believer in accepting proposals as XEPs and then experiment and pick a "winner" later.

  559. ralphm

    I cannot think of many reasons to *not* accept a specification that lands in the inbox. Other than known or suspected IPR concerns, and whatever formatting requirements Editors set.

  560. larma

    Oh and by the way, I think we shouldn't use references for that, but use message markup instead 😉

  561. ralphm

    larma: we can have a separate discussion on this, but I think message markup and references are the same thing with slightly different flavors.

  562. adiaholic has left

  563. adiaholic has joined

  564. larma

    XEP-0372 seems to mix markup with semantic which is very odd to me

  565. stpeter has joined

  566. larma

    mmh maybe semantic is the wrong word there

  567. ralphm

    larma: in my blog post, I altered the syntax, so that there's a <reference/> element with start and end, and then child elements that define the meta data (mention, media, message, link), so that you can do extend it independently.

  568. larma

    It definitely feels wrong to have markup change the routing behavior which is what the mention reference is supposed to do

  569. ralphm

    with message markup as I think you suggested, you also have a "thing with start and end" and "meta data about that thing" (emphasise, strike through, etc)

  570. david has left

  571. david has joined

  572. xsf has joined

  573. ralphm

    larma: wait huh?

  574. ralphm

    larma: what does "change the routing behavior" mean?

  575. larma

    well, as we discussed on summit we want push notifications based on mentions.

  576. xsf has left

  577. larma

    those are completely distinct concepts to me tbh

  578. ralphm

    I see mention notifications as a potential server-side side effect

  579. ralphm

    You can totally have mentions without notifications. References is primarily about markup.

  580. larma

    I don't want server side side effects based on markup, that's my point

  581. larma

    Also what I don't like about XEP-0372 is this "everything is a uri" concept

  582. ralphm

    That's ok. References doesn't specify or suggest notifications.

  583. jonas’

    larma, +1 against the everything is a URI thing

  584. ralphm

    larma: did you look at my examples I mentioned two times now?

  585. jonas’

    see also: https://mail.jabber.org/pipermail/standards/2018-March/034559.html

  586. larma

    ralphm, I did

  587. jonas’

    re markup with side-effects: markup is inherently semantic.

  588. jonas’

    or at least, Message Markup (my XEP) is, that’s the whole point

  589. ralphm

    larma: I intentionally moved away from the everything-is-a-URI model

  590. ralphm

    By having child elements with clear specific semantics

  591. larma

    yeah, but what is the purpose of the reference thing then? It just seems like a superfluous container element

  592. larma

    jonas’, Yeah, semantic is the wrong word, I just don't want markup to change how we deliver messages and I felt this was kind of the result of the discussion on summit

  593. jonas’

    larma, I think it’s the right thing to do

  594. ralphm

    larma: my idea was that you have a common thing (start and end attributes) and a specific description of what is to be found there. If you'd like to move the start and end attributes to the 'child' element, you could, but it isn't great for later (independent) extension with other types.

  595. jonas’

    mentions influence notification routing inherently

  596. jonas’

    to make this transparent to the user, it is required that it’s tied to some kind of markup, IMO

  597. calvin has joined

  598. ralphm

    jonas’, if you want this to be tied to a specific hint, I'd not be opposed I think.

  599. larma

    jonas’, but I might want to change notification routing without explicitly mentioning (slack does support that) or mention someone without notifying them (I don't think slack supports *that*)

  600. ralphm

    larma: well, you can still mention people in one-on-ones and channels the mentionee isn't in, and then you get asked what to do in the latter case.

  601. jonas’

    larma, I think the former case is a bad idea

  602. jonas’

    and the latter case is too

  603. larma

    jonas’, I want to talk about someone without them being notified, isn't that something rather usual?

  604. jonas’

    larma, then you don’t @mention them, what’s the problem?

  605. jonas’

    @mention -> notification

  606. ralphm

    I'd say in Slack, the thing that causes the notification is not unlike the user configuring keyword mentions for themselves.

  607. xsf has joined

  608. larma

    I want client to correctly reference that person (e.g. display their profile on hover)

  609. ralphm

    (which is a different way to look at it)

  610. jonas’

    larma, I suppose a mention-reference could have a silent=true thing in it, which would then also cause appropriate rendering in the recipients client

  611. larma

    How would it be displayed differently?

  612. jonas’

    but the way it’s presented and the way it’s routed needs to be tied together to avoid confusion and intransparent behaviour

  613. jonas’

    larma, probably grayed out or something?

  614. ralphm

    Should it be displayed differently?

  615. jonas’

    I don’t know the specifics, but it needs to be distinguishable. otherwise, people wonder where their notifications went.

  616. jonas’

    and then they blame the software because it doesn’t ping them when they’re mentioned

  617. jonas’

    being pinged when you’re mentioned (unless you turned that off) is pretty much standard and expected

  618. j.r has left

  619. ralphm

    jonas’, if I implemented this, receiving side, I'd want all mentions of me to notify me, independently of what the sender suggested.

  620. larma

    re notify without mentioning, in slack if a message does not cause a user to be notified I can force a notification anyway. It makes sense if I want the message to be delivered in their silent hours even if I don't explicitly mention them

  621. jonas’

    ralphm, that’s also an option I guess

  622. stpeter has left

  623. ralphm

    And you can influence the behavior with hints, maybe.

  624. larma

    jonas’, I think the question how to do it client side (also how the client decides if they want to add the notify=false hint or not) is completely irrelevant for the spec

  625. krauq has joined

  626. xsf has left

  627. xsf has joined

  628. larma

    But I personally would prefer if we just add a <notify jid="that@person.com /> hint to the message instead of having the server parse the markup. That notify also has the positive side effect that it can be used outside the e2ee so servers can actually parse it on e2ee messages

  629. xsf has left

  630. xsf has joined

  631. ralphm

    larma: but you agree that actual notification is the responsibility of the receiving server then?

  632. larma

    ralphm, it's always the receiving server to decide, the question is what the server SHOULD base it's decision on

  633. larma

    I'd rather do it explicit in the message rather than implicit through specific markup

  634. ralphm

    Well, you could also take the position that the sending client or server explicitly send a notification.

  635. ralphm

    I don't like that one, but you could.

  636. ralphm

    So I wanted to make it clear.

  637. ralphm

    I'd be happy with a please-notify-hint.

  638. larma

    nah I want the sending client to add a hint such that the receiving server (and maybe even client) don't need to parse markup. If they want to do that anyway that's another story

  639. larma

    It just shouldn't be the intended way to parse markup

  640. ralphm

    Taking into account the use case of "forcing" a notification during dnd. Not sure how to spec that, yet.

  641. ralphm

    larma: sounds good to me

  642. nyco

    Sorry for this interruption: Call for help of promotion of the newsletter! https://fosstodon.org/@xmpp/103606882304524026 https://twitter.com/xmpp/status/1225073484176543747 https://www.linkedin.com/posts/xmpp-standards-foundation_xmpp-jabber-decentralised-activity-6630841055023558656-SFhw/ https://www.reddit.com/r/xmpp/comments/ezb3tg/the_xmpp_newsletter_full_speed_xmpp_universe_04/ https://www.facebook.com/photo.php?fbid=10158047204828454&set=p.10158047204828454&type=1&theater Like and Share, if you want, what you want, how you want :)

  643. ralphm

    larma: a while back you asked about the use of the <reference/> wrapper. Did my explanation make sense?

  644. Wojtek has left

  645. Wojtek has joined

  646. xsf has left

  647. j.r has joined

  648. larma

    ralphm, I kind of see the point. But then we would still probably want to merge reference into message markup maybe?

  649. ralphm

    I'd be happy with a common <markup> wrapper with start/end, and then merge the markup, so you can have <emphasize/> and <mention/> next to each other.

  650. ralphm

    Or something similar, I'm not sure what's better, start/end on the specific element itself, or on a wrapper, in the face of distributed extensibility. In non-XMPP cases with XML, you'd use namespaced attributes, but I think I don't like that either.

  651. Nekit has left

  652. nyco

    <emphasize/> also <empathize/> or <ironize/>?

  653. Nekit has joined

  654. stpeter has joined

  655. ralphm


  656. ralphm

    in your own namespace

  657. waqas has left

  658. pdurbin has joined

  659. j.r has left

  660. mukt2 has joined

  661. pdurbin has left

  662. Dele Olajide has left

  663. Dele Olajide has joined

  664. mukt2 has left

  665. larma has left

  666. larma has joined

  667. lovetox has joined

  668. alameyo has left

  669. alameyo has joined

  670. vanitasvitae has left

  671. vanitasvitae has joined

  672. xsf has joined

  673. xsf has left

  674. xsf has joined

  675. mathijs has left

  676. mathijs has joined

  677. xsf has left

  678. mathijs has left

  679. mathijs has joined

  680. Daniel has left

  681. Daniel has joined

  682. Yagiza has left

  683. lovetox has left

  684. lovetox has joined

  685. mathijs has left

  686. mathijs has joined

  687. nyco-2 has left

  688. nyco-2 has joined

  689. Nekit has left

  690. mathijs has left

  691. mathijs has joined

  692. eevvoor has left

  693. Steve Kille has joined

  694. nyco-2 has left

  695. calvin has left

  696. calvin has joined

  697. sonny has left

  698. lovetox has left

  699. Steve Kille has left

  700. mathijs has left

  701. mathijs has joined

  702. mathijs has left

  703. mathijs has joined

  704. lovetox has joined

  705. Steve Kille has joined

  706. pdurbin has joined

  707. mukt2 has joined

  708. j.r has joined

  709. lovetox has left

  710. lovetox has joined

  711. lovetox has left

  712. pdurbin has left

  713. sonny has joined

  714. lovetox has joined

  715. lovetox has left

  716. eevvoor has joined

  717. lovetox has joined

  718. mukt2 has left

  719. nyco-2 has joined

  720. Wojtek has left

  721. adiaholic has left

  722. adiaholic has joined

  723. Nekit has joined

  724. nyco-2 has left

  725. nyco-2 has joined

  726. alameyo has left

  727. alameyo has joined

  728. calvin has left

  729. calvin has joined

  730. Wojtek has joined

  731. lovetox has left

  732. fippo has left

  733. fippo has joined

  734. fippo has left

  735. fippo has joined

  736. andrey.g has left

  737. mukt2 has joined

  738. andrey.g has joined

  739. Shell has joined

  740. adiaholic has left

  741. adiaholic has joined

  742. mukt2 has left

  743. mathijs has left

  744. mathijs has joined

  745. calvin has left

  746. calvin has joined

  747. moparisthebest

    anyone see https://snikket.org/ ? pretty neat move

  748. lorddavidiii has left

  749. lorddavidiii has joined

  750. moparisthebest

    what is it? messaging platform. how do I chat on it? grab this app. how can I run my own server? run this snikket docker container.

  751. moparisthebest

    ah, figured out who's involved now, nice work!

  752. jonas’


  753. jonas’

    MattJ, ^

  754. moparisthebest

    had to track down git repo and commits to figure it out lol, was linked to in jmp.chat muc first

  755. MattJ


  756. pep.

    moparisthebest, #old :p

  757. jonas’

    pep., never too old for praise

  758. moparisthebest

    was it linked in here before? I could have missed it I admit

  759. jonas’

    also, shaming people for re-sharing "old" news puts an odd incentive against sharing stuff at all

  760. pep.

    jonas’, can't joke anymore?

  761. pep.

    I'm not shaming anybody

  762. MattJ

    moparisthebest: I don't think it was linked here in particular

  763. pep.

    I haven't seen it here either

  764. MattJ

    I did publish a Prosody blog post yesterday: https://blog.prosody.im/introducing-snikket/

  765. j.r has left

  766. j.r has joined

  767. MattJ

    To be honest the early reaction from XMPP community members wasn't exactly encouraging :)

  768. Wojtek has left

  769. MattJ

    But pretty much anyone here is not the target audience

  770. jonas’

    pep., sorry, I didn’t get the joke part

  771. stpeter

    so true :-)

  772. Wojtek has joined

  773. neshtaxmpp has left

  774. moparisthebest

    if XMPP is weak at one thing, it's marketing, this looks good to me

  775. MattJ

    But hopefully the blog post gives some background - I've heard a lot of "why another Conversations fork?!"

  776. wojtek has joined

  777. MattJ

    And yes, a bunch of it is simply a layer of marketing :)

  778. moparisthebest

    reaction in jmp.chat muc which is more users than developers/xmpp community looks promising

  779. stpeter

    moparisthebest: what's the chatroom for jmp?

  780. MattJ

    Yes, had a demo at the XMPP stand at FOSDEM this past weekend and I think it's fair to say it was a success

  781. pep.

    Everywhere I mentioned it outside of XMPP circles the reaction was good

  782. moparisthebest

    stpeter, xmpp:discuss@conference.soprani.ca?join

  783. stpeter


  784. jonas’

    moparisthebest, can you hint the admins of that room that their room title isn’t particularly useful (if set at all): https://search.jabber.network/search?q=discuss%40conference.soprani.ca

  785. wojtek has left

  786. pdurbin has joined

  787. mukt2 has joined

  788. moparisthebest

    jonas’, thanks, they set one!

  789. Wojtek has left

  790. Wojtek has joined

  791. jonas’

    moparisthebest, :+1:

  792. jonas’

    (the usual delay of ~1h applies)

  793. mukt2 has left

  794. pdurbin has left

  795. debacle has left

  796. matkor has left

  797. matkor has joined

  798. calvin has left

  799. Daniel has left

  800. Daniel has joined

  801. lovetox has joined

  802. Neustradamus has left

  803. Daniel has left

  804. Daniel has joined

  805. calvin has joined

  806. ralphm

    MattJ: I personally think, I hoped to express, that I think the idea and execution so far for Snikket is really good.

  807. ralphm

    MattJ: I like that you focus on a product rather than the underlying protocol

  808. ralphm

    MattJ: I'm curious why you think the community wasn't encouraging. What kind of feedback did you get? Everyone I talked to at FOSDEM thought it was great.

  809. Zash

    Seen a bunch of things like "Why yet another Conversations fork?", "What's the point of this, we already have Prosody?"

  810. MattJ

    Nothing serious or surprising - I think it probably didn't click for many people (who weren't at FOSDEM) until I laid it out in the blog post yesterday

  811. MattJ

    Partly my fault, I'd aimed to post that sooner, but got held up by last minute demo preparation

  812. moparisthebest

    *personally* I see something like that, and the first thing I do is dig to see what the underlying protocol is, software is written in etc etc, I *suspect* I'm not a normal average person in that regard

  813. moparisthebest

    I see "XMPP" and instantly know all the advantages that provides, that are spelled out there in plain english, again I suspect the normal person does not

  814. MattJ

    Right, I totally get it, it's not a surprising reaction at all for a community of geeks :)

  815. sonny has left

  816. sonny has joined

  817. MattJ

    We are used to assessing technology, but there is very little new tech here

  818. fippo

    the general concern with the trend to package client+server is that it reduces the need for specs (and spec compliance). not a concern in this case i think because of a long record :-)

  819. moparisthebest

    and to be clear I'm meaning this as praise, to a "normal person" I think that snikket looks a lot better than "grab any XMPP client or server and join in"

  820. Zash

    Given the flexibility of XMPP, having clients and servers optimized for each other makes sense.

  821. MattJ

    moparisthebest: yeah, the FOSDEM reception was great

  822. MattJ

    Lots of people new to XMPP had a simple gateway in, that was easily explained as a "self-hostable WhatsApp/Telegram/Signal/..."

  823. mukt2 has joined

  824. debacle has joined

  825. stpeter

    Snikket: The Gateway Drug to Hardcore XMPP [tm]

  826. MattJ

    Time will tell :)

  827. ralphm

    stpeter: :-D

  828. stpeter

    Not the best marketing, I suppose. ;-)

  829. Daniel has left

  830. ralphm

    MattJ: you should have put the logo in your post

  831. MattJ

    Yeah, would have delayed it further though :)

  832. ralphm

    Eh, ok.

  833. MattJ

    Currently working on docker images that actually work on a Raspberry Pi like we advertised :D

  834. MattJ

    (current ones are x86 only)

  835. ralphm

    Drug dealers often lie, so there's that.

  836. mukt2 has left

  837. Daniel has joined

  838. Daniel has left

  839. Maranda has left

  840. Maranda has joined

  841. calvin has left

  842. calvin has joined

  843. Shell has left

  844. Daniel has joined

  845. lovetox has left

  846. lovetox has joined

  847. Daniel has left

  848. lovetox has left

  849. lovetox has joined

  850. j.r has left

  851. j.r has joined

  852. lorddavidiii has left

  853. gav has joined

  854. andy has left

  855. krauq has left

  856. pdurbin has joined

  857. mukt2 has joined

  858. Tobias has left

  859. Daniel has joined

  860. lovetox has left

  861. eevvoor has left

  862. calvin has left

  863. mukt2 has left

  864. pdurbin has left

  865. Daniel has left

  866. nyco-2 has left

  867. nyco-2 has joined

  868. Dele Olajide has left

  869. Daniel has joined

  870. gav has left

  871. Daniel has left

  872. krauq has joined

  873. gav has joined

  874. kuvoh has joined

  875. kuvoh has left

  876. kuvoh has joined

  877. kuvoh has left

  878. mukt2 has joined

  879. Daniel has joined

  880. Wojtek has left

  881. alameyo has left

  882. alameyo has joined

  883. Daniel has left

  884. neshtaxmpp has joined

  885. Half-Shot[m] has left

  886. Half-Shot[m] has joined

  887. mukt2 has left

  888. Neustradamus has joined

  889. karoshi has left

  890. Neustradamus has left

  891. Neustradamus has joined

  892. karoshi has joined

  893. goffi has left

  894. Half-Shot[m] has left

  895. Half-Shot[m] has joined

  896. calvin has joined

  897. paul has left

  898. Daniel has joined

  899. mukt2 has joined

  900. pdurbin has joined

  901. Daniel has left