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


  67. Yagiza

    jonas’, are you Jonas Schäfer?

  68. Yagiza

    Is it possible to adopt a deferred XEP?

  69. ralphm


  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


  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


  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


  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


  225. ralphm


  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


  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’


  319. oli

    lets just use plaintext.

  320. jonas’


  321. jonas’

    what did I miss here?

  322. oli

    gender gap doesnt work

  323. oli


  324. oli


  325. Maranda has joined

  326. oli


  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


  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


  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