jdev - 2023-10-27

I'm trying to do a bit of implicit testing of our new network stack by having some s2s traffic. I'd appreciate people trying to set up a quick connection to see if something unexpected happens. You can use this temporary account: interop@igniterealtime.org (send it a message or something). Let me know if you're running into something unexpected!

Guus, tested all the badxmpp domains? :)

Someone else is, yes :)

we're developing something that interacts with that from our CI setup

I'm primarily trying to get some data outside of the stuff that we thought of ourselves. Letting random people do random things is a good way to fill up the logs. :)

Guus, fyi, xmpp2.igniterealtime.org. doesn’t reply on port 5269.

xmpp2 should be offline

is it still in our DNS?

It is.

eek, let me fix that

Also, xmpp.igniterealtime.org. doesn’t reply anything on bad input, I think it should close the socket or something perhaps.

Guus: fyi it would be easier to click an uri like xmpp:interop@igniterealtime.org?message :) ✏

xmpp2 has now been removed from our SRV records (most records had a 300s TTL).

No delivery error... yet?

Link Mauve: the bad input test isn't something that we gave much thought in this rewrite. It's something to look into.

Zash, thanks (and thanks - I responded)

Guus: go talk to some badxmpp.eu hosts? :)

Zash: yeah, we do

:)

oh, who's doing the localhost thing?

The localhost thing?

someone is trying to identify themselves as 'localhost'

Works. :)

Wrong window…

DirectTLS was enabled just now, which is likely what Martin was testing :)

... looking forward for someone doing a test that's not using Prosody ;)

I used netcat!

hehe - ok ok

You already tested against an M-Link Edge when you sent me messages yesterday, right?

if you were on M-Link Edge at the time, yes - but that was accidental :D

I think that Openfire is using the default c2s max idle time for s2s too - I'm seeing reconnects every 5/6 minutes from some domains (I think we had it at something like 30 minutes before). All of those defaults are pretty much based on nothing but a gut feeling. Does anyone have a rationale for reasonable timeouts?

I'm not on an Edge, I'm on an M-Link User Server, but there's an M-Link Edge between the user server and the Internet :) ✏

Guus, prosody doesn't timeout s2s on its own at all

Which one is the 30 minutes timeout then? Ejabberd?

yes ✏

i thought about how to go about implementing https://xmpp.org/extensions/xep-0394.html

and i have no clue to be honest

i mean specifically the receiving side

has someone implemented that?

xmpp.org at least comes up empty

lovetox, no, and there's a reason I abandoned it

just re-implement XHTML-IM

but securely

somehow all the other things manage to use HTML for on-wire formatting, surely we can too

thats great for clients that display html, for all others it does not really matter

lovetox, even poezio supports XHTML-IM

I'm not sure what you're trying to say.

lovetox, it's in fact worse for clients that display html already, because they need to be extra careful not create security problems

that it does not matter if you use standard html tags, or invented tags (like in 0394), when the client cant display html

You can take our code if you want, it’s already in Python.

no, '394 is a huge mess

it's much trickier to implement because you can easily miscount and stuff

it doesnt even have security considerations

with displaying html i mean, passing the html as is to a engine which draws it to the screen, with no added effort by the developer

> passing the html as is to a engine nope, don't

jonas’, sadly new XEPs like replies also rely on counting codepoints…

(If you want the fallback.)

MSavoritias (fae,ve): that must mean it's secure! 😎

lovetox, please never do that, ever.

You don’t want to enable JavaScript vulnerabilities just because.

> with displaying html i mean, passing the html as is to a engine which draws it to the screen, with no added effort by the developer Absolutely under no circumstances should you do this! ↺

And no browser engine lets you just disable JavaScript in their API.

what i mean is, if you cannot use standard libraries to get value from html, you need to write a parser and translation to your UI framework from scratch

Link Mauve: Oh i like your avatar !

and it does not really matter if you build upon html, or some new invented language

Trung, thanks. :)

lovetox, it does, if you consider ecosystem support.

Trung, I’ve had it for years, but some clients (all clients on Android for instance) don’t support SVG.

XHTML-IM still has support in clients, I do not know of a single client implementing '394

> and it does not really matter if you build upon html, or some new invented language it matters in the sense that we already know how to handle html. and we are not specifying it alone

wgreenhouse, yay!

Link Mauve: poezio's xhtml-im is too good! (poezio + biboumi perfectly reproduce the illegible stylings of irc spammers) ✏

jonas’, not sure what you are getting at, xhtml-im is dead, nobody did any effort to change that in years

we need to use more standard stuff not less in xmpp

lovetox, it isn’t though.

we already have that problem with omemo anyway

lovetox, the same words apply to '394.

with the exception that there are a lot of folks thinking now that abandoning xHTML-IM was a bad idea, while there is approximately one person who thinks that '394 might be a good idea.

Who?!

maybe i misunderstood, did you make any proposal?

