XSF Discussion - 2019-07-29

Dave, I got your one on one, but my reply isn't being delivered.

This is an accurate depiction of why matrix wins over XMPP.

Yes, this is bad, although I've never experienced it with anyone else than Dave

Which I suspect is running non-production code

non-production s2s code

I'm guessing he's running s2s through Metre

👍

I've experienced asymmetric s2s with other people than Dave.

I'm sure Matrix is bug free. Let's just quit.

Yes. Or let's maybe fix the reliability issues that we are mostly ignoring for two decades now.

we did s2s interop testing... a decade ago

I've seen various proposals being discussed, here, on list, and at summits, but there's a whole lot of whataboutism and stuff, and not a lot of just experimenting. Dave's Metre is at least an attempt to figure out all the weird corners.

fippo: this is not about protocol-level interop, but about network connectivity corner cases, or connections being stuck going unnoticed

Things like the periodic pinger module of some widely-used server implementation which will _ping_ the other server, but won't act in any way on a timeout.

I'm also not talking just about s2s, but good examples are MIX and SASL2.

Ge0rG, there are still very few servers which support bidi, yours doesn’t for instance.

It’s the first step towards no-asymmetric s2s. ✏

(Words are hard.)

ge0rg: true, we just tested the basics. and bidi is an attempt to solve some of those issues

Link Mauve: maybe because mod_bidi is a community module that's not enabled by default, and nobody can quite tell whether it has side-effects?

Link Mauve: do you have stats on how many servers have bidi enabled?

Ge0rG, from linkmauve.fr I see 19, out of 177+181 open s2s.

I’m not sure in which direction these 19 count.

so it's ~10%

Maybe it's working perfectly, or maybe it's got a can of worms of its own.

On JabberFR I see 27, out of 1122+1112 s2s.

But now I will have another corner-case to consider when debugging s2s issues.

Getting bidi right turns out to be not as straightforward as one might think.

I'm enabling mod_bidi now. Let's wait and see.

Tell me when you’re done.

Link Mauve: done.

I don’t see a bidi s2s being established.

Even after closing the connection and letting it be reestablished.

apparently, mod_bidi didn't get loaded on the MUC domain.

Oh, that’d be the reason why.

Link Mauve: try again

Yay, perfect. :)

It also establishes much faster.

About 1s vs. 4s.

mod_admin_telnet won't show it as bidi, though.

Sigh.

It doesn’t here either, weird.

Link Mauve: would you pull a number please?

I was already at it. :)

Link Mauve: 👍

Ge0rG, https://issues.prosody.im/1403

Yay. https://tools.ietf.org/html/rfc5646 only defines "-" as a delimiter, not "_"

Ah, XPG vs IETF.

Also Java.

I think Java supports both.

yeah, apparently what I need to call is `Locale.toLanguageTag()`

Link Mauve, Ge0rG: mod_bidi should show in the admin console? I think I added that

pep.: nope. | <- linkmauve.fr [s2sin563bd6fc3640] (authenticated) (encrypted) (IPv6)

at least not in 0.11

Right, If it is it will be in trunk

Who cares about releases :p

🤷

Though Link Mauve would be using trunk

so if he can't see it, and I can't see it, it must be broken

pep., maybe a too old trunk.

mod_bidi Updated: 5 years ago

| jabberfr.org | <- yax.im [s2sin55c473563c00] (authenticated) (encrypted) (IPv6) (bidi)

That’s on JabberFR.

So maybe it’s already fixed.

are there two mod_bidi's?

NAFAIK.

No

The fix is in the telnet console

is there a telnet console in prosody-modules?

What, no

It's in core?

hg is so slow on my server…

Just spawning the python2 process takes like ten seconds.

added 246 changesets with 270 changes to 79 files

RIIR in 3... 2... 1...

Nope, still not fixed.

jonas’, I wish they’d get at it faster. :(

https://www.mercurial-scm.org/wiki/OxidationPlan

speaking of rust, my hand mixer’s mixing things are rusty :(

and here people wonder why I don’t like rust!!k

"Buster (Debian 10): Rust 1.28 (https://packages.debian.org/source/buster/rustc)", same for RHEL :((

xDDD

Maybe in two years they’ll be able to run today’s xmpp-rs.

What's that, being upset that it doesn't have the latest bleeding edge Rust?

It also desn't have the latest bleeding edge Go

this is not programming@ by the way

Zash, the latest stable is 1.36 :)

jonas’, I'll stop here, I was just reacting to the above :P

jonas’, oops, sorry.

pep., testing suggests you display (bidi) for incoming s2s, but not for outgoing.

Put that in the issue I guess

It’s already there.

✏

In the meantime you're not allowed to initiate bidi, you must only accept it :P

So that it gets displayed

dffdd

Indeed

PSA: I got my MUA fixed apparently and I’ll take care of the editor backlog tomorrow afternoon or tonight.

👍

small question regarding https://xmpp.org/extensions/xep-0060.html#subscriber-retrieve-requestrecent, when doing a max_items requests, the order should be most recent on top ?

in the example, it is newest at end of list

to me it's an issue

as a client I don't want to retrieve all the node items with their payloads (for performance purposes)

i can't find any text mandating a particular result ordering. but everything is shown as always oldest to newest

so I retrieve only the item ids, then check which items are missing and then retrieve independently the items that I need

where max_items will just give you the page of results at the very end in that sort order

yes but this order is not specified anywhere

ejabberd actually returns the list the other way around

ahh, then yeah. this is a gap in spec