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
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
flow
moparisthebest, what if you want to resumse a connection initially established via quic on a connection using websockets as transport binding?✎
flow
moparisthebest, 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
flow
jonas’, "via stream feature + attribute on <enable/> as negotiation" →
davidhas joined
flow
why 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
flow
jonas’, 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
flow
jonas’, ok, but I still think we can s/need/should/
Ge0rG
we don't have enough handshakes yet.
flow
Ge0rG, 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
flow
Not 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
Ge0rG
maybe you should move this to the ML
Ge0rG
it's CFE after all
Zash
Is this experience? Seems like speculation about future things
Ge0rG
Do we have a formal Call for Speculation? I'd love that.
dwd
Experiential 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
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
flow
Ge0rG, 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
Kev
Can 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
flow
Kev, xep426
flow
for certain values of "would break"
mathijshas left
mathijshas joined
Kev
Ta.
lorddavidiiihas joined
waqashas left
dwd
Kev, Everything? Yeah, anything relying on character counting. You're NFC rather than NFKC, correct?
lskdjfhas joined
Kev
NFC is what I'm currently having a conversation about.
Kev
NFKC is the lossy one, I think?
dwd
NFC is more stable between unicode versions, so should be OK. Anything that relies on digital signatures will/might break too.
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.
Kev
Covert Channels.
mukt2has joined
lorddavidiiihas joined
dwd
Side 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
Kev
Yes, it feels to me that it's closing a window when the door's open.
Ge0rG
With the dozens of different whitespace characters, you can't have that anyway.
Maxhas left
lorddavidiiihas joined
Kev
Whitespace is normalised in canonical XML isn't it?
Maxhas joined
Maxhas left
Maxhas joined
Maxhas left
Maxhas joined
dwd
Kev, Oh, if you're canonicalising XML too, that might be fun. And no, whitespace is not canonicalized, except outside the document.
dwd
Kev, Excepting line endings.
Kev
<this is= 'though'/>
Kev
Depending how you define 'outside the document'.
dwd
Kev, Yes, inside start and end elements it's normalised. But in any text it isn't.
Kev
Right.
dwd
Kev, You'd also have to deal with people randomly slipping in additional attrbutes.
Kev
Quite.
pep.
dwd, "in any text"? with xml:space="preserve"?
goffihas joined
dwd
pep., 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
Zash
All whitespace in attributes seems to turn into 0x20
davidhas left
mukt2has left
lorddavidiiihas left
davidhas joined
lorddavidiiihas joined
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.
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."
pep.
https://www.w3.org/TR/REC-xml/#sec-white-space
flow
pep., i'd assume that xmpp operates with xml:space='default'
pep.
Is it defined what default means
pep.
somewhere in XMPP
flow
pep., ha, right XML says it is then applcation defined and we don't do that
flow
at least to my knowledge
flow
so anything goes?
pep.
¯\_(ツ)_/¯
flow
I wouldn't be surprised if most XMPP implementations preserve whitespace
flow
besides 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
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...
pep.
fix the sending entities rather than trimming? :/
flow
larma, i have a dino user which reports that dino does not show whitespace only messages. Is that correct?
larma
probably
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 ;)
flow
not saying that dino's behavior is wrong, just telling the story…
larma
pep., well it's funny that pretty printed XML is different to non pretty printed XML in XMPP.
flow
larma, different how?
larma
<body>Test
Test2</body>
usually is pretty printed to
<body>
Test
Test2
</body>
flow
ahh, that implementation would add newlines within the textual content of body
flow
larma, 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
flow
i'd definetly describe that as broken, as one can argue that XMPPs xml:space="default" is preserve
flow
pep., I am not sure how much harm it causes (besides the story I told)
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
pep.
I find both a) and b) in XMPP as crap as the trimming you describe now :x
flow
larma, 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
larma
pep., both a) and b) would work everywhere in XMPP except for the body.
pep.
larma, or anywhere that defines containing text
larma
pep., 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)
larma
I *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..
larma
Yeah, funny things happen there.
larma
I 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?)
larma
probably
pep.
Also it's funny that whitespace handling can be changed at the CSS layer
pep.
unrelatedly
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?
pep.
I guess we do :x
larma
maybe it's good that we haven't clarified whitespace handling too much in XMPP
pep.
somebody(tm) should open an errata I guess
larma
can we maybe go with xml:space="preserve" on <body> and basically ignore whitespace outside?
larma
Even 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
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
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?
pep.
flow, yeah that's be a good first step I think
larma
flow, you want to break backwards compatibility?
larma
also, why don't we like pretty printed?
flow
maybe even with 'default', <message>\n<bar/></message> would become <message>U+0020<bar/></message> and still be invalid
flow
larma, 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)
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
pep.
larma, it's already the case no? That mixed text/tag is not valid
Shellhas left
Shellhas joined
flow
I see, but the client could also "normalize" your pretty printed input before its put on the wire
larma
pep., yes and no: text might be but whitespaces are ignored
pep.
Do you know where that's defined?
larma
flow, so how do I put malformed XML on the wire then? 😀
larma
pep., maybe nowhere
flow
larma, hehe, I'am sure you figure out a way
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
pep.
:(
goffihas left
pdurbinhas left
throw-me-outhas joined
throw-me-out
This message is invalid.
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)
pep.
poezio displayed it
flow
I am not surprised that the "no mixed content" rule is not enforced
larma
flow, well if it's not enforced, enforcing it is likely to break compatibility...
flow
most implementations will simply ignore the textual content
edhelashas left
flow
larma, I think I have a different definition of compatibility than you
larma
I just checked RFC, and mixed content is allowed
larma
It's just not allowed inside <show> <status> <priority> <body> <subject> and <thread>
flow
ahh
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
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.
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
larma
So 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
larma
because the newline could be added as part of pretty printing
larma
which 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
larma
Conversations 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.
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
Douglas Terabytehas left
Holger
ejabberd won't include whitespace between nodes FWIW. But I ignored the backlog, probably not relevant :-)
Douglas Terabytehas joined
mukt2has left
Holger
s/include/preserve/
larma
Holger, between nodes or between stanzas?
Guus
I'm actually not sure what Openfire does.
Holger
larma: Between XML nodes.
sonnyhas left
Guus
I'm firmly on team #trimWhiteSpace in the presentation layer though. But we've discussed that to death already.
Holger
larma: All incoming traffic is decoded into internal structs and it won't include unnecessary whitespace when encoded for transmission.
larma
Holger, 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
Guus
I don't expect trimming text in text-nodes is allowed, is it?
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.
larma
Guus, we just checked, it is allowed in general just not inside certain text only elements like <body>
Holger
larma: Well I just had the `<test/> <test2/>` case in mind, which you probably don't care about. In your example "it depends".
Guus
larma: you're only talking about whitespace though, correct? I ment: <outer>some text<inner/></outer>
larma
Guus, no I was talking about everything
Guus
I was under the impression that something like <outer>some text<inner/></outer> is invalid in XMPP - but I might be wrong.
larma
There is no general rule if RFC 6120 and RFC 6121 has specific rules to forbid mixed content inside certain elements
larma
Also mixed content is allowed in XHTML-IM which is in XMPP 😉
larma
I think the consensus is that we don't like mixed content, but it's not disallowed by RFC
romeohas left
Guus
meh. 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
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?
mukt2has left
pep.
So that you respect my whitespace
pep.
Whatever usecase
larma
I 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"
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.
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.
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
larma
Also 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
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
larma
pep., 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
larma
What are you expecting this to look like:
a
b
pep.
dunno, characters and a bunch of spaces
lovetoxhas joined
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
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)
larma
at 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
larma
Yeah sure, but I might expect you to display it like that
larma
just 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
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
pep.
Everybody should use monospace \o/
larma
Being able to send empty lines is probably the least relevant expectation
larma
pep., monospace is a lie
pep.
Do you want a screenshot of my desktop just now? :p
Danielhas left
Danielhas joined
larma
WWW
W👍️W
WWW
My monospace font doesn't monospace this
!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 :)
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)
!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
larma
That's what most monospace fonts do, that's why I came up with this example 😉
!XSF_Martin
Yeah, if you want to have your characters the same width you probably don't want the dash to stand out.
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.
larma
Are you arguing that recipient's preference should override sender's preference?
Shellhas left
Shellhas joined
!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.
!XSF_Martin
That's why I choose a specific font and color scheme.
!XSF_Martin
It's the same reason I don't like people sending me HTML email without plaintext
!XSF_Martin
But for the record: I am only speaking as a user, I'm neither an XMPP developer nor affiliated with the XSF
larma
OK, 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_Martin
larma: I talk about *styling* like character width, colors and so on. Not about removing content.
larma
A newline is not content
larma
Same applies to whitespace
larma
It is formatting
Zashhas left
Zashhas joined
pep.
larma, the day I send whitespace (language), it is content :)
!XSF_Martin
Hmm, 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
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
!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.
larma
I have hard times imagining any valid use case for leading newlines
larma
!XSF_Martin: we are only talking about leading/trailing whitespace
larma
And I don't really consider whitespace (language) a valid use case...
!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"
larma
What is "it" that you don't want to touch? The bytes on the wire or how they are displayed?
adiaholichas joined
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.✎
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. ✏
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
larma
Isn't that a perfect example for using monospace format blocks?
larma
Which start with a line containing ```
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
lorddavidiiihas joined
larma
Ge0rG: 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
Ge0rG
everything is horrible
lovetoxhas left
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 ;)
pep.
poezio also doesn't indent the first line
Ge0rG
it indents all lines.
lorddavidiiihas left
Ge0rG
but the /code plugin fails on pasting tab-completed code because initial whitespace is stripped✎
adiaholichas joined
Ge0rG
but the /code plugin fails on pasting tab-indented code because initial whitespace is stripped ✏
mukt2has joined
Ge0rG
everything is horrible
lovetoxhas joined
lorddavidiiihas joined
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 😉
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
dwd
pep., "were", it's a subjunctive.
pep.
larma, current terminal size: 273x74
pep.
dwd, thanks
dwd
pep., But only foreign speakers would get it right. :-)
pep.
haha
lorddavidiiihas joined
dwd
pep., 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
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/ ?
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...
lovetox
moparisthebest, thats a bit misleading
SubPubhas left
lovetox
or not, he is breaking compat with all clients, but most clients will update their code soon to send 12 byte IV
lovetox
so that leaves older versions probably in stable distros
moparisthebest
right, so breaking compatibility with most existing clients for the next few years until all users update
moparisthebest
I suspect it'd be better for everyone involved if he simply kept compat with 16 byte IVs in the short term no?
lovetox
yes correct
moparisthebest
just requires a small algorithm to hash 16 bytes down to 12
lovetox
he said its not possible with apples GCM impl
lovetox
dont know if thats true
lovetox
yeah is monal not open source?
lovetox
you could just provide a MR
LNJhas joined
lovetox
and while you are at it a problem is also chatsecure, which only accepts 16 byte IV
moparisthebest
well I volunteered to help but can't write Objective-C or compile/test/run iOS apps
moparisthebest
I can write what they need in C or Rust or something though
lovetox
true
lovetox
much overhead
lovetox
but i guess the offical muc is the best place to reach him
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