Link Mauve, the person who took over '394 might

(I'm not listed as author anymore)

Ah maybe.

lovetox, my proposal is: implement XHTML-IM. once it re-gains traction in the ecosystem, respecify it properly.

'394 is a dead end.

↑ agreed.

it probably will not gain traction anytime soon

why not?

>> with displaying html i mean, passing the html as is to a engine which draws it to the screen, with no added effort by the developer > Absolutely under no circumstances should you do this! Depends what kind of engine. Android has a built in html parser specifically for basic text styling case thrt doesn't support dangerous stuff, for example, which i use ↺

agreed. i would love to work personally on an xhtml but specified on top of html5

because xhtml does not work with omemo

lovetox, '394 doesn't, either.

of course it does

singpolyma, until one day someone adds some dangerous stuff

unless you use the actual real new OMEMO which does full stanza encryption.

either way stuff moves to mls /shrug

or someone ports the code to a different environment

394 does not add stuff from the message, its just metadata

> singpolyma, until one day someone adds some dangerous stuff That would affect every android app though not just us ↺

while xhtml adds the full plaintext

not saying xhtml-im is bad or anything, i dont care

xhtml can be fixed

i just say, the traction is bound to omemo:2

which also is a huge task

Yes, twomemo or ox or mls. Something sane

you cant improve 394 enough to make it good without making it a complete mess

so thats why im saying, it will not happen anytime soon

lovetox, in the meantime, you can already support the common case where OMEMO isn’t used.

need to write a html parser, and a mapping to my ui framework thats supports unlimited nesting of all kind of elements

not sure i want to get into this really

> (If you want the fallback.) i'm correct to assume that 0071's fallback is simply to ignore unknown or unsupported (due to security-imposed or interface limitations) tags and display their innertext as-is?

50% of xhtml-im i dont want to support

This isn’t HTML, this is proper XHTML.

lovetox, pango’s markup format is quite close to HTML fwiw.

opal, correct.

awesome, so 0394's start/end annotations are overkill and prone to more developer error in a sense

opal, see XEP-0071 example 8.

> and it does not really matter if you build upon html, or some new invented language even 0393 is "some [...] invented language" but not new as you mentioned before, and it requires its own parsing, so i dont see how a revised 0071 would be any different, and certainly 0394 would require much of the same

Link Mauve, ah so the plaintext preserves semantics of some tags in this case, at the cost of duplicating the entire message body

that is one perk of 0394, deduplication, but assuming stanzas are compressed over the wire, this might not be a huge concern either way

> 50% of xhtml-im i dont want to support i dont blame you

isn't it divided into modules?

opal, but stanzas are not compressed

well damn :D

html and compression are both security hazards that we removed

me and my assumptions

is, say, stanza-level zlib compression a security hazard? i thought it was just TLS compression that was a mistake

https://blog.thijsalkema.de/blog/2014/08/07/https-attacks-and-xmpp-2-crime-and-breach/

ty

so BREACH and not CRIME is what im looking into

>If you absolutely have to use compression, disable TLS compression and use XEP-0138 and do a full flush after every stanza. that makes perfect sense ok, now i see how theyre both an equal concern

this method to simply ignore tags would work pretty badly for the case of lists for example

make a list of all the block elements, if you don't understand more than that treat them as <div>, assume anything else are <span>

or just turn anything unknow into <span>-equivalents and send newlines and whitespace that makes sense if all tags are stripped

since xmpp preserves whitespace unlike "real" (x)html, it'd probably suffice for the sender to have each <li/> on its own line, but then you lose the numbering/bulleting information

as an anecdote, html5's <q/> tag is a blessing and a curse, seeing as css is required to change what those quotes actually are, and without css, semantic information is lost

lovetox, fwiw, '394 has the same issue.

tho then it's probably marginally more explicit that you should make the <body> make sense without the formatting?

isnt that the case anyway? that a client needs to implement the whole markup xep otherwise there needs to be a good fallback?

0394 seems like it wouldnt lend way to lists of any type since the * or the 1. 2. 3. are part of the original body still

we could be dicks and make the server implementations translate lists and such to plaintext variants :D

for clients that dont advertise support

personally it would make sense to reuse xhtml in other places too.

"for clients that dont advertise support" someday I'd really like to be able to do this again. For now you'll just get answers like "something carbons something MAM"

but maybe its too late for that

kind of like core xep and extensions but alas something something cant have nice things

>someday I'd really like to be able to do this again. For now you'll just get answers like "something carbons something MAM" not really clear what youre responding to but the mere existence of e2ee makes the server unable to do anything to modify the messages anyway; it was just a joke lol

What I meant is, in the context of unencrypted content, it's often hard to predict what kind of device will read what you send. If at the time of sending all recipient's online devices support the feature, nothing guarantees that they aren't going to fire up another device that doesn't, and fetch history

yeah

(Well and it's the same for encrypted content anyway, no difference there)