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


  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


  260. dwd

    Kev, You'd also have to deal with people randomly slipping in additional attrbutes.

  261. Kev


  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’


  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.


  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


  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


  344. pep.

    Also it's funny that whitespace handling can be changed at the CSS layer

  345. pep.


  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


  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.


  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.


  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.


  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


  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


  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.


  526. !XSF_Martin


  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.


  543. larma

    nbsp under typical definition is a whitespace

  544. pep.


  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


  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.


  623. pep.


  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.


  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


  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