XSF Discussion - 2020-03-28

For the Berlin Sprint I created a little open-mind question. As it is made online now, everyone can particiate. Feel free to state your visions on XMPP for the next years: https://yourpart.eu/p/xmpp-2020-berlin

> por que todos hablan español? No español todo, just making fun

Daniel, would it be terrible if XEP-0333 said (along the lines of) "In a MUC, use ids in this order of preference: stanza-id, origin-id, @id." ?

I'd like a world where the MUC itself is able to track read status of users, and I can achieve that today while only aiming for compat with Converse.js (which doesn't use origin-id in markers)

But then it loses compat with Conversations

MattJ: yeah I guess that be OK

Not sure how best to keep backwards-compatibility, but I'll have a think about it all

I really think we need an informational XEP on IDs in general anyway

having an either-or situtation is also bad on the parsing end

I just realised markers in MUC aren't at all specified anyway

MattJ: we need to introduce a new unified ID that removes all the drawbacks of pre-existing ID schemes

Good idea

It shall be called "message ID"

Perfect

Can it also be used on presence?

MattJ, so you plan that a client references a stanza-id in its read marker?

In a MUC, yes

ok and the message-id is bad why?

You mean the id attribute?

yes, not Ge0rG new thing :d

;)

Because it is optional, and not guaranteed to be unique

If two users send id='foo' and both add <markable/> nobody can know what <received id='foo'/> means

hm indeed

MattJ [15:16]: > Can it also be used on presence? Yes, but the name shall remain the same.

why not just adding a new MUC feature that lets the MUC add the message-id?

MattJ, tbh others are just as optional. You need to implement the XEPs :)

and sidestep all the problems

It can do that now, if it wants (if it doesn't advertise muc#stable-id)

Conversations bypasses this by using origin-id instead

Now the MUC /could/ rewrite the origin-id, but that would be very bad :)

hm MattJ stable-id does only mean the MUC has to reflect the user chosen id

exactly the opposite of what we want

Oh, but you mean it might send a different id to other occupants? Right

I think everything is simpler if we just say stanza-id should be used

yes and just disable markers if MAM is not activated

Works for me :)

or fall back to message-id

i already save message-id and stanza-id

i somehow beeing reluctant to add a third database field for origin-id

every client that uses origin-id should set the message-id accordingly

I agree (though the XEP still doesn't say that :( )

yeah but thats not a big problem, really thats a nice to have thing a read marker

if it does not work perfectly because there are malicious clients in some MUCs

i dont really care ..

🤔

Neustradamus: of course we can, but how do you think it should work?

When there are S2S TLS problems, and when an user@xmpp1.tld try to join a mucroom@conference.xmpp2.tld, it is not possible and the XMPP client has not an error. Can you add new informations to inform XMPP client? ✏

oh I thought it's Psi channel, but the question is anyway valid :)

I have created: https://github.com/xsf/xeps/issues/916 Note: https://github.com/xsf/rfcs/issues not updated since several years.

Neustradamus: the server on xmpp1.tld will create a presence error response to the user

Ge0rG: For example an user@jabber.org -> muc@muc.xmpp.org The log on muc.xmpp.org: - User has joined - User has left Client has not error and the client always tries but it has already failed.

> The log on muc.xmpp.org: > - User has joined > - User has left I'd assume that this means that there are no real s2s issues?

I mean, apparently the users server can reach the muc service

Probably it means the s2s is one way

ah that may be

So server1 sees no issue, server2 is unable to send an error back to the user because it can't establish a connection

Right

So server1 should probably return some timeout error to the client?

server1 is not performing any operation, the connection server1->server2 succeeds

at the MUC level, the client could implement a timeout

#MIXWhen?

:)

MattJ: shouldn't server2 close the incoming connection when dialback fails?

MIX doesn't solve this

Ge0rG, there is no dialback, auth happened via TLS

