XSF Discussion - 2020-02-14


  1. Dele Olajide has left
  2. Dele Olajide has joined
  3. debacle has left
  4. adiaholic has left
  5. Zash has left
  6. Dele Olajide has left
  7. Zash has joined
  8. Shell has left
  9. Wojtek has left
  10. arc has joined
  11. moparisthebest has joined
  12. moparisthebest Yea I saw that too, though previously I heard it was dead in the water due to middleboxes, so I wonder if anything changed there
  13. andy has left
  14. paul has left
  15. pdurbin has joined
  16. karoshi has left
  17. arc has left
  18. arc has joined
  19. pdurbin has left
  20. rion has left
  21. rion has joined
  22. arc has left
  23. arc has joined
  24. arc has left
  25. arc has joined
  26. arc has left
  27. arc has joined
  28. arc has left
  29. arc has joined
  30. arc has left
  31. arc has joined
  32. aj has joined
  33. aj has left
  34. Douglas Terabyte has left
  35. Douglas Terabyte has joined
  36. neshtaxmpp has left
  37. neshtaxmpp has joined
  38. Yagiza has joined
  39. Nekit has joined
  40. pdurbin has joined
  41. arc has left
  42. arc has joined
  43. pdurbin has left
  44. mukt2 has joined
  45. waqas has joined
  46. larma has left
  47. lskdjf has left
  48. larma has joined
  49. pdurbin has joined
  50. arc has left
  51. arc has joined
  52. mukt2 has left
  53. mukt2 has joined
  54. andy has joined
  55. lorddavidiii has joined
  56. edhelas has left
  57. mukt2 has left
  58. mukt2 has joined
  59. pdurbin has left
  60. strypey has joined
  61. adiaholic has joined
  62. pdurbin has joined
  63. mukt2 has left
  64. paul has joined
  65. mukt2 has joined
  66. !XSF_Martin has left
  67. debxwoody has joined
  68. !XSF_Martin has joined
  69. edhelas has joined
  70. arc has left
  71. arc has joined
  72. strypey has left
  73. wurstsalat has left
  74. wurstsalat has joined
  75. arc has left
  76. arc has joined
  77. karoshi has joined
  78. lorddavidiii has left
  79. lorddavidiii has joined
  80. lorddavidiii has left
  81. lorddavidiii has joined
  82. lorddavidiii has left
  83. lorddavidiii has joined
  84. pdurbin has left
  85. arc has left
  86. arc has joined
  87. debxwoody has left
  88. arc has left
  89. arc has joined
  90. arc has left
  91. debacle has joined
  92. Tobias has joined
  93. adiaholic has left
  94. mimi89999 has left
  95. mathijs has left
  96. mathijs has joined
  97. strypey has joined
  98. serge90 has left
  99. eevvoor has joined
  100. mimi89999 has joined
  101. serge90 has joined
  102. strypey has left
  103. strypey has joined
  104. mathijs has left
  105. flow moparisthebest, what if you want to resumse a connection initially established via quic on a connection using websockets as transport binding?
  106. flow moparisthebest, what if you want to resume a connection initially established via quic on a connection using websockets as transport binding?
  107. romeo has joined
  108. david has left
  109. mathijs has joined
  110. flow jonas’, "via stream feature + attribute on <enable/> as negotiation" →
  111. david has joined
  112. flow why the attribute? what's its value?
  113. Marc has left
  114. jonas’ flow, the client needs to tell the server that it supports alternative transports, too
  115. mukt2 has left
  116. jonas’ it could be "supported-transports='...'" or "i-support-quic='true'"
  117. goffi has joined
  118. goffi has left
  119. goffi has joined
  120. goffi has left
  121. Steve Kille has left
  122. Dele Olajide has joined
  123. Marc has joined
  124. Dele Olajide has left
  125. Dele Olajide has joined
  126. Steve Kille has joined
  127. !XSF_Martin has left
  128. mathijs has left
  129. mathijs has joined
  130. !XSF_Martin has joined
  131. mathijs has left
  132. mathijs has joined
  133. mukt2 has joined
  134. Douglas Terabyte has left
  135. strypey has left
  136. strypey has joined
  137. j.r has left
  138. j.r has joined
  139. mukt2 has left
  140. mukt2 has joined
  141. pdurbin has joined
  142. debxwoody has joined
  143. pdurbin has left
  144. debacle has left
  145. j.r has left
  146. j.r has joined
  147. j.r has left
  148. j.r has joined
  149. flow jonas’, why does the client need to tell the server that it supports alternative transports too?
  150. mukt2 has left
  151. aj has joined
  152. Dele Olajide has left
  153. jonas’ flow, so that the server can pick a proper reconnect address out of multiple options
  154. flow jonas’, ok, but I still think we can s/need/should/
  155. Ge0rG we don't have enough handshakes yet.
  156. flow Ge0rG, I don't think there is an additional handshake involved
  157. j.r has left
  158. j.r has joined
  159. mukt2 has joined
  160. j.r has left
  161. jonas’ flow, if you say so. I also think that there’s little point in discussing the details right now
  162. j.r has joined
  163. mukt2 has left
  164. flow Not sure which time would be better to discuss matters of xep198, especially since there is a CFE for xep198 out
  165. mukt2 has joined
  166. debxwoody has left
  167. mukt2 has left
  168. mukt2 has joined
  169. jonas’ it’s not about '198
  170. jonas’ it’s about future extensions
  171. Ge0rG maybe you should move this to the ML
  172. Ge0rG it's CFE after all
  173. Zash Is this experience? Seems like speculation about future things
  174. Ge0rG Do we have a formal Call for Speculation? I'd love that.
  175. dwd Experiential part is that people do use '198 resumption across different transports.
  176. debacle has joined
  177. Douglas Terabyte has joined
  178. debxwoody has joined
  179. david has left
  180. lorddavidiii has left
  181. david has joined
  182. lorddavidiii has joined
  183. aj has left
  184. debxwoody has left
  185. Dele (Mobile) has joined
  186. flow well the question is if those future extensions require adjustments to xep198, so I think it touches at least xep198 and its CFE, especially since its the step before xep198 becomes final
  187. flow Ge0rG, I think I posted everything I said here also to the ML. Please correct me if I'm wrong
  188. mukt2 has left
  189. mukt2 has joined
  190. david has left
  191. david has joined
  192. mukt2 has left
  193. jubalh has left
  194. jubalh has joined
  195. jubalh has left
  196. jubalh has joined
  197. jubalh has left
  198. jubalh has joined
  199. jubalh has left
  200. strypey has left
  201. jubalh has joined
  202. mukt2 has joined
  203. jonas’ flow, my rough draft of how such an extension could negotiate features was meant to show that it’s possible *without* having to modify '198
  204. jonas’ the details on whether a step of that is necessary do not matter; it is meant to show that a new feature can be introduced in such a way that both parties are sure about whether the other side supports it.
  205. eevvoor has left
  206. mukt2 has left
  207. david has left
  208. david has joined
  209. mukt2 has joined
  210. david has left
  211. david has joined
  212. pdurbin has joined
  213. mukt2 has left
  214. mukt2 has joined
  215. lorddavidiii has left
  216. lorddavidiii has joined
  217. Kev Can anyone think of anything that would break if a server was going to Unicode NFC-ify everything that goes through it?
  218. mukt2 has left
  219. lorddavidiii has left
  220. mathijs has left
  221. mathijs has joined
  222. flow Kev, xep426
  223. flow for certain values of "would break"
  224. mathijs has left
  225. mathijs has joined
  226. Kev Ta.
  227. lorddavidiii has joined
  228. waqas has left
  229. dwd Kev, Everything? Yeah, anything relying on character counting. You're NFC rather than NFKC, correct?
  230. lskdjf has joined
  231. Kev NFC is what I'm currently having a conversation about.
  232. Kev NFKC is the lossy one, I think?
  233. dwd NFC is more stable between unicode versions, so should be OK. Anything that relies on digital signatures will/might break too.
  234. dwd NFKC is Kompatibility, to ™ -> TM
  235. dwd NFKC is Kompatibility, so ™ -> TM
  236. lorddavidiii has left
  237. dwd But mostly, I'd have to ask why you'd want to. NFC is quite expensive, after all, I wouldn't want to normalize everything if I didn't have to.
  238. Kev Covert Channels.
  239. mukt2 has joined
  240. lorddavidiii has joined
  241. dwd Side channel attacks based on composition? I suspect that word choice would be far simpler, but I suppose it's worth closing.
  242. pdurbin has left
  243. lorddavidiii has left
  244. Kev Yes, it feels to me that it's closing a window when the door's open.
  245. Ge0rG With the dozens of different whitespace characters, you can't have that anyway.
  246. Max has left
  247. lorddavidiii has joined
  248. Kev Whitespace is normalised in canonical XML isn't it?
  249. Max has joined
  250. Max has left
  251. Max has joined
  252. Max has left
  253. Max has joined
  254. dwd Kev, Oh, if you're canonicalising XML too, that might be fun. And no, whitespace is not canonicalized, except outside the document.
  255. dwd Kev, Excepting line endings.
  256. Kev <this is= 'though'/>
  257. Kev Depending how you define 'outside the document'.
  258. dwd Kev, Yes, inside start and end elements it's normalised. But in any text it isn't.
  259. Kev Right.
  260. dwd Kev, You'd also have to deal with people randomly slipping in additional attrbutes.
  261. Kev Quite.
  262. pep. dwd, "in any text"? with xml:space="preserve"?
  263. goffi has joined
  264. dwd pep., I think that's the case by default, isn't it? I see, though, that whitespace is normalized in attribute values.
  265. jonas’ I’d very much like not to set a precedent for a server messing with data
  266. Zash All whitespace in attributes seems to turn into 0x20
  267. david has left
  268. mukt2 has left
  269. lorddavidiii has left
  270. david has joined
  271. lorddavidiii has joined
  272. dwd jonas’, That precedent is already set to some degree - lots of cases of linking high security networks with lower security networks where data is heavily futzed about. But I agree I wouldn't want to see this normalization behaviour normalized.
  273. Marc has left
  274. Marc has joined
  275. mukt2 has joined
  276. jonas’ indeed
  277. lorddavidiii has left
  278. SubPub has joined
  279. lorddavidiii has joined
  280. Shell has joined
  281. lorddavidiii has left
  282. mukt2 has left
  283. mukt2 has joined
  284. lorddavidiii has joined
  285. larma has left
  286. Dele (Mobile) has left
  287. Dele (Mobile) has joined
  288. lorddavidiii has left
  289. lorddavidiii has joined
  290. lorddavidiii has left
  291. Shell has left
  292. Shell has joined
  293. lorddavidiii has joined
  294. larma has joined
  295. LNJ has joined
  296. Shell has left
  297. Shell has joined
  298. pep. dwd, I'm curious if XMPP defines anything re whitespace actually. I'm reading §2.10 White Space Handling in XML 1.0 and it says "In valid documents, this attribute, like any other, MUST be declared if it is used."
  299. pep. https://www.w3.org/TR/REC-xml/#sec-white-space
  300. flow pep., i'd assume that xmpp operates with xml:space='default'
  301. pep. Is it defined what default means
  302. pep. somewhere in XMPP
  303. flow pep., ha, right XML says it is then applcation defined and we don't do that
  304. flow at least to my knowledge
  305. flow so anything goes?
  306. pep. ¯\_(ツ)_/¯
  307. flow I wouldn't be surprised if most XMPP implementations preserve whitespace
  308. flow besides some doing a trim() on <body/> (dino IIRC)
  309. pep. I think they do, I sometimes see pretty-printed XML in my client logs
  310. krauq has left
  311. krauq has joined
  312. larma flow, yes we do trim() on text elements, but that was only because some implementation would pretty print by adding newlines at the beginning/end of text elements...
  313. pep. fix the sending entities rather than trimming? :/
  314. flow larma, i have a dino user which reports that dino does not show whitespace only messages. Is that correct?
  315. larma probably
  316. flow which lead to the funny situation that the whitespace sending person would send an "sorry for that" message afterwards, which confused the dino user because he didn't knew for what his contact was sorry for ;)
  317. flow not saying that dino's behavior is wrong, just telling the story…
  318. larma pep., well it's funny that pretty printed XML is different to non pretty printed XML in XMPP.
  319. flow larma, different how?
  320. larma <body>Test Test2</body> usually is pretty printed to <body> Test Test2 </body>
  321. flow ahh, that implementation would add newlines within the textual content of body
  322. flow larma, which implementation was/is that?
  323. pep. larma, ask the sending entity to fix it rather :/
  324. pep. It's their fault not yours. And trimming on reception is only going to harm your users
  325. flow i'd definetly describe that as broken, as one can argue that XMPPs xml:space="default" is preserve
  326. flow pep., I am not sure how much harm it causes (besides the story I told)
  327. larma Also some XML implementations also (at least have an option to) a) consider all whitespaces the same and b) merge multiple consecutive whitespaces in a single one
  328. pep. I find both a) and b) in XMPP as crap as the trimming you describe now :x
  329. flow larma, i am still missing the part where we publicly shame that sending implementation ;)
  330. pep. I'd say the behaviour is always preserve in text nodes
  331. larma pep., both a) and b) would work everywhere in XMPP except for the body.
  332. pep. larma, or anywhere that defines containing text
  333. larma pep., well I don't know too many examples but I remember that it worked for some
  334. pep. xhtml-im. possibly reactions? (when are we going to be able to send more than one grapheme cluster? :p)
  335. larma I *hope* XHTML-IM does the same whitespace handling as XHTML, which is the one described above IIRC
  336. pep. But if the XML library used in the XMPP client doesn't..
  337. larma Yeah, funny things happen there.
  338. larma I am not aware of any HTML renderer printing " " as two spaces except of inside <pre> or <code> elements
  339. pdurbin has joined
  340. mathijs has left
  341. mathijs has joined
  342. pep. XHTML defines xml:space="default" as both your a) and b) right? and code and pre are xml:space="preserve" (or only pre?)
  343. larma probably
  344. pep. Also it's funny that whitespace handling can be changed at the CSS layer
  345. pep. unrelatedly
  346. larma If mixed content is illegal in XMPP and whitespace only textnodes should not be ignored, don't we get illegal XMPP XML as soon as you pretty-print?
  347. pep. I guess we do :x
  348. larma maybe it's good that we haven't clarified whitespace handling too much in XMPP
  349. pep. somebody(tm) should open an errata I guess
  350. larma can we maybe go with xml:space="preserve" on <body> and basically ignore whitespace outside?
  351. larma Even if it's not what Dino does, it seems the most sane to me
  352. pep. no we can't. We should recommend XEP authors to take tht into account
  353. pep. and properly define what is xml:space="preserve" and what isn't
  354. pep. if it's not the default, that currently isn't defined anywhere
  355. larma pep., what should they take into account? If they don't account for it default applied, so we just need to make default to ignore whitespaces pretty much
  356. flow larma, why not simply assume preserve everywhere and say that sending pretty printed XML e.g. <message>\n<bar/></message> is invalid in XMPP because it is mixed content?
  357. pep. flow, yeah that's be a good first step I think
  358. larma flow, you want to break backwards compatibility?
  359. larma also, why don't we like pretty printed?
  360. flow maybe even with 'default', <message>\n<bar/></message> would become <message>U+0020<bar/></message> and still be invalid
  361. flow larma, I don't think I am breaking backwards compatibility
  362. pep. flow, no, "default" not being defined in XMPP there's no normalization happening
  363. flow (besides that, I usually try to avoid breaking backwards compatibility)
  364. larma I am used to typing XML directly in my openssl s_client and it helps a lot that I can put newlines arbitrarly except for body
  365. pep. larma, it's already the case no? That mixed text/tag is not valid
  366. Shell has left
  367. Shell has joined
  368. flow I see, but the client could also "normalize" your pretty printed input before its put on the wire
  369. larma pep., yes and no: text might be but whitespaces are ignored
  370. pep. Do you know where that's defined?
  371. larma flow, so how do I put malformed XML on the wire then? 😀
  372. larma pep., maybe nowhere
  373. flow larma, hehe, I'am sure you figure out a way
  374. larma pep., I just tried: `<message to="jabber@larma.de">Bla<body>Bla2</body></message>` was forwarded by prosody and rendered as "Bla2" on Conversations and Dino
  375. pep. :(
  376. goffi has left
  377. pdurbin has left
  378. throw-me-out has joined
  379. throw-me-out This message is invalid.
  380. larma Did anyone *not* see "This message is invalid." ? at least nobody seemed to have send an error and the server forwarded it as is (just added a stanza-id)
  381. pep. poezio displayed it
  382. flow I am not surprised that the "no mixed content" rule is not enforced
  383. larma flow, well if it's not enforced, enforcing it is likely to break compatibility...
  384. flow most implementations will simply ignore the textual content
  385. edhelas has left
  386. flow larma, I think I have a different definition of compatibility than you
  387. larma I just checked RFC, and mixed content is allowed
  388. larma It's just not allowed inside <show> <status> <priority> <body> <subject> and <thread>
  389. flow ahh
  390. pep. 6120 §11.7 "Except where explicitly disallowed (e.g., during TLS negotiation and SASL negotiation), either entity MAY send whitespace as separators between XML stanzas or between any other first-level elements sent over the stream. One common use for sending such whitespace is explained under Section 4.4."
  391. pep. 0071 version 0.19 changelog: "Per list discussion, removed recommendation to preserve whitespace in XHTML bodies (instead, use of <br/> and non-breaking spaces is recommended)"
  392. pep. whitespace handling in XMPP is :x
  393. sonny has left
  394. pep. #FightForWhitespaceRights
  395. edhelas has joined
  396. sonny has joined
  397. larma I think the RFC was not considering details of whitespace handling in body. A client that replaces new lines with spaces in body would probably be RFC compliant.
  398. larma All examples in RFC are pretty printed but no note that those string won't actually be valid. https://www.rfc-editor.org/rfc/rfc6121.html#page-74 is an example where pretty printing adds new lines at begin and end of text content
  399. larma So the client that did cause Dino to add this trimming was actually RFC compliant
  400. larma and it is just not properly possible to send a message that starts with a new line
  401. pep. Why not?
  402. pep. This has 3 newlines at the beginning
  403. larma because the newline could be added as part of pretty printing
  404. larma which seems to be fine according to RFC
  405. pep. one newlines here before, and one after
  406. sonny has left
  407. sonny has joined
  408. pep. #FightForWhitespaceRights
  409. larma This message has some spaces
  410. larma (funnily enough Dino does not do trim before sending, so my message is displayed differently on sender and receiver)
  411. mathijs has left
  412. larma Conversations also does the same trimming as Dino
  413. pep. https://ppjet.bouah.net/whitespace.png
  414. throw-me-out This message is pretty printed RFC style and thus should probably be displayed without leading or trailing newlines or whitespaces.
  415. !XSF_Martin Hmm
  416. !XSF_Martin Ha, conversarions really trimmed the newlines
  417. !XSF_Martin Ha, conversations really trimmed the newlines
  418. mathijs has joined
  419. larma So status is: - Servers do transfer XML verbatim including unnecessary whitespaces between nodes. They just add elements before the closing </message> if necessary. - Some clients ignore leading and trailing whitespace of all kinds in body (aka trim()) when others don't
  420. Douglas Terabyte has left
  421. Holger ejabberd won't include whitespace between nodes FWIW. But I ignored the backlog, probably not relevant :-)
  422. Douglas Terabyte has joined
  423. mukt2 has left
  424. Holger s/include/preserve/
  425. larma Holger, between nodes or between stanzas?
  426. Guus I'm actually not sure what Openfire does.
  427. Holger larma: Between XML nodes.
  428. sonny has left
  429. Guus I'm firmly on team #trimWhiteSpace in the presentation layer though. But we've discussed that to death already.
  430. Holger larma: All incoming traffic is decoded into internal structs and it won't include unnecessary whitespace when encoded for transmission.
  431. larma Holger, but not inside XML nodes? <body> </body> will go verbatim whereas <test> <test2 /></test> will not?
  432. larma "unnecessary whitespace" I don't think that's defined in the RFC 😀
  433. sonny has joined
  434. mukt2 has joined
  435. Guus I don't expect trimming text in text-nodes is allowed, is it?
  436. Guus and if I recall correctly, XMPP does not allow for mixed nodes (what's the correct name again?) where you mix text and elements in one node.
  437. larma Guus, we just checked, it is allowed in general just not inside certain text only elements like <body>
  438. Holger larma: Well I just had the `<test/> <test2/>` case in mind, which you probably don't care about. In your example "it depends".
  439. Guus larma: you're only talking about whitespace though, correct? I ment: <outer>some text<inner/></outer>
  440. larma Guus, no I was talking about everything
  441. Guus I was under the impression that something like <outer>some text<inner/></outer> is invalid in XMPP - but I might be wrong.
  442. larma There is no general rule if RFC 6120 and RFC 6121 has specific rules to forbid mixed content inside certain elements
  443. larma Also mixed content is allowed in XHTML-IM which is in XMPP 😉
  444. larma I think the consensus is that we don't like mixed content, but it's not disallowed by RFC
  445. romeo has left
  446. Guus meh. I'm looking forward to your bugreports. 😃
  447. Daniel has left
  448. Daniel has joined
  449. eevvoor has joined
  450. Daniel has left
  451. Daniel has joined
  452. SubPub has left
  453. eevvoor has left
  454. Daniel has left
  455. Daniel has joined
  456. mathijs has left
  457. mathijs has joined
  458. Daniel has left
  459. Daniel has joined
  460. Daniel has left
  461. Daniel has joined
  462. Daniel has left
  463. Daniel has joined
  464. eevvoor has joined
  465. Daniel has left
  466. Daniel has joined
  467. mathijs has left
  468. mathijs has joined
  469. LNJ has left
  470. mathijs has left
  471. mathijs has joined
  472. mukt2 has left
  473. mukt2 has joined
  474. SubPub has joined
  475. Shell has left
  476. Shell has joined
  477. throw-me-out has left
  478. pep. As I see some people don't care about whitespace and treat it horribly (#FightForWhitespacerights !), would you respect xml:space="preserve" btw? If I say on body "don't touch plz", would you stop trimming etc.?
  479. pep. As I see some people don't care about whitespace and treat it horribly (#FightForWhitespaceRights !), would you respect xml:space="preserve" btw? If I say on body "don't touch plz", would you stop trimming etc.?
  480. pep. Or because it's the assumed default would you continue not caring
  481. romeo has joined
  482. larma pep., you mean, you'd like to have <body xml:space="preserve">\nTest</body> have an empty line displayed before the message? What is the use case for this?
  483. mukt2 has left
  484. pep. So that you respect my whitespace
  485. pep. Whatever usecase
  486. larma I am respecting the whitespace, I am just not wasting my users screenspace
  487. pep. You're not respecting whitespace if you trim it
  488. pep. power users would probably appreciate that, if only them
  489. pep. To me this is about the same fight as "don't interpret body if I don't say so"
  490. larma By now I honestly think that newlines were completely out of scope in the RFC i.e. it might be that it was not intended what we do nowadays with newlines and that you instead just send one message for each line.
  491. larma pep., an empty line can just be invisible. This has nothing to do with me respecting whitespace or not, this might even be a font renderers decision (depending on what font renderer you use). Display and transport are generally independent from each other.
  492. larma For example when I have a line with an emoji in it 👍️ this line will take more vertical space then a line without an emoji. consequently a line without any characters in it could be rendered without needing any vertical space
  493. larma Also some fonts render consecutive spaces different to single spaces.
  494. pep. That's an issue with your font renderer then
  495. pdurbin has joined
  496. pep. It's not like I was asking you to display protocol-things verbatim to the user, like say: Hey somebody commented on your post: ""
  497. pep. I'Ve seen that in a client not so long ago for subscription requests when there's no comment
  498. pep. Just asking to display what's intended by the sending entity
  499. larma preserving whitespace might be simple for terminal clients with monospace fonts (as if monospace fonts were still a thing), it is not for the general case
  500. larma pep., this is strictly impossible because the sending entity does not know my client/font etc
  501. pep. So we might as well give up and close shop? :)
  502. mukt2 has joined
  503. pep. Or do all the weird things we're inflicting onto body?
  504. pep. Because it's not possible to do it right anyway
  505. larma What are you expecting this to look like: a b
  506. pep. dunno, characters and a bunch of spaces
  507. lovetox has joined
  508. larma there is a tab character before the a, I might be expecting it to be displayed as 4 or 8 spaces or displayed as \t
  509. pep. If you use \t you're not expecting it to be displayed as any fixed number or chars no (programmers' myths)
  510. pep. (that's the whole point of \t)
  511. larma at the beginning of a line I am
  512. pep. The sender doesn't decide of the number of chars that \t will be replaced with, is what I mean
  513. pdurbin has left
  514. larma Yeah sure, but I might expect you to display it like that
  515. larma just because the information is not transferred doesn't say anything about user expectations
  516. pep. I get your point, but you've got wrong expectations here
  517. larma We literally have a GitHub issue with someone complaining that the ASCII art send from another client doesn't render properly, so users have strange expectations
  518. pep. Everybody should use monospace \o/
  519. larma Being able to send empty lines is probably the least relevant expectation
  520. larma pep., monospace is a lie
  521. pep. Do you want a screenshot of my desktop just now? :p
  522. Daniel has left
  523. Daniel has joined
  524. larma WWW W👍️W WWW My monospace font doesn't monospace this
  525. pep. hmm
  526. !XSF_Martin https://files.mdosch.de:5281/upload/zHk1fWzzbI53ZVxn/2020-02-14-160041_scrot.png
  527. !XSF_Martin Haven't measured it, but seems quite monospace to me.
  528. larma Those were three lines with each three characters in it
  529. !XSF_Martin larma: I wouldn't expect emoji to be monospace
  530. larma !XSF_Martin, so how many spaces would you expect it to be?
  531. !XSF_Martin It's little images and making it the size of a character would render them toooooo small.
  532. larma So they shall be arbitrary length? Isn't that completely contradictory to the purpose of monospace fonts?
  533. !XSF_Martin larma: I, as a user, would not expect monospace to work with emoji. I'd rather be annoyed if you display emoji as small as one character.
  534. !XSF_Martin larma: Although emoji are included in fonts I don't see them as *text*
  535. !XSF_Martin I expect this to be same width, but not if I embedd emoji, images, stickers or whatelse the kids do today. ASD FGH JKL öäü asd fgh jkl
  536. lovetox has left
  537. lovetox has joined
  538. pep. larma, would you also trim nbsp btw?
  539. pep. Maybe I should start replacing all spaces in front and at the end of lines by nbsp :)
  540. larma !XSF_Martin, How about — this is the em dash, which by definition should be 1em width
  541. larma pep., we trim whitespaces
  542. pep. Any?
  543. larma nbsp under typical definition is a whitespace
  544. pep. meh
  545. larma I haven't tried all of them
  546. Daniel has left
  547. pep. There is a line with full-width spaces above.
  548. larma Yeah, nothing visible on any of me devices
  549. !XSF_Martin larma: What about it? Seems to fit in well here. ——— ÄÖÜ @»« ł€¶ ŧ←↓ →ø[ ]}\
  550. !XSF_Martin pep.: In profanity there's an empty line in your last message.
  551. edhelas https://nl.movim.eu/?node/pubsub.movim.eu/Movim/87633da7-3963-4923-aabc-54ac5f6ad1d8
  552. pep. !XSF_Martin, yes
  553. Daniel has joined
  554. larma !XSF_Martin, well it if has the same width as any other characters and your don't use a square font, you are rendering the em dash *wrong*. em dash is defined that it should be rendered with the width of 1em. 1em is the same length as the font's height
  555. pep. edhelas, nice :)
  556. larma We were talking about expectations, and I certainly expect a receiving client to follow the unicode rules for rendering the characters I send (or not support the character at all)
  557. !XSF_Martin > !XSF_Martin, well it if has the same width as any other characters and your don't use a square font, you are rendering the em dash *wrong*. em dash is defined that it should be rendered with the width of 1em. 1em is the same length as the font's height No idea if terminus is square, but looks like it's not. Height should be bigger than width.
  558. goffi has joined
  559. Max has left
  560. Max has joined
  561. larma That's what most monospace fonts do, that's why I came up with this example 😉
  562. !XSF_Martin Yeah, if you want to have your characters the same width you probably don't want the dash to stand out.
  563. larma well I didn't ask for you to render characers the same width, I asked you to render that specific character with 1em width, I don't care what width you are using for all other characters.
  564. larma Are you arguing that recipient's preference should override sender's preference?
  565. Shell has left
  566. Shell has joined
  567. !XSF_Martin Yes, I also wouldn't want to see red text on orange background only because the sender likes this theme on his client.
  568. !XSF_Martin That's why I choose a specific font and color scheme.
  569. !XSF_Martin It's the same reason I don't like people sending me HTML email without plaintext
  570. !XSF_Martin But for the record: I am only speaking as a user, I'm neither an XMPP developer nor affiliated with the XSF
  571. larma OK, so we agree it is perfectly fine that a client ignores incoming leading whitespaces, as this is a recipient's preference
  572. pep. So you'd also remove "a"s in a message as this is a recipient's preference?
  573. pep. if* this is
  574. !XSF_Martin larma: I talk about *styling* like character width, colors and so on. Not about removing content.
  575. larma A newline is not content
  576. larma Same applies to whitespace
  577. larma It is formatting
  578. Zash has left
  579. Zash has joined
  580. pep. larma, the day I send whitespace (language), it is content :)
  581. !XSF_Martin Hmm, I see it is hard where to draw the line.
  582. pep. larma, we both agree it's not a common use-case for dino's target
  583. larma Your client is rendering many whitespaces the same (because there are various whitespaces that define a length that will become the same when displayed monospace), so you should expect my client to change rendering of whitespaces as well
  584. !XSF_Martin But as pep. says, if you paste code snippets removing whitespaces might be bad. In case of common languages it might be cosmetics but in case of whitespace (language) it's removing your code.
  585. larma I have hard times imagining any valid use case for leading newlines
  586. larma !XSF_Martin: we are only talking about leading/trailing whitespace
  587. larma And I don't really consider whitespace (language) a valid use case...
  588. !XSF_Martin In this case I would be fine with it. But if you want to compile a general rule I'd go for "don't touch it" than "do whatever you want to"
  589. larma What is "it" that you don't want to touch? The bytes on the wire or how they are displayed?
  590. adiaholic has joined
  591. larma The problem is: the information about how to display things get lost on the wire, so clients have to do assumptions on how to display things.
  592. larma The problem is: the information about how to display things is lost on the wire, so clients have to do assumptions on how to display things.
  593. jonas’ larma, FWIW, I use leading newlines when I paste a block of lines so that they’re all indented the same
  594. mukt2 has left
  595. jonas’ many clients indent the first line more than subsequent lines (because the name is prefixed)
  596. lorddavidiii has left
  597. adiaholic has left
  598. larma Isn't that a perfect example for using monospace format blocks?
  599. larma Which start with a line containing ```
  600. Ge0rG but you don't want to actually display the ``` except when it's not a block delimiter, which you can't know because there is no meta-data
  601. lorddavidiii has joined
  602. larma Ge0rG: we can do the same with message markup xep if you don't want to display ``` ;)
  603. Dele Olajide has joined
  604. jonas’ or, y’know, XHTML-IM
  605. jonas’ minus the CSS crap
  606. Ge0rG everything is horrible
  607. lovetox has left
  608. larma Also dino does not indent the first line so this is a good example where it is again perfectly sensible for dino to strip the empty line ;)
  609. pep. poezio also doesn't indent the first line
  610. Ge0rG it indents all lines.
  611. lorddavidiii has left
  612. Ge0rG but the /code plugin fails on pasting tab-completed code because initial whitespace is stripped
  613. adiaholic has joined
  614. Ge0rG but the /code plugin fails on pasting tab-indented code because initial whitespace is stripped
  615. mukt2 has joined
  616. Ge0rG everything is horrible
  617. lovetox has joined
  618. lorddavidiii has joined
  619. larma pep., so you are wasting a line of screen space whenever jonas’ sends a block of lines. And you are complaining about Dino wasting too much screen space 😉
  620. pep. Even if jonas’ was abusing it we would be wasting less space than dino :p
  621. pep. Even if jonas’ were abusing it we would be wasting less space than dino :p
  622. pep. was*
  623. pep. english?.
  624. lorddavidiii has left
  625. dwd pep., "were", it's a subjunctive.
  626. pep. larma, current terminal size: 273x74
  627. pep. dwd, thanks
  628. dwd pep., But only foreign speakers would get it right. :-)
  629. pep. haha
  630. lorddavidiii has joined
  631. dwd pep., I suspect it properly takes an infinitive, as well, so "even if jonas’ were to abuse it".
  632. pep. right, that sounds better
  633. j.r has left
  634. Max has left
  635. Max has joined
  636. lorddavidiii has left
  637. lorddavidiii has joined
  638. Max has left
  639. Max has joined
  640. lorddavidiii has left
  641. lorddavidiii has joined
  642. lorddavidiii has left
  643. mukt2 has left
  644. lorddavidiii has joined
  645. Max has left
  646. Max has joined
  647. Max has left
  648. lorddavidiii has left
  649. Max has joined
  650. lorddavidiii has joined
  651. lorddavidiii has left
  652. Max has left
  653. mathijs has left
  654. lorddavidiii has joined
  655. Max has joined
  656. j.r has joined
  657. lorddavidiii has left
  658. lorddavidiii has joined
  659. mathijs has joined
  660. Max has left
  661. Shell has left
  662. Shell has joined
  663. Max has joined
  664. lorddavidiii has left
  665. Max has left
  666. lorddavidiii has joined
  667. Max has joined
  668. lorddavidiii has left
  669. Max has left
  670. Max has joined
  671. lorddavidiii has joined
  672. lorddavidiii has left
  673. Shell has left
  674. Shell has joined
  675. lorddavidiii has joined
  676. lorddavidiii has left
  677. mukt2 has joined
  678. lorddavidiii has joined
  679. lovetox has left
  680. calvin has joined
  681. lorddavidiii has left
  682. lorddavidiii has joined
  683. andrey.g has left
  684. Max has left
  685. Max has joined
  686. eevvoor has left
  687. lovetox has joined
  688. mathijs has left
  689. mathijs has joined
  690. lorddavidiii has left
  691. mathijs has left
  692. lorddavidiii has joined
  693. mathijs has joined
  694. pdurbin has joined
  695. lorddavidiii has left
  696. andy has left
  697. lorddavidiii has joined
  698. lorddavidiii has left
  699. mathijs has left
  700. mathijs has joined
  701. lorddavidiii has joined
  702. Steve Kille has left
  703. lorddavidiii has left
  704. pdurbin has left
  705. lorddavidiii has joined
  706. Steve Kille has joined
  707. debacle has left
  708. j.r has left
  709. j.r has joined
  710. adiaholic has left
  711. Shell has left
  712. Shell has joined
  713. Shell has left
  714. Shell has joined
  715. mukt2 has left
  716. eevvoor has joined
  717. mukt2 has joined
  718. andrey.g has joined
  719. mathijs has left
  720. mathijs has joined
  721. mathijs has left
  722. mathijs has joined
  723. krauq has left
  724. andrey.g has left
  725. krauq has joined
  726. andrey.g has joined
  727. mathijs has left
  728. mathijs has joined
  729. mathijs has left
  730. mathijs has joined
  731. debacle has joined
  732. mathijs has left
  733. mathijs has joined
  734. eevvoor has left
  735. calvin has left
  736. lovetox has left
  737. andy has joined
  738. goffi has left
  739. mukt2 has left
  740. Max has left
  741. Max has joined
  742. mukt2 has joined
  743. pdurbin has joined
  744. goffi has joined
  745. lovetox has joined
  746. pdurbin has left
  747. Shell has left
  748. Shell has joined
  749. mukt2 has left
  750. eevvoor has joined
  751. mukt2 has joined
  752. Dele Olajide has left
  753. eevvoor has left
  754. romeo has left
  755. eevvoor has joined
  756. mukt2 has left
  757. moparisthebest anyone have a direct way to contact the Monal dev re: https://monal.im/blog/monal-4-3-is-coming-out-in-about-a-week-even-in-france/ ?
  758. moparisthebest long story short he's silently dropping all OMEMO compatibility with all other clients because he thinks he has to due to a crypto library constraint, when he can likely keep support with a bit of code, I've pinged him with an offer to help in the official muc yesterday but no response so far...
  759. lovetox moparisthebest, thats a bit misleading
  760. SubPub has left
  761. lovetox or not, he is breaking compat with all clients, but most clients will update their code soon to send 12 byte IV
  762. lovetox so that leaves older versions probably in stable distros
  763. moparisthebest right, so breaking compatibility with most existing clients for the next few years until all users update
  764. moparisthebest I suspect it'd be better for everyone involved if he simply kept compat with 16 byte IVs in the short term no?
  765. lovetox yes correct
  766. moparisthebest just requires a small algorithm to hash 16 bytes down to 12
  767. lovetox he said its not possible with apples GCM impl
  768. lovetox dont know if thats true
  769. lovetox yeah is monal not open source?
  770. lovetox you could just provide a MR
  771. LNJ has joined
  772. lovetox and while you are at it a problem is also chatsecure, which only accepts 16 byte IV
  773. moparisthebest well I volunteered to help but can't write Objective-C or compile/test/run iOS apps
  774. moparisthebest I can write what they need in C or Rust or something though
  775. lovetox true
  776. lovetox much overhead
  777. lovetox but i guess the offical muc is the best place to reach him
  778. moparisthebest yep to put in a MR I'd only need a macos machine for development, an iphone for testing, and $99/year for the privelege :P
  779. eevvoor has left
  780. LNJ has left
  781. LNJ has joined
  782. mukt2 has joined
  783. mathijs has left
  784. mathijs has joined
  785. LNJ has left
  786. LNJ has joined
  787. mathijs has left
  788. LNJ has left
  789. mathijs has joined
  790. LNJ has joined
  791. mukt2 has left
  792. Maranda has left
  793. Maranda has joined
  794. mathijs has left
  795. mathijs has joined
  796. Yagiza has left
  797. goffi has left
  798. Marc has left
  799. Marc has joined
  800. pdurbin has joined
  801. rion has left
  802. rion has joined
  803. LNJ has left
  804. LNJ has joined
  805. Shell has left
  806. Shell has joined
  807. pdurbin has left
  808. mukt2 has joined
  809. mathijs has left
  810. mathijs has joined
  811. mathijs has left
  812. mathijs has joined
  813. mukt2 has left
  814. lovetox has left
  815. LNJ has left
  816. Tobias has left
  817. lorddavidiii has left
  818. lorddavidiii has joined
  819. Shell has left
  820. Shell has joined
  821. lorddavidiii has left
  822. paul has left
  823. Maranda has left
  824. Maranda has joined
  825. Shell has left
  826. Shell has joined
  827. pdurbin has joined
  828. Shell has left
  829. Shell has joined
  830. pdurbin has left
  831. mukt2 has joined
  832. mukt2 has left
  833. arc has joined
  834. goffi has joined
  835. waqas has joined
  836. Neustradamus has left
  837. Neustradamus has joined
  838. strypey has joined
  839. Neustradamus has left
  840. Neustradamus has joined
  841. Shell has left
  842. matkor has left
  843. Neustradamus has left
  844. Neustradamus has joined
  845. goffi has left
  846. debacle has left
  847. strypey has left
  848. Shell has joined