moparisthebestYea I saw that too, though previously I heard it was dead in the water due to middleboxes, so I wonder if anything changed there
andyhas left
paulhas left
pdurbinhas joined
karoshihas left
archas left
archas joined
pdurbinhas left
rionhas left
rionhas joined
archas left
archas joined
archas left
archas joined
archas left
archas joined
archas left
archas joined
archas left
archas joined
ajhas joined
ajhas left
Douglas Terabytehas left
Douglas Terabytehas joined
neshtaxmpphas left
neshtaxmpphas joined
Yagizahas joined
Nekithas joined
pdurbinhas joined
archas left
archas joined
pdurbinhas left
mukt2has joined
waqashas joined
larmahas left
lskdjfhas left
larmahas joined
pdurbinhas joined
archas left
archas joined
mukt2has left
mukt2has joined
andyhas joined
lorddavidiiihas joined
edhelashas left
mukt2has left
mukt2has joined
pdurbinhas left
strypeyhas joined
adiaholichas joined
pdurbinhas joined
mukt2has left
paulhas joined
mukt2has joined
!XSF_Martinhas left
debxwoodyhas joined
!XSF_Martinhas joined
edhelashas joined
archas left
archas joined
strypeyhas left
wurstsalathas left
wurstsalathas joined
archas left
archas joined
karoshihas joined
lorddavidiiihas left
lorddavidiiihas joined
lorddavidiiihas left
lorddavidiiihas joined
lorddavidiiihas left
lorddavidiiihas joined
pdurbinhas left
archas left
archas joined
debxwoodyhas left
archas left
archas joined
archas left
debaclehas joined
Tobiashas joined
adiaholichas left
mimi89999has left
mathijshas left
mathijshas joined
strypeyhas joined
serge90has left
eevvoorhas joined
mimi89999has joined
serge90has joined
strypeyhas left
strypeyhas joined
mathijshas left
flowmoparisthebest, what if you want to resumse a connection initially established via quic on a connection using websockets as transport binding?
flowmoparisthebest, what if you want to resume a connection initially established via quic on a connection using websockets as transport binding?
romeohas joined
davidhas left
mathijshas joined
flowjonas’, "via stream feature + attribute on <enable/> as negotiation" →
davidhas joined
flowwhy the attribute? what's its value?
Marchas left
jonas’flow, the client needs to tell the server that it supports alternative transports, too
mukt2has left
jonas’it could be "supported-transports='...'" or "i-support-quic='true'"
goffihas joined
goffihas left
goffihas joined
goffihas left
Steve Killehas left
Dele Olajidehas joined
Marchas joined
Dele Olajidehas left
Dele Olajidehas joined
Steve Killehas joined
!XSF_Martinhas left
mathijshas left
mathijshas joined
!XSF_Martinhas joined
mathijshas left
mathijshas joined
mukt2has joined
Douglas Terabytehas left
strypeyhas left
strypeyhas joined
j.rhas left
j.rhas joined
mukt2has left
mukt2has joined
pdurbinhas joined
debxwoodyhas joined
pdurbinhas left
debaclehas left
j.rhas left
j.rhas joined
j.rhas left
j.rhas joined
flowjonas’, why does the client need to tell the server that it supports alternative transports too?
mukt2has left
ajhas joined
Dele Olajidehas left
jonas’flow, so that the server can pick a proper reconnect address out of multiple options
flowjonas’, ok, but I still think we can s/need/should/
Ge0rGwe don't have enough handshakes yet.
flowGe0rG, I don't think there is an additional handshake involved
j.rhas left
j.rhas joined
mukt2has joined
j.rhas left
jonas’flow, if you say so. I also think that there’s little point in discussing the details right now
j.rhas joined
mukt2has left
flowNot sure which time would be better to discuss matters of xep198, especially since there is a CFE for xep198 out
mukt2has joined
debxwoodyhas left
mukt2has left
mukt2has joined
jonas’it’s not about '198
jonas’it’s about future extensions
Ge0rGmaybe you should move this to the ML
Ge0rGit's CFE after all
ZashIs this experience? Seems like speculation about future things
Ge0rGDo we have a formal Call for Speculation? I'd love that.
dwdExperiential part is that people do use '198 resumption across different transports.
debaclehas joined
Douglas Terabytehas joined
debxwoodyhas joined
davidhas left
lorddavidiiihas left
davidhas joined
lorddavidiiihas joined
ajhas left
debxwoodyhas left
Dele (Mobile)has joined
flowwell 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
flowGe0rG, I think I posted everything I said here also to the ML. Please correct me if I'm wrong
mukt2has left
mukt2has joined
davidhas left
davidhas joined
mukt2has left
jubalhhas left
jubalhhas joined
jubalhhas left
jubalhhas joined
jubalhhas left
jubalhhas joined
jubalhhas left
strypeyhas left
jubalhhas joined
mukt2has joined
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
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.
eevvoorhas left
mukt2has left
davidhas left
davidhas joined
mukt2has joined
davidhas left
davidhas joined
pdurbinhas joined
mukt2has left
mukt2has joined
lorddavidiiihas left
lorddavidiiihas joined
KevCan anyone think of anything that would break if a server was going to Unicode NFC-ify everything that goes through it?
mukt2has left
lorddavidiiihas left
mathijshas left
mathijshas joined
flowKev, xep426
flowfor certain values of "would break"
mathijshas left
mathijshas joined
KevTa.
lorddavidiiihas joined
waqashas left
dwdKev, Everything? Yeah, anything relying on character counting. You're NFC rather than NFKC, correct?
lskdjfhas joined
KevNFC is what I'm currently having a conversation about.
KevNFKC is the lossy one, I think?
dwdNFC is more stable between unicode versions, so should be OK. Anything that relies on digital signatures will/might break too.
dwdNFKC is Kompatibility, to ™ -> TM
dwdNFKC is Kompatibility, so ™ -> TM
lorddavidiiihas left
dwdBut 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.
KevCovert Channels.
mukt2has joined
lorddavidiiihas joined
dwdSide channel attacks based on composition? I suspect that word choice would be far simpler, but I suppose it's worth closing.
pdurbinhas left
lorddavidiiihas left
KevYes, it feels to me that it's closing a window when the door's open.
Ge0rGWith the dozens of different whitespace characters, you can't have that anyway.
Maxhas left
lorddavidiiihas joined
KevWhitespace is normalised in canonical XML isn't it?
Maxhas joined
Maxhas left
Maxhas joined
Maxhas left
Maxhas joined
dwdKev, Oh, if you're canonicalising XML too, that might be fun. And no, whitespace is not canonicalized, except outside the document.
dwdKev, Excepting line endings.
Kev<this is= 'though'/>
KevDepending how you define 'outside the document'.
dwdKev, Yes, inside start and end elements it's normalised. But in any text it isn't.
KevRight.
dwdKev, You'd also have to deal with people randomly slipping in additional attrbutes.
KevQuite.
pep.dwd, "in any text"? with xml:space="preserve"?
goffihas joined
dwdpep., I think that's the case by default, isn't it? I see, though, that whitespace is normalized in attribute values.
jonas’I’d very much like not to set a precedent for a server messing with data
ZashAll whitespace in attributes seems to turn into 0x20
davidhas left
mukt2has left
lorddavidiiihas left
davidhas joined
lorddavidiiihas joined
dwdjonas’, 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.
Marchas left
Marchas joined
mukt2has joined
jonas’indeed
lorddavidiiihas left
SubPubhas joined
lorddavidiiihas joined
Shellhas joined
lorddavidiiihas left
mukt2has left
mukt2has joined
lorddavidiiihas joined
larmahas left
Dele (Mobile)has left
Dele (Mobile)has joined
lorddavidiiihas left
lorddavidiiihas joined
lorddavidiiihas left
Shellhas left
Shellhas joined
lorddavidiiihas joined
larmahas joined
LNJhas joined
Shellhas left
Shellhas joined
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."
flowpep., i'd assume that xmpp operates with xml:space='default'
pep.Is it defined what default means
pep.somewhere in XMPP
flowpep., ha, right XML says it is then applcation defined and we don't do that
flowat least to my knowledge
flowso anything goes?
pep.¯\_(ツ)_/¯
flowI wouldn't be surprised if most XMPP implementations preserve whitespace
flowbesides some doing a trim() on <body/> (dino IIRC)
pep.I think they do, I sometimes see pretty-printed XML in my client logs
krauqhas left
krauqhas joined
larmaflow, 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...
pep.fix the sending entities rather than trimming? :/
flowlarma, i have a dino user which reports that dino does not show whitespace only messages. Is that correct?
larmaprobably
flowwhich 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 ;)
flownot saying that dino's behavior is wrong, just telling the story…
larmapep., well it's funny that pretty printed XML is different to non pretty printed XML in XMPP.
flowlarma, different how?
larma<body>Test
Test2</body>
usually is pretty printed to
<body>
Test
Test2
</body>
flowahh, that implementation would add newlines within the textual content of body
flowlarma, which implementation was/is that?
pep.larma, ask the sending entity to fix it rather :/
pep.It's their fault not yours. And trimming on reception is only going to harm your users
flowi'd definetly describe that as broken, as one can argue that XMPPs xml:space="default" is preserve
flowpep., I am not sure how much harm it causes (besides the story I told)
larmaAlso 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
pep.I find both a) and b) in XMPP as crap as the trimming you describe now :x
flowlarma, i am still missing the part where we publicly shame that sending implementation ;)
pep.I'd say the behaviour is always preserve in text nodes
larmapep., both a) and b) would work everywhere in XMPP except for the body.
pep.larma, or anywhere that defines containing text
larmapep., well I don't know too many examples but I remember that it worked for some
pep.xhtml-im. possibly reactions? (when are we going to be able to send more than one grapheme cluster? :p)
larmaI *hope* XHTML-IM does the same whitespace handling as XHTML, which is the one described above IIRC
pep.But if the XML library used in the XMPP client doesn't..
larmaYeah, funny things happen there.
larmaI am not aware of any HTML renderer printing " " as two spaces except of inside <pre> or <code> elements
pdurbinhas joined
mathijshas left
mathijshas joined
pep.XHTML defines xml:space="default" as both your a) and b) right? and code and pre are xml:space="preserve" (or only pre?)
larmaprobably
pep.Also it's funny that whitespace handling can be changed at the CSS layer
pep.unrelatedly
larmaIf 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?
pep.I guess we do :x
larmamaybe it's good that we haven't clarified whitespace handling too much in XMPP
pep.somebody(tm) should open an errata I guess
larmacan we maybe go with xml:space="preserve" on <body> and basically ignore whitespace outside?
larmaEven if it's not what Dino does, it seems the most sane to me
pep.no we can't. We should recommend XEP authors to take tht into account
pep.and properly define what is xml:space="preserve" and what isn't
pep.if it's not the default, that currently isn't defined anywhere
larmapep., 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
flowlarma, 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?
pep.flow, yeah that's be a good first step I think
larmaflow, you want to break backwards compatibility?
larmaalso, why don't we like pretty printed?
flowmaybe even with 'default', <message>\n<bar/></message> would become <message>U+0020<bar/></message> and still be invalid
flowlarma, I don't think I am breaking backwards compatibility
pep.flow, no, "default" not being defined in XMPP there's no normalization happening
flow(besides that, I usually try to avoid breaking backwards compatibility)
larmaI 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
pep.larma, it's already the case no? That mixed text/tag is not valid
Shellhas left
Shellhas joined
flowI see, but the client could also "normalize" your pretty printed input before its put on the wire
larmapep., yes and no: text might be but whitespaces are ignored
pep.Do you know where that's defined?
larmaflow, so how do I put malformed XML on the wire then? 😀
larmapep., maybe nowhere
flowlarma, hehe, I'am sure you figure out a way
larmapep., 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
pep.:(
goffihas left
pdurbinhas left
throw-me-outhas joined
throw-me-outThis message is invalid.
larmaDid 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)
pep.poezio displayed it
flowI am not surprised that the "no mixed content" rule is not enforced
larmaflow, well if it's not enforced, enforcing it is likely to break compatibility...
flowmost implementations will simply ignore the textual content
edhelashas left
flowlarma, I think I have a different definition of compatibility than you
larmaI just checked RFC, and mixed content is allowed
larmaIt's just not allowed inside <show> <status> <priority> <body> <subject> and <thread>
flowahh
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."
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)"
pep.whitespace handling in XMPP is :x
sonnyhas left
pep.#FightForWhitespaceRights
edhelashas joined
sonnyhas joined
larmaI 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.
larmaAll 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
larmaSo the client that did cause Dino to add this trimming was actually RFC compliant
larma
and it is just not properly possible to send a message that starts with a new line
pep.Why not?
pep.
This has 3 newlines at the beginning
larmabecause the newline could be added as part of pretty printing
larmawhich seems to be fine according to RFC
pep.
one newlines here before, and one after
sonnyhas left
sonnyhas joined
pep.#FightForWhitespaceRights
larma
This message has some spaces
larma(funnily enough Dino does not do trim before sending, so my message is displayed differently on sender and receiver)
mathijshas left
larmaConversations also does the same trimming as Dino
pep.https://ppjet.bouah.net/whitespace.png
throw-me-out
This message is pretty printed RFC style and thus should probably be displayed without leading or trailing newlines or whitespaces.
!XSF_Martin
Hmm
!XSF_MartinHa, conversarions really trimmed the newlines
!XSF_MartinHa, conversations really trimmed the newlines
mathijshas joined
larmaSo 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
Douglas Terabytehas left
Holgerejabberd won't include whitespace between nodes FWIW. But I ignored the backlog, probably not relevant :-)
Douglas Terabytehas joined
mukt2has left
Holgers/include/preserve/
larmaHolger, between nodes or between stanzas?
GuusI'm actually not sure what Openfire does.
Holgerlarma: Between XML nodes.
sonnyhas left
GuusI'm firmly on team #trimWhiteSpace in the presentation layer though. But we've discussed that to death already.
Holgerlarma: All incoming traffic is decoded into internal structs and it won't include unnecessary whitespace when encoded for transmission.
larmaHolger, but not inside XML nodes? <body> </body> will go verbatim whereas <test> <test2 /></test> will not?
larma"unnecessary whitespace" I don't think that's defined in the RFC 😀
sonnyhas joined
mukt2has joined
GuusI don't expect trimming text in text-nodes is allowed, is it?
Guusand 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.
larmaGuus, we just checked, it is allowed in general just not inside certain text only elements like <body>
Holgerlarma: Well I just had the `<test/> <test2/>` case in mind, which you probably don't care about. In your example "it depends".
Guuslarma: you're only talking about whitespace though, correct? I ment: <outer>some text<inner/></outer>
larmaGuus, no I was talking about everything
GuusI was under the impression that something like <outer>some text<inner/></outer> is invalid in XMPP - but I might be wrong.
larmaThere is no general rule if RFC 6120 and RFC 6121 has specific rules to forbid mixed content inside certain elements
larmaAlso mixed content is allowed in XHTML-IM which is in XMPP 😉
larmaI think the consensus is that we don't like mixed content, but it's not disallowed by RFC
romeohas left
Guusmeh. I'm looking forward to your bugreports. 😃
Danielhas left
Danielhas joined
eevvoorhas joined
Danielhas left
Danielhas joined
SubPubhas left
eevvoorhas left
Danielhas left
Danielhas joined
mathijshas left
mathijshas joined
Danielhas left
Danielhas joined
Danielhas left
Danielhas joined
Danielhas left
Danielhas joined
eevvoorhas joined
Danielhas left
Danielhas joined
mathijshas left
mathijshas joined
LNJhas left
mathijshas left
mathijshas joined
mukt2has left
mukt2has joined
SubPubhas joined
Shellhas left
Shellhas joined
throw-me-outhas left
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.?
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.?
pep.Or because it's the assumed default would you continue not caring
romeohas joined
larmapep., 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?
mukt2has left
pep.So that you respect my whitespace
pep.Whatever usecase
larmaI am respecting the whitespace, I am just not wasting my users screenspace
pep.You're not respecting whitespace if you trim it
pep.power users would probably appreciate that, if only them
pep.To me this is about the same fight as "don't interpret body if I don't say so"
larmaBy 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.
larmapep., 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.
larmaFor 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
larmaAlso some fonts render consecutive spaces different to single spaces.
pep.That's an issue with your font renderer then
pdurbinhas joined
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: ""
pep.I'Ve seen that in a client not so long ago for subscription requests when there's no comment
pep.Just asking to display what's intended by the sending entity
larmapreserving 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
larmapep., this is strictly impossible because the sending entity does not know my client/font etc
pep.So we might as well give up and close shop? :)
mukt2has joined
pep.Or do all the weird things we're inflicting onto body?
pep.Because it's not possible to do it right anyway
larmaWhat are you expecting this to look like:
a
b
pep.dunno, characters and a bunch of spaces
lovetoxhas joined
larmathere is a tab character before the a, I might be expecting it to be displayed as 4 or 8 spaces or displayed as \t
pep.If you use \t you're not expecting it to be displayed as any fixed number or chars no (programmers' myths)
pep.(that's the whole point of \t)
larmaat the beginning of a line I am
pep.The sender doesn't decide of the number of chars that \t will be replaced with, is what I mean
pdurbinhas left
larmaYeah sure, but I might expect you to display it like that
larmajust because the information is not transferred doesn't say anything about user expectations
pep.I get your point, but you've got wrong expectations here
larmaWe 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
pep.Everybody should use monospace \o/
larmaBeing able to send empty lines is probably the least relevant expectation
larmapep., monospace is a lie
pep.Do you want a screenshot of my desktop just now? :p
Danielhas left
Danielhas joined
larmaWWW
W👍️W
WWW
My monospace font doesn't monospace this
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
pep.edhelas, nice :)
larmaWe 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)
!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.
goffihas joined
Maxhas left
Maxhas joined
larmaThat's what most monospace fonts do, that's why I came up with this example 😉
!XSF_MartinYeah, if you want to have your characters the same width you probably don't want the dash to stand out.
larmawell 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.
larmaAre you arguing that recipient's preference should override sender's preference?
Shellhas left
Shellhas joined
!XSF_MartinYes, I also wouldn't want to see red text on orange background only because the sender likes this theme on his client.
!XSF_MartinThat's why I choose a specific font and color scheme.
!XSF_MartinIt's the same reason I don't like people sending me HTML email without plaintext
!XSF_MartinBut for the record: I am only speaking as a user, I'm neither an XMPP developer nor affiliated with the XSF
larmaOK, so we agree it is perfectly fine that a client ignores incoming leading whitespaces, as this is a recipient's preference
pep.So you'd also remove "a"s in a message as this is a recipient's preference?
pep.if* this is
!XSF_Martinlarma: I talk about *styling* like character width, colors and so on. Not about removing content.
larmaA newline is not content
larmaSame applies to whitespace
larmaIt is formatting
Zashhas left
Zashhas joined
pep.larma, the day I send whitespace (language), it is content :)
!XSF_MartinHmm, I see it is hard where to draw the line.
pep.larma, we both agree it's not a common use-case for dino's target
larmaYour 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
!XSF_MartinBut 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.
larmaI have hard times imagining any valid use case for leading newlines
larma!XSF_Martin: we are only talking about leading/trailing whitespace
larmaAnd I don't really consider whitespace (language) a valid use case...
!XSF_MartinIn 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"
larmaWhat is "it" that you don't want to touch? The bytes on the wire or how they are displayed?
adiaholichas joined
larmaThe 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.
larmaThe 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.
jonas’larma, FWIW, I use leading newlines when I paste a block of lines so that they’re all indented the same
mukt2has left
jonas’many clients indent the first line more than subsequent lines (because the name is prefixed)
lorddavidiiihas left
adiaholichas left
larmaIsn't that a perfect example for using monospace format blocks?
larmaWhich start with a line containing ```
Ge0rGbut 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
lorddavidiiihas joined
larmaGe0rG: we can do the same with message markup xep if you don't want to display ``` ;)
Dele Olajidehas joined
jonas’or, y’know, XHTML-IM
jonas’minus the CSS crap
Ge0rGeverything is horrible
lovetoxhas left
larmaAlso 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 ;)
pep.poezio also doesn't indent the first line
Ge0rGit indents all lines.
lorddavidiiihas left
Ge0rGbut the /code plugin fails on pasting tab-completed code because initial whitespace is stripped
adiaholichas joined
Ge0rGbut the /code plugin fails on pasting tab-indented code because initial whitespace is stripped
mukt2has joined
Ge0rGeverything is horrible
lovetoxhas joined
lorddavidiiihas joined
larmapep., 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 😉
pep.Even if jonas’ was abusing it we would be wasting less space than dino :p
pep.Even if jonas’ were abusing it we would be wasting less space than dino :p
pep.was*
pep.english?.
lorddavidiiihas left
dwdpep., "were", it's a subjunctive.
pep.larma, current terminal size: 273x74
pep.dwd, thanks
dwdpep., But only foreign speakers would get it right. :-)
pep.haha
lorddavidiiihas joined
dwdpep., I suspect it properly takes an infinitive, as well, so "even if jonas’ were to abuse it".
pep.right, that sounds better
j.rhas left
Maxhas left
Maxhas joined
lorddavidiiihas left
lorddavidiiihas joined
Maxhas left
Maxhas joined
lorddavidiiihas left
lorddavidiiihas joined
lorddavidiiihas left
mukt2has left
lorddavidiiihas joined
Maxhas left
Maxhas joined
Maxhas left
lorddavidiiihas left
Maxhas joined
lorddavidiiihas joined
lorddavidiiihas left
Maxhas left
mathijshas left
lorddavidiiihas joined
Maxhas joined
j.rhas joined
lorddavidiiihas left
lorddavidiiihas joined
mathijshas joined
Maxhas left
Shellhas left
Shellhas joined
Maxhas joined
lorddavidiiihas left
Maxhas left
lorddavidiiihas joined
Maxhas joined
lorddavidiiihas left
Maxhas left
Maxhas joined
lorddavidiiihas joined
lorddavidiiihas left
Shellhas left
Shellhas joined
lorddavidiiihas joined
lorddavidiiihas left
mukt2has joined
lorddavidiiihas joined
lovetoxhas left
calvinhas joined
lorddavidiiihas left
lorddavidiiihas joined
andrey.ghas left
Maxhas left
Maxhas joined
eevvoorhas left
lovetoxhas joined
mathijshas left
mathijshas joined
lorddavidiiihas left
mathijshas left
lorddavidiiihas joined
mathijshas joined
pdurbinhas joined
lorddavidiiihas left
andyhas left
lorddavidiiihas joined
lorddavidiiihas left
mathijshas left
mathijshas joined
lorddavidiiihas joined
Steve Killehas left
lorddavidiiihas left
pdurbinhas left
lorddavidiiihas joined
Steve Killehas joined
debaclehas left
j.rhas left
j.rhas joined
adiaholichas left
Shellhas left
Shellhas joined
Shellhas left
Shellhas joined
mukt2has left
eevvoorhas joined
mukt2has joined
andrey.ghas joined
mathijshas left
mathijshas joined
mathijshas left
mathijshas joined
krauqhas left
andrey.ghas left
krauqhas joined
andrey.ghas joined
mathijshas left
mathijshas joined
mathijshas left
mathijshas joined
debaclehas joined
mathijshas left
mathijshas joined
eevvoorhas left
calvinhas left
lovetoxhas left
andyhas joined
goffihas left
mukt2has left
Maxhas left
Maxhas joined
mukt2has joined
pdurbinhas joined
goffihas joined
lovetoxhas joined
pdurbinhas left
Shellhas left
Shellhas joined
mukt2has left
eevvoorhas joined
mukt2has joined
Dele Olajidehas left
eevvoorhas left
romeohas left
eevvoorhas joined
mukt2has left
moparisthebestanyone 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/ ?
moparisthebestlong 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...
lovetoxmoparisthebest, thats a bit misleading
SubPubhas left
lovetoxor not, he is breaking compat with all clients, but most clients will update their code soon to send 12 byte IV
lovetoxso that leaves older versions probably in stable distros
moparisthebestright, so breaking compatibility with most existing clients for the next few years until all users update
moparisthebestI suspect it'd be better for everyone involved if he simply kept compat with 16 byte IVs in the short term no?
lovetoxyes correct
moparisthebestjust requires a small algorithm to hash 16 bytes down to 12
lovetoxhe said its not possible with apples GCM impl
lovetoxdont know if thats true
lovetoxyeah is monal not open source?
lovetoxyou could just provide a MR
LNJhas joined
lovetoxand while you are at it a problem is also chatsecure, which only accepts 16 byte IV
moparisthebestwell I volunteered to help but can't write Objective-C or compile/test/run iOS apps
moparisthebestI can write what they need in C or Rust or something though
lovetoxtrue
lovetoxmuch overhead
lovetoxbut i guess the offical muc is the best place to reach him
moparisthebestyep 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
XSF Discussion - 2020-02-14