MIX has its own share of fun failure modes when s2s fails :)

#198s2sWhen?

jonas’: it also has all the previously existing failure modes

MattJ: so we can't do anything against asymmetric s2s?

does 198s2s even help with this? it's not like server2->server1 was even a thing to start with

Daniel, I'd say bidi rather

https://xmpp.org/extensions/xep-0288.xml !

server2 could only accept the connection if it can make a return one

Some people think bidi is the solution

bidi just makes it worse IMHO

It just moves the failure to some other point in time

MattJ, accept as in accept(2)?

MattJ, bidi would make the failure more discoverable though

I'd say possibly less(?)

jonas’, no, it would make a return connection before informing the incoming stream that it is authenticated

either it succeeds (server1->server2) or it fails (server2->server1). There’s no half-open state anymore.

With bidi you either get a working connection or not. No half-failuers.

jonas’, it makes it less discoverable

No half failures, but then you're not seeing server2->server1 fails

In this case, let's assume you have bidi. Joining the MUC will work!

pep., the sender of stanzas from server2 sees it though

and then later when the s2s connection closes for whatever reason, it fails

jonas’, assuming they initiate the connection

pep., if they don’t, there’s nothing which gets lost.

MattJ, sure, you drop out of the room. That’s discoverable.

Sure, but I get why MattJ is saying "moves the failure to a later time"

My preference would be not being able to join the room with a broken setup

I do think no half-failures is better

BIDI provides a *consistent* view across the system at any point in time, which I think is valuable.

Instead of pretending it's not broken

MattJ, you know what gets you that? Dialback.

I will not be convinced that "It fails when I send messages to you, unless you sent a message to me first within the past N minutes" is a world I want to live in

MattJ, I slightly prefer that world over "I can send messages to you always, but you can’t send messages to me at all"

But that one is so simple

You can send messages out? Ok, outgoing connections work

You can't receive messages in? Ok, your firewall or DNS or cert is messed up

With bidi, how do you even debug that?

Without a hack to disable bidi on the server for testing

By looking at your server logs?

Yeah, that's not the world I want to live in (telling people to look at server logs)

But I think you miss my point

If bidi is enabled, I test outgoing, and there is no way to test incoming without force-closing the outgoing connection

It will just appear like it works anyway

Until later, when it randomly doesn't (but you won't know, because by then nobody will be able to contact you)

Well. Trade-offs be that.

Thing that could be done.. relax the requirement for error replies to be sent on a stream in the proper direction.

Hm, but that doesn't fix MUC

Tool that tests your DNS and connectivity from the outside and gives you a green checkmark?

like xmpp.net?

how useful would it be if there was a public HTTP API endpoint which would try to establish an S2S connection to a given domain and report the results?

more of a "yes/no" type result, not full cipherlist

So useful I almost made this already :)

what if I told you all I need to do is open a port in my firewall?

Hm, I did have a thing like this but it was hooked up to a DANE-only server for testing your DANE validation stuff.

`curl io.sotecware.net:9604/probe\?module=s2s_normal\&target=xmpp:muc.xmpp.org`

(now with IPv6)

Hol up what

> Secure s2sin_unauthed connection from blackbox@zash.se to zash.se failed.

that sounds wrong

but my prober agrees

Verily

I'm surprised Prosody don't reject the @ in the stream.

so I take it that I should spin up a second instance of this and expose it to the world?

maybe behind a reverse proxy on the search.jabber.network domain

jonas’: What's this good for? Checking if the MUC component is reachable by muclumbus?

!XSF_Martin, I could see integration in tools like `prosodyctl check`

Hmm, but not every prosody instance will have the MUC component reachable from external I guess.

!XSF_Martin, in that case, don’t probe the MUC component but something else ;)

!XSF_Martin, it’s not specfic to MUC at all

Yeah, but would prosodyctl know if you have SRV records for you MUC component?

yes, it already checks that

(IIRC)

Ok

