XSF Discussion - 2018-12-08


  1. marc has left
  2. marc has joined
  3. efrit has joined
  4. genofire has left
  5. andrey.g has left
  6. Zash has left
  7. andrey.g has joined
  8. labdsf has joined
  9. lorddavidiii has left
  10. UsL has left
  11. UsL has joined
  12. oli has joined
  13. Dele Olajide has joined
  14. Dele Olajide has left
  15. alexis has joined
  16. oli has left
  17. oli has joined
  18. lovetox has left
  19. andrey.g has left
  20. andrey.g has joined
  21. efrit has left
  22. efrit has joined
  23. lorddavidiii has left
  24. andrey.g has left
  25. vanitasvitae has left
  26. vanitasvitae has joined
  27. alexis has left
  28. andrey.g has joined
  29. efrit has left
  30. alexis has joined
  31. alexis has left
  32. alexis has joined
  33. lumi has joined
  34. alexis has left
  35. alexis has joined
  36. ta has joined
  37. waqas has joined
  38. waqas has left
  39. waqas has joined
  40. vanitasvitae has left
  41. vanitasvitae has joined
  42. alexis has left
  43. alexis has joined
  44. Yagiza has joined
  45. moparisthebest has left
  46. moparisthebest has joined
  47. ta has joined
  48. igoose has left
  49. igoose has joined
  50. oli has joined
  51. alexis has left
  52. alexis has joined
  53. alacer has joined
  54. igoose has left
  55. alacer has left
  56. ta has left
  57. igoose has joined
  58. mimi89999 has left
  59. mimi89999 has joined
  60. lorddavidiii has joined
  61. marc has left
  62. marc has joined
  63. ta has joined
  64. oli has joined
  65. dos has left
  66. Yagiza Hello!
  67. Yagiza jonas’, are you Jonas Schäfer?
  68. Yagiza Is it possible to adopt a deferred XEP?
  69. ralphm Yes.
  70. ralphm Which one?
  71. Yagiza ralphm, right now I'm about XEP-0394: Message Markup
  72. Yagiza ralphm, I want to implement something like it in my client as an alternative to deprecated XEP-0071, but in it current state it is almost useless, so I don't want. And it seems, no one wants.
  73. lskdjf has joined
  74. Yagiza ralphm, and author said that he have no time to improve it.
  75. ralphm Yeah, XHTML-IM has various security concerns, that's why it was deprecated
  76. lskdjf has left
  77. Yagiza ralphm, the idea of the XEP is good, but it's current implementation is awful. We need to add more features and remove unneeded restrictions to make it a usable alternative to XEP-0071.
  78. lskdjf has joined
  79. ralphm There's been some recent discussion on it
  80. ralphm And there are a few other suggestions
  81. Yagiza ralphm, yes. But the main question is who will keep updating the XEP. At least, to advance it back to experimental state.
  82. ralphm https://xmpp.org/extensions/inbox/bmh.html https://xmpp.org/extensions/xep-0393.html
  83. ralphm Yagiza: sure. I'd send an email to standards@xmpp.org about your suggestions for modification. Then either Jonas will ask for a pull request or more discussion ensues.
  84. Yagiza ralphm, ok, thanx
  85. Nekit has joined
  86. ralphm No worries.
  87. daniel has left
  88. daniel has joined
  89. oli Yagiza: xep-0394 _sucks_
  90. daniel has left
  91. lorddavidiii has left
  92. oli don't implement it.
  93. lorddavidiii has joined
  94. daniel has joined
  95. Yagiza oli, the idea is good.
  96. oli no its not
  97. oli i hate the idea
  98. Yagiza oli, why?
  99. Yagiza oli, I myself hate an idea of using LML in IM, but I feel ut's a good idea to allow using rich text formatting.
  100. oli because it forces me to use some weird "markup"
  101. alexis has left
  102. Yagiza oli, it forces you? Never heard about any XEP, which FORCES someone to do something.
  103. Yagiza oli, AFAIK all the XEPs are optional.
  104. oli why not use <b> <em> <i> ?
  105. Yagiza oli, what do you mean?
  106. Yagiza oli, where to use them?
  107. oli why not use some basic xhtml for rich text.
  108. frainz has left
  109. oli the client can decide how to implement it
  110. oli if you like 0394 then translate it
  111. oli client translates it to xhtml
  112. oli underlines as italics is weird...
  113. Yagiza oli, i can't get your point.
  114. Yagiza oli, what do you suggest?
  115. oli the richtext format on the wire should be xml, like xep-0071, but much simpler
  116. oli clients could implement whatsapp like markup, but translate it to xml
  117. Yagiza oli, using the way it described in XEP-0071 have nasty problem: formatted and unformatted texts are separated. So, it's possible to send absolutely different content to those, who's software supports XEP and for those, who's software do not. Also, it will make problem with P2P encryption XEPs.
  118. ralphm oli: the primary objection to having something syntactically a subset of (X)HTML is that people just throw at their closest HTML rendering engine, without checking.
  119. Yagiza oli, so, XEP-0394 is much better in that way: text itself and its formatting MUST be separated!
  120. oli maybe im confusing xeps
  121. labdsf has left
  122. Yagiza oli, yes. If you're about XEP-0393, it's really awful.
  123. Yagiza oli, I'm strongly against using LML in IM.
  124. Yagiza oli, also, it's too bad that XEP names are confusing.
  125. oli fuck, sorry
  126. Yagiza oli, I told about it more than a year ago, but nothing's changed so far.
  127. Holger has left
  128. Yagiza oli, XEP-0393 describes LML, but called "Styling" and XEP-0394 describes styling, but called "Markup"!
  129. Yagiza oli, I also was often confused because of that and often mixed them up!
  130. Jeremy has joined
  131. oli ok, i will remember 0393 *bad* 0394 good
  132. Yagiza That's why I want to adopt XEP-0394, to fix those issues and make it usable, to start its implementation in my client.
  133. oli which client
  134. oli ?
  135. Yagiza oli, yes. XEP-0393 is a bad idea itself. XEP-0394 is a good idea, but awful implementation in its current state.
  136. Yagiza oli, eyeCU.
  137. Yagiza oli, it has full implementation of XEP-0071 right now.
  138. ralphm I'd rename for being so much like ICQ you might have a trademark issue
  139. Yagiza oli, it can even use both http(s)/ftp and cid (BOB) chemas for embedded images.
  140. Yagiza ralphm, i don't think so. eyeCU called that way because it's geoloc-oriented. It has built-in online map engine, so you can see your contacts on the map.
  141. ralphm I don't have a beef in it, just saying that I'd avoid a legal discussion that you're likely to lose.
  142. ralphm I'm not taking about the client, I'm taking about its name.
  143. ralphm Talking
  144. labdsf has joined
  145. Yagiza ralphm, yes. You're just the first person, who ever tell that our client name may have legal issues.
  146. ralphm Better me than a lawyer
  147. Yagiza ralphm, yes. So, you gave me an idea to register "eyeCU" and eyeCU logo as a trademark!
  148. ralphm Good luck. I'm very curious about the outcome.
  149. oli OS/2 :)
  150. Yagiza ralphm, you are from Netherlands, you talk just like you're from USA! ;-)
  151. Yagiza oli, do you fel something bad about IBM OS/2?
  152. Yagiza feel
  153. ralphm I'm told I do sound like a Californian when speaking English.
  154. oli Yagiza: I used it in the 90s with fidonet and BBS
  155. Yagiza ralphm, yes, but that's not an idea. A character of a popular Russian sitcom said once: "USA is a country of lawyers and criminals!". The idea is that because of lawyers in USA anyone may suddenly find himself a criminal.
  156. Yagiza oli, me too!
  157. oli i dont think there is a problem with eyeCU and ICQ.
  158. oli it did remind me of CU-SeeMe
  159. oli ok, but thats offtopic
  160. Yagiza oli, I'm sure it's impossible in Russia, even now, when ICQ belongs to a Russian company. But I can't be sure about USA and other countries with strange laws and almighty lawyers.
  161. oli are there other clients that support xep-0394?
  162. Yagiza oli, I hope, no
  163. Yagiza oli, if there are, it makes its harder to improve it.
  164. Yagiza oli, the authors of those clients will try to resist serious changes.
  165. ralphm I don't see that as a valid reason against changes while it is experimental or even deferred.
  166. Yagiza ralphm, me so
  167. Yagiza ralphm, but
  168. alexis has joined
  169. Yagiza ralphm, once I tried to suggest improvements for XEP-0363 here, some people started to argue against them. And the only argument was that there are existing implementations and authors will not implement my suggestions even after XEP is updated.
  170. Holger has left
  171. ralphm Well, if they're backwards incompatible, it may require increasing the number at the end of the namespace. Whether a change gets accepted is ultimately up to the Council.
  172. ralphm Oddly, XEP-0363 is still in Last Call, so you might make another attempt.
  173. lumi has joined
  174. Yagiza ralphm, to tell the truth, I didn't even try to post my suggestions to mailing list, 'cause they were hardly criticized by a pair of participants of this (or jdev) room.
  175. Maranda has joined
  176. Ge0rG Somebody tried to make the 0363 client a full HTTP proxy and almost succeeded. The web is a huge mess for security, not only the markup but also the transport.
  177. Yagiza Ge0rG, IC
  178. lorddavidiii has left
  179. Ge0rG Also 0393 was supposed to document existing usage of the markup in some clients, and is sufficiently easy to implement. I'm not convinced that 0394 has a chance for wide adoption
  180. Yagiza Ge0rG, that's why I think it should be an informational XEP, not standards track.
  181. Ge0rG The names are really bad. I already suggested renaming them to markright (uses >) and markleft (needs < for all styling annotations)
  182. daniel Funnily enough 393 is better than what some clients are implementing
  183. Yagiza Ge0rG, the only idea I suggested is to send file hash when requesting a slot. So, if file is already on the server, server will reply just with URL, without upload slot.
  184. daniel Same syntax stricter rules
  185. Ge0rG Yagiza: I've implemented 0393 in my client. It's great.
  186. Yagiza Ge0rG, your arguments?
  187. ralphm Indeed, 0393 is basically codifying the Slack syntax, no?
  188. Yagiza Ge0rG, besides "it's great because I like it".
  189. daniel You only start noticing how important the parsing rules in 393 are when you use a client that doesn't follow
  190. daniel > Indeed, 0393 is basically codifying the Slack syntax, no? I mix of WhatsApp and slack plus some in the wild testing
  191. daniel I mean WhatsApp and slack don't publish their exact rules
  192. daniel But it's the same general syntax
  193. Ge0rG Yagiza: your suggestion is nice, but now you created an oracle that will tell the user whether a given file exists on the server
  194. Ge0rG Yagiza: 0393 is in a sweet spot of easy to implement, easy to understand for users, sufficiently easy for handicapped people
  195. Ge0rG Also works over transports
  196. Yagiza Ge0rG, yes. And what's wrong with it?
  197. alexis has joined
  198. ralphm Ge0rG: do you think that the body markup hints spec in the inbox is a useful complement to XEP-0393?
  199. Ge0rG ralphm: haven't read yet
  200. blabla has left
  201. daniel ralphm: it feels overly generalized. That will end up like the stanza-id xep or the hints xep that is only used in one place. I'd prefer to use add a <styled xml=message styling /> hint
  202. blabla has joined
  203. alexis has left
  204. alexis has joined
  205. ralphm Huh? Doesn't BHM just tell the other side which markup dialect was used in the body?
  206. ralphm BMH
  207. daniel Yes. But I don't think anyone will ever use anything else
  208. daniel And then why bother having to rely on a second xep
  209. alexis has left
  210. alexis has joined
  211. 404.city has joined
  212. efrit has joined
  213. frainz has left
  214. Yagiza Ge0rG, which of above cannot be applied to XEP-0394?
  215. pep. I would just implement xhtml-im fwiw, maybe without CSS until we find a replacement. There is no good alternative for it as of today and deprecating it was a mistake.
  216. pep. Even then, CSS included in there is pretty simple, it's not CSS3
  217. labdsf has left
  218. pep. 393 is fine as an input method, but that's about it
  219. ralphm pep.: the problem isn't which parts you use, it is how clients implement rendering, which is usually not checking the input and passing it to a generic HTML renderer
  220. pep. Yes, I just don't want to buy this argument, you can say that about pretty much anything
  221. oli lets not use the web
  222. ralphm I don't think the idea behind XEP-0394 is bad, as it provides a way to very explicitly mark up the plain text. Might be better if it was somehow combined with References.
  223. marc_ has joined
  224. oli references?
  225. ralphm https://xmpp.org/extensions/xep-0372.html
  226. ralphm And see also https://xmpp.org/extensions/xep-0385.html
  227. waqas I have very mixed feelings about xhtml-im, but the main thing I know about it is that every single client I looked at had RCE vulnerabilities.
  228. 404.city has left
  229. pep. Because it was the only place with vulnerabilities right
  230. Yagiza pep., why not just improve XEP-0394 instead of trying to rip-off CSS from XEP-0071?
  231. waqas It was. I think I averaged 15 minutes each, across more than a handful of clients before seeing something dumb.
  232. waqas Including some native clients with embedded HTML, where RCE meant full local system access.
  233. Yagiza pep., also, what's nice about LML as input method? WYSIWYG is always better for and user, than LML.
  234. pep. Yagiza: yeah I don't really care about the input method tbh
  235. Yagiza pep., so, then. Why improved XEP-0394 is not better than ripped XHTML-IM?
  236. ralphm waqas: especially in MUC context, because it doesn't require direct contact and the amplification angle?
  237. oli ralphm: > And see also https://xmpp.org/extensions/xep-0385.html i don't understand what it has to do with markup and references.
  238. pep. Yagiza, Dismiss the comment about CSS. It's not that complex. If people want more stuff in security implications, let there be more stuff added. I don't think deprecating the xep altogether was the thing to do
  239. ralphm oli: XHTML-IM provides a way to include images
  240. oli ok
  241. oli xhtml-im includes a lot
  242. Holger has left
  243. ralphm oli: so SIMS helps achieving that in a similar way as XEP-0394 does. Also why I think they should be aligned, spec wise.
  244. efrit has left
  245. waqas Note that I'm neither for, nor against deprecation. I think it's a feature people may want. It was simply concerning how hard it was to find an implementation that was secure.
  246. oli Yagiza: which changes for xep0394 do you propose?
  247. oli where are the problems?
  248. oli has left
  249. oli has joined
  250. ralphm waqas: disconcerting indeed
  251. pep. has left
  252. ralphm By the way, XEP-0393 and XEP-0394 could totally co-exist.
  253. lnj has joined
  254. efrit has joined
  255. labdsf has joined
  256. Yagiza oli, add support for embedded images and hyperlinks.
  257. Yagiza oli, add normal "bold", "italic", "underscore" text decoration instead of strange "emphasis".
  258. Yagiza oli, add ability to specify font type, font size and text color.
  259. Yagiza oli, add ability to specify text alignment.
  260. Yagiza oli, add ability to remove list markers from the beginning of list item text when rendering.
  261. Ge0rG Yagiza [10:47]: > oli, add ability to specify font type, font size and text color. This will end up with clients sending 5px Comic Sans black on black, kthx
  262. Yagiza Ge0rG, as I said many times, any feature could be abused. We should deprecate XMPP itself, 'cause there are hundreds features in it which could be used for abuse.
  263. oli but it also get used. like in the mess we have with emails
  264. ralphm Yagiza: if those are your suggestions, then I'd rather have you look at the References stuff I just mentioned
  265. ralphm Also, if it were my client, I'd never implement font type, size, or color.
  266. oli supporting font size and color will be messy
  267. Nekit has left
  268. Nekit has joined
  269. oli monospace font has some value
  270. ralphm With backticks, sure
  271. oli everything else should be semantic markup only
  272. Yagiza oli, ralphm, it depends on what you are using it for.
  273. oli maybe xhtml-im is just the right way to do everything fancy
  274. Yagiza oli, yes, but it has flaws which XEP-0394 solves.
  275. Yagiza oli, so making XEP-0394 powerful enough, but without XHTML-IM flaws is a good way, I beleive.
  276. ralphm oli: I'd see the use of monospace for literals (one backtick) and code snippets (triple backticks) as purely semantic.
  277. ralphm Allowing users to specify font size, type, or color, just makes for a horrible mess. Like different clients/desktops having different default background colors.
  278. ralphm We have this XHTML-IM right now, and at some time patched Gajim to ignore those styles completely.
  279. oli maybe we could just encapsulate rfc822 messages
  280. oli would be super fun and messy
  281. Yagiza ralphm, author of XEP-0394 thinks about specifying not text color but only its hue and saturation. To allow client always make text contrast. So, that's not really a problem.
  282. Yagiza Inability to specify bold, italic and underscore in different combinations if much worse.
  283. ralphm I don't agree with the author then, that this is useful.
  284. oli have anyone thought about accessibility?
  285. Yagiza oli, what's wrong with accessibility? If contrast problem is solved, I guess no problem.
  286. ralphm I strongly think that markup should be semantic
  287. oli and i believe that xep-0393 is not very screen reader friendly
  288. ralphm E.g. while monospace for literals is nice, it doesn't work if you are in a terminal. Then you need some other way of rendering that differently. E.g. by setting a different background.
  289. ralphm oli: why not?
  290. oli i have to test it
  291. ralphm I'd say markdown-like syntaxes are actually very good for screen readers.
  292. oli has left
  293. oli has joined
  294. !xsf_martin has joined
  295. lnj has left
  296. lnj has joined
  297. igoose has left
  298. igoose has joined
  299. oli screen reader test: *one* _two_ `three`
  300. alexis has left
  301. alexis has joined
  302. oli »one underscore two underscore backquote three backquote«
  303. oli doesn't work well with android talkback
  304. oli ~talkback~ select-to-read
  305. jonas’ Yagiza, yes, you can adopt a deferred XEP, but I might retract XEP-0394 in the medium future actually
  306. Yagiza jonas’, so, I can try to publish my own XEP instead of that one?
  307. jonas’ you can also adopt it if you want
  308. jonas’ I’d be fine with that, since I want to go down other routes, I think
  309. Yagiza jonas’, that's nice
  310. jonas’ Yagiza, my original idea where to go with XEP-0394 was to enforce a specific plain-text representation of the different markup variants to have an automatic plaintext fallback
  311. jonas’ so e.g. a span marked with strong would have to be bracketed with *
  312. jonas’ but that was just the last idea I had
  313. Yagiza jonas’, IC
  314. Yagiza jonas’, anyway, we should think about the best way to implement that all.
  315. jonas’ I think we might end up with a revamped version of '71 actually
  316. oli so xep-0071 is security nightmare, xep-0393 horrible for screen readers and sexist, xep-0394 will be retracted
  317. MattJ oli, ok, what?
  318. jonas’ what
  319. oli lets just use plaintext.
  320. jonas’ sexist?
  321. jonas’ what did I miss here?
  322. oli gender gap doesnt work
  323. oli *professor*in*
  324. oli sexist
  325. Maranda has joined
  326. oli _professor_innen_
  327. jonas’ ah, that
  328. MattJ jonas’, ? enlighten me?
  329. daniel that’s going to require so much explaining
  330. jonas’ MattJ, in german, we have gender in nouns. the male version is the default.
  331. jonas’ then there’s the "in" suffix which makes it a female word
  332. jonas’ e.g. Lehrer (-> male teacher), Lehrerin (-> female teacher)
  333. efrit has left
  334. jonas’ now the male default is viewed as sexist by some (many even?), and also the restriction to two versions (male and female) as problematic
  335. jonas’ so some constructs such as Lehrer*In (kind of a wildcard thing) or Lehrer_In (symbolising the gap in the language to support all the cases) have been invented
  336. MattJ I see
  337. jonas’ in formal language, Lehrer/In was typical (but also only represents the two versions), LehrerIn has become a shorthand of that
  338. jonas’ (I even brought that up when XEP-0393 was discussed)
  339. MattJ Sounds like it's the German language that's sexist, not XEP-0393 :)
  340. jonas’ that’s true
  341. MattJ But yes, it highlights the fact that the XEP assumes these symbols are just free for it to use for its own purpose
  342. jonas’ it does
  343. oli i'm arguing all the time that we just change the german language, but without any succesd
  344. jonas’ oli, sounds like a plan, but in that case I’d actually like to see the "*" version; I like how globby it is :)
  345. oli what do you mean?
  346. jonas’ which part of my statement is unclear to yu?
  347. jonas’ which part of my statement is unclear to you?
  348. oli like to see the * version
  349. oli ?
  350. daniel fwiw this could potentially be fixed in the xep
  351. jonas’ making the non-existent grammar more complex?
  352. daniel but that’s not as cool as complaining about stuff
  353. jonas’ still waiting on Sams promise to deliver a formal grammar for the thing.
  354. daniel jonas’, one potential fix (of the two that i have in mind) would actually make things easier
  355. daniel although i would prefer the more complicated one. :-)
  356. oli jonas’: i would eliminate the multiple grammatical genders from the german language. problem solved
  357. oli okay, but what about screen readers?
  358. jonas’ oli, I like you, you repeat all the arguments I brought up a year ago :)
  359. jonas’ gives me the feeling I’m not totally outside of the norm
  360. marc has left
  361. !xsf_martin has left
  362. dos has left
  363. dos has left
  364. dos has left
  365. dos has left
  366. Maranda has joined
  367. Maranda has joined
  368. Yagiza If I adopt XEP-0394, it won't be retracted, so calm down.
  369. lnj has left
  370. Yagiza has left
  371. Maranda has left
  372. alexde has joined
  373. Ge0rG Maybe XHTML-IM is just the wrong way to do anything. I don't want somebody else to be dictating how the text *I* shall read will look. I'm okay with the sender define monospace vs normal, and _maybe_ color hints from a predefined high contrast palette and _maybe_ relative font sizes for pasting headings.
  374. tux has left
  375. Maranda has joined
  376. alexis has left
  377. alexis has joined
  378. oli for chat i'm happy with plain text. for everything else we could resurrect google wave
  379. jonas’ Ge0rG, so you want XHTML-IM :)
  380. jonas’ not the current one
  381. jonas’ but you want semantic markup
  382. jonas’ emphasis, monospace, headings
  383. goffi has joined
  384. ralphm oli: I think that's a minority opinion.
  385. alexis has left
  386. alexis has joined
  387. oli better plain text than xep-0393. i'll try to disable it in conversations, later.
  388. lorddavidiii has joined
  389. alexis has left
  390. alexis has joined
  391. rion has left
  392. daniel has left
  393. Syndace Couple of OMEMO questions: OMEMO defines KeyTransportMessages to be used to encrypt out-of-band non-message data like pictures or files or whatever you want. In reality these KTMs have become a tool to do manual ratchet forwarding/silent session creation in case a session is broken. So my question is: if you ever wanted to use KTMs for actual data, how would you even know, which KTM is for your photos, which one is for that pdf someone sent you and which one is just a ratchet forwarder? Is there any identification mechanism? If not, should we add one? And are there any XEPs using the KTM mechanism?
  394. UsL has joined
  395. UsL has joined
  396. jonas’ Syndace, https://xmpp.org/extensions/xep-0396.html this maybe?
  397. jonas’ if KeyTransportElement == KeyTransportMessage
  398. alexis has left
  399. daniel has left
  400. alexis has joined
  401. Syndace jonas’: Thanks, it is ^^
  402. daniel Syndace: I think the original plan was to just reuse the element somewhere as a sub element
  403. Syndace daniel: That's how it's done in the XEP that jonas' linked, makes a lot of sense
  404. daniel And that would give you the context
  405. daniel Yes I don't like that xep for various reasons. But it is a good demonstration on how it was originally intended to be used
  406. genofire has left
  407. daniel has left
  408. Syndace Okay cool. At least gives me a good hint on how to add KTMs to my lib...
  409. daniel has left
  410. alexis has left
  411. alexis has joined
  412. daniel has left
  413. pep. has joined
  414. ralphm oli: I don't understand. People _already_ type markup like this, and I like that Conversations takes those hints. I don't really like that it retains the markers, though. Other messaging systems don't, when they interpret the plain text.
  415. alexis has left
  416. alexis has joined
  417. jonas’ you must retain the markers when you make up markup out of thin air
  418. jonas’ if we just had an out-of-band way to signal that the markers really are intended for markup....
  419. pep. If only
  420. daniel has left
  421. daniel I by the way have a work around for the _programmier_innen_ problem that probably shouldn't cause side effects
  422. daniel Will test this for a while
  423. daniel https://share.gultsch.de/daniel/1YQ0Fftaz84JZmZY/6h4kux4-TpOxZZMXs-4-MQ.jpg
  424. daniel Coming up with the parsing rules Was a process. It doesn't mean it has to end there. It can still be modified
  425. daniel That's what experimental xeps are for
  426. lorddavidiii has left
  427. genofire has left
  428. rion has left
  429. rion has joined
  430. oli has joined
  431. oli has joined
  432. UsL has joined
  433. pep. has joined
  434. oli done. i just disabled ImStyleParser. now i can write underlines without the italics. make the _usenet_ great again.
  435. vanitasvitae has left
  436. ralphm jonas’: haha
  437. marc_ has left
  438. !xsf_martin has joined
  439. alexis has left
  440. alexis has joined
  441. vanitasvitae has left
  442. vanitasvitae has joined
  443. alexis has left
  444. alexis has joined
  445. vanitasvitae has left
  446. vanitasvitae has joined
  447. !xsf_martin has left
  448. oli has left
  449. oli has joined
  450. !xsf_martin has joined
  451. !xsf_martin has left
  452. oli has joined
  453. oli has joined
  454. !xsf_martin has joined
  455. daniel has left
  456. vanitasvitae has left
  457. vanitasvitae has joined
  458. lorddavidiii has joined
  459. marc has joined
  460. marc_ has joined
  461. daniel has left
  462. ThibG has left
  463. ThibG has joined
  464. 404.city has joined
  465. 404.city has left
  466. ThibG has left
  467. ThibG has joined
  468. lnj has joined
  469. Steve Kille has joined
  470. Kev has joined
  471. Kev has joined
  472. Steve Kille has joined
  473. Yagiza has joined
  474. oli has left
  475. oli has joined
  476. blabla has left
  477. blabla has joined
  478. marc_ has left
  479. alexis has joined
  480. waqas has left
  481. waqas has joined
  482. ta > done. i just disabled ImStyleParser. now i can write underlines without the italics. make the _usenet_ great again. Actually i'd like to see that in expert preferencies
  483. mimi89999 has left
  484. mimi89999 has joined
  485. marc has left
  486. marc has joined
  487. waqas has left
  488. lovetox has joined
  489. lovetox has left
  490. lovetox has joined
  491. winfried has joined
  492. winfried has joined
  493. oli switching to propet old-school style?
  494. Jeremy has left
  495. Holger has left
  496. 404.city has joined
  497. ThibG has joined
  498. ThibG has joined
  499. marc has left
  500. marc has joined
  501. 404.city has left
  502. winfried has joined
  503. winfried has joined
  504. ThibG has left
  505. ThibG has joined
  506. genofire has joined
  507. marc_ has joined
  508. winfried has joined
  509. winfried has joined
  510. lskdjf has joined
  511. oli has joined
  512. oli has joined
  513. alexis has left
  514. MattJ has joined
  515. Tobias has joined
  516. krauq has joined
  517. krauq has joined
  518. Tobias has joined
  519. mimi89999 has left
  520. mimi89999 has joined
  521. genofire has left
  522. genofire has joined
  523. lskdjf has left
  524. lskdjf has joined
  525. Wiktor has joined
  526. lorddavidiii has left
  527. alexis has joined
  528. alexis has left
  529. alexis has joined
  530. lnj has left
  531. marc has left
  532. marc has joined
  533. genofire has left
  534. genofire has joined
  535. alexis has left
  536. alexis has joined
  537. daniel has left
  538. daniel has joined
  539. tux has joined
  540. frainz has left
  541. frainz has joined
  542. alexis has left
  543. alexis has joined
  544. daniel has left
  545. daniel has joined
  546. ralphm has joined
  547. daniel has left
  548. daniel has joined
  549. daniel has left
  550. daniel has joined
  551. daniel has left
  552. daniel has joined
  553. oli has joined
  554. genofire has left
  555. Marc Laporte has joined
  556. l has left
  557. l has joined
  558. Marc Laporte has left
  559. mimi89999 has joined
  560. !xsf_martin has left
  561. moparisthebest has joined
  562. UsL has left
  563. genofire has left
  564. alexis has left
  565. lovetox has left
  566. genofire has left
  567. lovetox has joined
  568. APach has left
  569. igoose has left
  570. APach has joined
  571. genofire has left
  572. Tobias has joined
  573. Tobias has joined
  574. 404.city has joined
  575. igoose has joined
  576. dos has left
  577. ThibG has left
  578. ThibG has joined
  579. !xsf_martin has joined
  580. Tobias has joined
  581. Tobias has joined
  582. daniel has left
  583. ThibG has left
  584. ThibG has joined
  585. Alex has joined
  586. lorddavidiii has left
  587. lorddavidiii has joined
  588. marc has left
  589. marc has joined
  590. lorddavidiii has left
  591. ThibG has left
  592. ThibG has joined
  593. lorddavidiii has joined
  594. oli has joined
  595. winfried has joined
  596. winfried has joined
  597. winfried has left
  598. winfried has joined
  599. lorddavidiii has left
  600. lorddavidiii has joined
  601. UsL has joined
  602. 404.city has left
  603. ThibG has left
  604. ThibG has joined
  605. Yagiza has left
  606. waqas has joined
  607. vanitasvitae has left
  608. vanitasvitae has joined
  609. lorddavidiii has left
  610. vanitasvitae has left
  611. vanitasvitae has joined
  612. vanitasvitae has left
  613. vanitasvitae has joined
  614. vanitasvitae https://upload.jabberhead.tk:5443/f0a454a3b03d017a262dfcfef56c2235742e325d/EweL3J5ZnfVQjrwbMfBuVaKojAwCnCtP2ZS0BG6v/0pgTCrRQSVusm4QBS9oICg.jpg
  615. vanitasvitae When you just want to game a little bit...
  616. lorddavidiii has joined
  617. lorddavidiii has left
  618. lorddavidiii has joined
  619. lnj has joined
  620. ralphm ⚔️
  621. ta has left
  622. edhelas has left
  623. edhelas has joined
  624. Holger has left
  625. alexis has joined
  626. Holger has joined
  627. Holger has joined
  628. rion has left
  629. Holger has left
  630. Holger has joined
  631. lnj has left
  632. Zash has left
  633. lnj has joined
  634. alexde Hope it got a good multiplayer: https://repl.it/site/blog/multi ...
  635. !xsf_martin has left
  636. rion has left
  637. krauq has joined
  638. vanitasvitae has left
  639. vanitasvitae has joined
  640. waqas has left
  641. edhelas has left
  642. Syndace has left
  643. Syndace has joined
  644. marc has left
  645. marc has joined
  646. krauq has joined
  647. vanitasvitae has left
  648. vanitasvitae has joined
  649. edhelas has left
  650. pep. has joined
  651. goffi has joined
  652. edhelas has left
  653. l has left
  654. l has joined
  655. waqas has joined
  656. marc_ has left
  657. Alex has left
  658. mightyBroccoli has left
  659. mightyBroccoli has joined
  660. edhelas has left
  661. lnj has left
  662. thorsten has joined
  663. vanitasvitae has left
  664. vanitasvitae has joined
  665. lnj has joined
  666. ta has left
  667. thorsten has joined
  668. alexde has left
  669. thorsten has joined
  670. thorsten has left
  671. thorsten has joined
  672. oli has joined
  673. oli has joined
  674. genofire has left
  675. Tobias has joined
  676. Tobias has joined
  677. krauq has joined
  678. krauq has joined
  679. oli has left
  680. oli has joined
  681. lskdjf has joined
  682. lskdjf has joined
  683. dos has left
  684. MattJ has joined
  685. lorddavidiii has left
  686. l has left
  687. l has joined