XSF Discussion - 2020-02-14


  1. 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

  2. flow

    moparisthebest, what if you want to resumse a connection initially established via quic on a connection using websockets as transport binding?

  3. flow

    moparisthebest, what if you want to resume a connection initially established via quic on a connection using websockets as transport binding?

  4. flow

    jonas’, "via stream feature + attribute on <enable/> as negotiation" →

  5. flow

    why the attribute? what's its value?

  6. jonas’

    flow, the client needs to tell the server that it supports alternative transports, too

  7. jonas’

    it could be "supported-transports='...'" or "i-support-quic='true'"

  8. flow

    jonas’, why does the client need to tell the server that it supports alternative transports too?

  9. jonas’

    flow, so that the server can pick a proper reconnect address out of multiple options

  10. flow

    jonas’, ok, but I still think we can s/need/should/

  11. Ge0rG

    we don't have enough handshakes yet.

  12. flow

    Ge0rG, I don't think there is an additional handshake involved

  13. jonas’

    flow, if you say so. I also think that there’s little point in discussing the details right now

  14. flow

    Not sure which time would be better to discuss matters of xep198, especially since there is a CFE for xep198 out

  15. jonas’

    it’s not about '198

  16. jonas’

    it’s about future extensions

  17. Ge0rG

    maybe you should move this to the ML

  18. Ge0rG

    it's CFE after all

  19. Zash

    Is this experience? Seems like speculation about future things

  20. Ge0rG

    Do we have a formal Call for Speculation? I'd love that.

  21. dwd

    Experiential part is that people do use '198 resumption across different transports.

  22. 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

  23. flow

    Ge0rG, I think I posted everything I said here also to the ML. Please correct me if I'm wrong

  24. 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

  25. 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.

  26. Kev

    Can anyone think of anything that would break if a server was going to Unicode NFC-ify everything that goes through it?

  27. flow

    Kev, xep426

  28. flow

    for certain values of "would break"

  29. Kev

    Ta.

  30. dwd

    Kev, Everything? Yeah, anything relying on character counting. You're NFC rather than NFKC, correct?

  31. Kev

    NFC is what I'm currently having a conversation about.

  32. Kev

    NFKC is the lossy one, I think?

  33. dwd

    NFC is more stable between unicode versions, so should be OK. Anything that relies on digital signatures will/might break too.

  34. dwd

    NFKC is Kompatibility, to ™ -> TM

  35. dwd

    NFKC is Kompatibility, so ™ -> TM

  36. 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.

  37. Kev

    Covert Channels.

  38. dwd

    Side channel attacks based on composition? I suspect that word choice would be far simpler, but I suppose it's worth closing.

  39. Kev

    Yes, it feels to me that it's closing a window when the door's open.

  40. Ge0rG

    With the dozens of different whitespace characters, you can't have that anyway.

  41. Kev

    Whitespace is normalised in canonical XML isn't it?

  42. dwd

    Kev, Oh, if you're canonicalising XML too, that might be fun. And no, whitespace is not canonicalized, except outside the document.

  43. dwd

    Kev, Excepting line endings.

  44. Kev

    <this is= 'though'/>

  45. Kev

    Depending how you define 'outside the document'.

  46. dwd

    Kev, Yes, inside start and end elements it's normalised. But in any text it isn't.

  47. Kev

    Right.

  48. dwd

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

  49. Kev

    Quite.

  50. pep.

    dwd, "in any text"? with xml:space="preserve"?

  51. dwd

    pep., I think that's the case by default, isn't it? I see, though, that whitespace is normalized in attribute values.

  52. jonas’

    I’d very much like not to set a precedent for a server messing with data

  53. Zash

    All whitespace in attributes seems to turn into 0x20

  54. 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.

  55. jonas’

    indeed

  56. 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."

  57. pep.

    https://www.w3.org/TR/REC-xml/#sec-white-space

  58. flow

    pep., i'd assume that xmpp operates with xml:space='default'

  59. pep.

    Is it defined what default means

  60. pep.

    somewhere in XMPP

  61. flow

    pep., ha, right XML says it is then applcation defined and we don't do that

  62. flow

    at least to my knowledge

  63. flow

    so anything goes?

  64. pep.

    ¯\_(ツ)_/¯

  65. flow

    I wouldn't be surprised if most XMPP implementations preserve whitespace

  66. flow

    besides some doing a trim() on <body/> (dino IIRC)

  67. pep.

    I think they do, I sometimes see pretty-printed XML in my client logs

  68. 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...

  69. pep.

    fix the sending entities rather than trimming? :/

  70. flow

    larma, i have a dino user which reports that dino does not show whitespace only messages. Is that correct?

  71. larma

    probably

  72. 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 ;)

  73. flow

    not saying that dino's behavior is wrong, just telling the story…

  74. larma

    pep., well it's funny that pretty printed XML is different to non pretty printed XML in XMPP.

  75. flow

    larma, different how?

  76. larma

    <body>Test Test2</body> usually is pretty printed to <body> Test Test2 </body>

  77. flow

    ahh, that implementation would add newlines within the textual content of body

  78. flow

    larma, which implementation was/is that?

  79. pep.

    larma, ask the sending entity to fix it rather :/

  80. pep.

    It's their fault not yours. And trimming on reception is only going to harm your users

  81. flow

    i'd definetly describe that as broken, as one can argue that XMPPs xml:space="default" is preserve

  82. flow

    pep., I am not sure how much harm it causes (besides the story I told)

  83. 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

  84. pep.

    I find both a) and b) in XMPP as crap as the trimming you describe now :x

  85. flow

    larma, i am still missing the part where we publicly shame that sending implementation ;)

  86. pep.

    I'd say the behaviour is always preserve in text nodes

  87. larma

    pep., both a) and b) would work everywhere in XMPP except for the body.

  88. pep.

    larma, or anywhere that defines containing text

  89. larma

    pep., well I don't know too many examples but I remember that it worked for some

  90. pep.

    xhtml-im. possibly reactions? (when are we going to be able to send more than one grapheme cluster? :p)

  91. larma

    I *hope* XHTML-IM does the same whitespace handling as XHTML, which is the one described above IIRC

  92. pep.

    But if the XML library used in the XMPP client doesn't..

  93. larma

    Yeah, funny things happen there.

  94. larma

    I am not aware of any HTML renderer printing " " as two spaces except of inside <pre> or <code> elements

  95. pep.

    XHTML defines xml:space="default" as both your a) and b) right? and code and pre are xml:space="preserve" (or only pre?)

  96. larma

    probably

  97. pep.

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

  98. pep.

    unrelatedly

  99. 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?

  100. pep.

    I guess we do :x

  101. larma

    maybe it's good that we haven't clarified whitespace handling too much in XMPP

  102. pep.

    somebody(tm) should open an errata I guess

  103. larma

    can we maybe go with xml:space="preserve" on <body> and basically ignore whitespace outside?

  104. larma

    Even if it's not what Dino does, it seems the most sane to me

  105. pep.

    no we can't. We should recommend XEP authors to take tht into account

  106. pep.

    and properly define what is xml:space="preserve" and what isn't

  107. pep.

    if it's not the default, that currently isn't defined anywhere

  108. 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

  109. 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?

  110. pep.

    flow, yeah that's be a good first step I think

  111. larma

    flow, you want to break backwards compatibility?

  112. larma

    also, why don't we like pretty printed?

  113. flow

    maybe even with 'default', <message>\n<bar/></message> would become <message>U+0020<bar/></message> and still be invalid

  114. flow

    larma, I don't think I am breaking backwards compatibility

  115. pep.

    flow, no, "default" not being defined in XMPP there's no normalization happening

  116. flow

    (besides that, I usually try to avoid breaking backwards compatibility)

  117. 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

  118. pep.

    larma, it's already the case no? That mixed text/tag is not valid

  119. flow

    I see, but the client could also "normalize" your pretty printed input before its put on the wire

  120. larma

    pep., yes and no: text might be but whitespaces are ignored

  121. pep.

    Do you know where that's defined?

  122. larma

    flow, so how do I put malformed XML on the wire then? 😀

  123. larma

    pep., maybe nowhere

  124. flow

    larma, hehe, I'am sure you figure out a way

  125. 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

  126. pep.

    :(

  127. throw-me-out

    This message is invalid.

  128. 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)

  129. pep.

    poezio displayed it

  130. flow

    I am not surprised that the "no mixed content" rule is not enforced

  131. larma

    flow, well if it's not enforced, enforcing it is likely to break compatibility...

  132. flow

    most implementations will simply ignore the textual content

  133. flow

    larma, I think I have a different definition of compatibility than you

  134. larma

    I just checked RFC, and mixed content is allowed

  135. larma

    It's just not allowed inside <show> <status> <priority> <body> <subject> and <thread>

  136. flow

    ahh

  137. 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."

  138. 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)"

  139. pep.

    whitespace handling in XMPP is :x

  140. pep.

    #FightForWhitespaceRights

  141. 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.

  142. 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

  143. larma

    So the client that did cause Dino to add this trimming was actually RFC compliant

  144. larma

    and it is just not properly possible to send a message that starts with a new line

  145. pep.

    Why not?

  146. pep.

    This has 3 newlines at the beginning

  147. larma

    because the newline could be added as part of pretty printing

  148. larma

    which seems to be fine according to RFC

  149. pep.

    one newlines here before, and one after

  150. pep.

    #FightForWhitespaceRights

  151. larma

    This message has some spaces

  152. larma

    (funnily enough Dino does not do trim before sending, so my message is displayed differently on sender and receiver)

  153. larma

    Conversations also does the same trimming as Dino

  154. pep.

    https://ppjet.bouah.net/whitespace.png

  155. throw-me-out

    This message is pretty printed RFC style and thus should probably be displayed without leading or trailing newlines or whitespaces.

  156. !XSF_Martin

    Hmm

  157. !XSF_Martin

    Ha, conversarions really trimmed the newlines

  158. !XSF_Martin

    Ha, conversations really trimmed the newlines

  159. 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

  160. Holger

    ejabberd won't include whitespace between nodes FWIW. But I ignored the backlog, probably not relevant :-)

  161. Holger

    s/include/preserve/

  162. larma

    Holger, between nodes or between stanzas?

  163. Guus

    I'm actually not sure what Openfire does.

  164. Holger

    larma: Between XML nodes.

  165. Guus

    I'm firmly on team #trimWhiteSpace in the presentation layer though. But we've discussed that to death already.

  166. Holger

    larma: All incoming traffic is decoded into internal structs and it won't include unnecessary whitespace when encoded for transmission.

  167. larma

    Holger, but not inside XML nodes? <body> </body> will go verbatim whereas <test> <test2 /></test> will not?

  168. larma

    "unnecessary whitespace" I don't think that's defined in the RFC 😀

  169. Guus

    I don't expect trimming text in text-nodes is allowed, is it?

  170. 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.

  171. larma

    Guus, we just checked, it is allowed in general just not inside certain text only elements like <body>

  172. Holger

    larma: Well I just had the `<test/> <test2/>` case in mind, which you probably don't care about. In your example "it depends".

  173. Guus

    larma: you're only talking about whitespace though, correct? I ment: <outer>some text<inner/></outer>

  174. larma

    Guus, no I was talking about everything

  175. Guus

    I was under the impression that something like <outer>some text<inner/></outer> is invalid in XMPP - but I might be wrong.

  176. larma

    There is no general rule if RFC 6120 and RFC 6121 has specific rules to forbid mixed content inside certain elements

  177. larma

    Also mixed content is allowed in XHTML-IM which is in XMPP 😉

  178. larma

    I think the consensus is that we don't like mixed content, but it's not disallowed by RFC

  179. Guus

    meh. I'm looking forward to your bugreports. 😃

  180. 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.?

  181. 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.?

  182. pep.

    Or because it's the assumed default would you continue not caring

  183. 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?

  184. pep.

    So that you respect my whitespace

  185. pep.

    Whatever usecase

  186. larma

    I am respecting the whitespace, I am just not wasting my users screenspace

  187. pep.

    You're not respecting whitespace if you trim it

  188. pep.

    power users would probably appreciate that, if only them

  189. pep.

    To me this is about the same fight as "don't interpret body if I don't say so"

  190. 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.

  191. 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.

  192. 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

  193. larma

    Also some fonts render consecutive spaces different to single spaces.

  194. pep.

    That's an issue with your font renderer then

  195. 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: ""

  196. pep.

    I'Ve seen that in a client not so long ago for subscription requests when there's no comment

  197. pep.

    Just asking to display what's intended by the sending entity

  198. 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

  199. larma

    pep., this is strictly impossible because the sending entity does not know my client/font etc

  200. pep.

    So we might as well give up and close shop? :)

  201. pep.

    Or do all the weird things we're inflicting onto body?

  202. pep.

    Because it's not possible to do it right anyway

  203. larma

    What are you expecting this to look like: a b

  204. pep.

    dunno, characters and a bunch of spaces

  205. 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

  206. pep.

    If you use \t you're not expecting it to be displayed as any fixed number or chars no (programmers' myths)

  207. pep.

    (that's the whole point of \t)

  208. larma

    at the beginning of a line I am

  209. pep.

    The sender doesn't decide of the number of chars that \t will be replaced with, is what I mean

  210. larma

    Yeah sure, but I might expect you to display it like that

  211. larma

    just because the information is not transferred doesn't say anything about user expectations

  212. pep.

    I get your point, but you've got wrong expectations here

  213. 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

  214. pep.

    Everybody should use monospace \o/

  215. larma

    Being able to send empty lines is probably the least relevant expectation

  216. larma

    pep., monospace is a lie

  217. pep.

    Do you want a screenshot of my desktop just now? :p

  218. larma

    WWW W👍️W WWW My monospace font doesn't monospace this

  219. pep.

    hmm

  220. !XSF_Martin

    https://files.mdosch.de:5281/upload/zHk1fWzzbI53ZVxn/2020-02-14-160041_scrot.png

  221. !XSF_Martin

    Haven't measured it, but seems quite monospace to me.

  222. larma

    Those were three lines with each three characters in it

  223. !XSF_Martin

    larma: I wouldn't expect emoji to be monospace

  224. larma

    !XSF_Martin, so how many spaces would you expect it to be?

  225. !XSF_Martin

    It's little images and making it the size of a character would render them toooooo small.

  226. larma

    So they shall be arbitrary length? Isn't that completely contradictory to the purpose of monospace fonts?

  227. !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.

  228. !XSF_Martin

    larma: Although emoji are included in fonts I don't see them as *text*

  229. !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

  230. pep.

    larma, would you also trim nbsp btw?

  231. pep.

    Maybe I should start replacing all spaces in front and at the end of lines by nbsp :)

  232. larma

    !XSF_Martin, How about — this is the em dash, which by definition should be 1em width

  233. larma

    pep., we trim whitespaces

  234. pep.

    Any?

  235. larma

    nbsp under typical definition is a whitespace

  236. pep.

    meh

  237. larma

    I haven't tried all of them

  238. pep.

    There is a line with full-width spaces above.

  239. larma

    Yeah, nothing visible on any of me devices

  240. !XSF_Martin

    larma: What about it? Seems to fit in well here. ——— ÄÖÜ @»« ł€¶ ŧ←↓ →ø[ ]}\

  241. !XSF_Martin

    pep.: In profanity there's an empty line in your last message.

  242. edhelas

    https://nl.movim.eu/?node/pubsub.movim.eu/Movim/87633da7-3963-4923-aabc-54ac5f6ad1d8

  243. pep.

    !XSF_Martin, yes

  244. 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

  245. pep.

    edhelas, nice :)

  246. 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)

  247. !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.

  248. larma

    That's what most monospace fonts do, that's why I came up with this example 😉

  249. !XSF_Martin

    Yeah, if you want to have your characters the same width you probably don't want the dash to stand out.

  250. 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.

  251. larma

    Are you arguing that recipient's preference should override sender's preference?

  252. !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.

  253. !XSF_Martin

    That's why I choose a specific font and color scheme.

  254. !XSF_Martin

    It's the same reason I don't like people sending me HTML email without plaintext

  255. !XSF_Martin

    But for the record: I am only speaking as a user, I'm neither an XMPP developer nor affiliated with the XSF

  256. larma

    OK, so we agree it is perfectly fine that a client ignores incoming leading whitespaces, as this is a recipient's preference

  257. pep.

    So you'd also remove "a"s in a message as this is a recipient's preference?

  258. pep.

    if* this is

  259. !XSF_Martin

    larma: I talk about *styling* like character width, colors and so on. Not about removing content.

  260. larma

    A newline is not content

  261. larma

    Same applies to whitespace

  262. larma

    It is formatting

  263. pep.

    larma, the day I send whitespace (language), it is content :)

  264. !XSF_Martin

    Hmm, I see it is hard where to draw the line.

  265. pep.

    larma, we both agree it's not a common use-case for dino's target

  266. 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

  267. !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.

  268. larma

    I have hard times imagining any valid use case for leading newlines

  269. larma

    !XSF_Martin: we are only talking about leading/trailing whitespace

  270. larma

    And I don't really consider whitespace (language) a valid use case...

  271. !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"

  272. larma

    What is "it" that you don't want to touch? The bytes on the wire or how they are displayed?

  273. 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.

  274. 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.

  275. jonas’

    larma, FWIW, I use leading newlines when I paste a block of lines so that they’re all indented the same

  276. jonas’

    many clients indent the first line more than subsequent lines (because the name is prefixed)

  277. larma

    Isn't that a perfect example for using monospace format blocks?

  278. larma

    Which start with a line containing ```

  279. 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

  280. larma

    Ge0rG: we can do the same with message markup xep if you don't want to display ``` ;)

  281. jonas’

    or, y’know, XHTML-IM

  282. jonas’

    minus the CSS crap

  283. Ge0rG

    everything is horrible

  284. 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 ;)

  285. pep.

    poezio also doesn't indent the first line

  286. Ge0rG

    it indents all lines.

  287. Ge0rG

    but the /code plugin fails on pasting tab-completed code because initial whitespace is stripped

  288. Ge0rG

    but the /code plugin fails on pasting tab-indented code because initial whitespace is stripped

  289. Ge0rG

    everything is horrible

  290. 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 😉

  291. pep.

    Even if jonas’ was abusing it we would be wasting less space than dino :p

  292. pep.

    Even if jonas’ were abusing it we would be wasting less space than dino :p

  293. pep.

    was*

  294. pep.

    english?.

  295. dwd

    pep., "were", it's a subjunctive.

  296. pep.

    larma, current terminal size: 273x74

  297. pep.

    dwd, thanks

  298. dwd

    pep., But only foreign speakers would get it right. :-)

  299. pep.

    haha

  300. dwd

    pep., I suspect it properly takes an infinitive, as well, so "even if jonas’ were to abuse it".

  301. pep.

    right, that sounds better

  302. 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/ ?

  303. 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...

  304. lovetox

    moparisthebest, thats a bit misleading

  305. lovetox

    or not, he is breaking compat with all clients, but most clients will update their code soon to send 12 byte IV

  306. lovetox

    so that leaves older versions probably in stable distros

  307. moparisthebest

    right, so breaking compatibility with most existing clients for the next few years until all users update

  308. moparisthebest

    I suspect it'd be better for everyone involved if he simply kept compat with 16 byte IVs in the short term no?

  309. lovetox

    yes correct

  310. moparisthebest

    just requires a small algorithm to hash 16 bytes down to 12

  311. lovetox

    he said its not possible with apples GCM impl

  312. lovetox

    dont know if thats true

  313. lovetox

    yeah is monal not open source?

  314. lovetox

    you could just provide a MR

  315. lovetox

    and while you are at it a problem is also chatsecure, which only accepts 16 byte IV

  316. moparisthebest

    well I volunteered to help but can't write Objective-C or compile/test/run iOS apps

  317. moparisthebest

    I can write what they need in C or Rust or something though

  318. lovetox

    true

  319. lovetox

    much overhead

  320. lovetox

    but i guess the offical muc is the best place to reach him

  321. 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