`prosodyctl check dns` already checks everything, but it naturally can't test that it really works from the outside

the tool is also 100% unrelated to search.jabber.network

probe.jabber.network? poke.?

Hmm, chat.mdosch.de is probably cached because it's listed at s.j.o but holy crap, connecting to mdosch.de takes ages

Zash, bikeshedding!

martin@schlepptop ~ % curl -6 io.sotecware.net:9604/probe\?module=s2s_normal\&target=xmpp:chat.mdosch.de # HELP probe_duration_seconds Returns how long the probe took to complete in seconds # TYPE probe_duration_seconds gauge probe_duration_seconds 0.527403685 # HELP probe_success Displays whether or not the probe was a success # TYPE probe_success gauge probe_success 0 martin@schlepptop ~ % curl -6 io.sotecware.net:9604/probe\?module=s2s_normal\&target=xmpp:mdosch.de # HELP probe_duration_seconds Returns how long the probe took to complete in seconds # TYPE probe_duration_seconds gauge probe_duration_seconds 4.191193315 # HELP probe_success Displays whether or not the probe was a success # TYPE probe_success gauge probe_success 0

!XSF_Martin, it doesn’t cache anything

it’s a fresh connection every time

it’s, again, 100% unrelated to search.jabber.network

(except that it runs on the same box)

also, note that both probes fail

jonas’, how far does it go with the s2s?

Ugh, I thought returning 0 is SUCCESS

Zash, good question!

Zash, I think it only does STARTTLS

!XSF_Martin, using integers as bools do this to you yeah :P

jonas’: But it doesn't provide a certificate, and also the wrong stream name.

pep., floats, not integers

sure

;>

>probe_duration_seconds 8.2175e-05

And why the heck does nameprep allow '@' ?

Zash, no, it doesn’t provide a certificate (it also doesn’t start authentication). Wrong stream name being?

uh, was that blackbox@zash.se from me?

jonas’, blackbox@ name of thing you probe

jonas’: Yes

uh

how did that happen :)

>Mar 28 19:43:09 s2sin5628b6007350 info Incoming s2s stream blackbox@chat.mdosch.de->chat.mdosch.de closed: Your server's certificate could not be validated

Zash: jonas’: This? ^

That

jonas’, do you see stream errors? Prosody trunk should be sending nicer descriptions there :)

hah: https://github.com/horazont/prometheus-xmpp-blackbox-exporter/blob/master/prober/dial.go#L82

hm, so this is going to break now that dialback is going to be phased out?

That can't possibly have worked with dialback already

I use it all the time

also, the curl command I pasted earlier also returns with success

Because it gets past the TLS and then you simply don't authenticate?

Whereas my and !XSF_Martin's servers abort the connection at that stage for not having a valid certificate (none at all in this case)

away for tonight

We didn't target at scaring you away.

But enjoy your evening jonas’. Bye. :)

On a tangental topic, I set up something like badssl.com for xmpp: https://badxmpp.eu/

fancy

The bulb should look bad, so let it wear a hoody!

😃

Zash, nice!

Sent a longer announcement to jdev@

Zash: oooh been wanting to set up something like that for awhile, specifically to test various srv fallback behavior in both c2s and s2s

Not the same but related I guess

moparisthebest: I want to expand weird SRV setups, just haven't gotten that far yet. If you want to help and/or suggest specific SRV setups that'd be cool.

Zash: for starters, I've seen many give up if only the TCP connection succeeds, but something else is wrong, even if the certificate is wrong, that should still trigger fallback to the next record

Yeah. There's one thing already that's just pointed at a http port. A SRV setup with [ http, normal xmpp ] would be interesting.

yep, or a xmpps-client with [ https, xmpps ] which is what happens in practice if something requires ALPN but the client doesn't send it, dino fails here

I still have deep on my list to write a, maybe informational, xep with guidelines about when to continue SRV fallback and when to abort