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
emus
> por que todos hablan español?
No español todo, just making fun
werdanhas left
Jeybehas left
Jeybehas joined
Jeybehas left
Jeybehas joined
Shellhas joined
rionhas left
rionhas joined
Shellhas left
Shellhas joined
Jeybehas left
Jeybehas joined
calvinhas joined
mukt2has joined
waqashas left
pdurbinhas left
Jeybehas left
MattJ
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." ?
Jeybehas joined
MattJ
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)
MattJ
But then it loses compat with Conversations
mukt2has left
Daniel
MattJ: yeah I guess that be OK
MattJ
Not sure how best to keep backwards-compatibility, but I'll have a think about it all
MattJ
I really think we need an informational XEP on IDs in general anyway
werdanhas joined
Shellhas left
Shellhas joined
adiaholic_has left
Jeybehas left
Jeybehas joined
Daniel
having an either-or situtation is also bad on the parsing end
calvinhas left
MattJ
I just realised markers in MUC aren't at all specified anyway
adiaholic_has joined
j.rhas left
j.rhas joined
Jeybehas left
Jeybehas joined
neshtaxmpphas left
neshtaxmpphas joined
Jeybehas left
Jeybehas joined
Jeybehas left
Nekithas left
Jeybehas joined
Jeybehas left
Jeybehas joined
emushas left
neshtaxmpphas left
neshtaxmpphas joined
Ge0rG
MattJ: we need to introduce a new unified ID that removes all the drawbacks of pre-existing ID schemes
MattJ
Good idea
Ge0rG
It shall be called "message ID"
MattJ
Perfect
MattJ
Can it also be used on presence?
lovetox
MattJ, so you plan that a client references a stanza-id in its read marker?
MattJ
In a MUC, yes
lovetox
ok and the message-id is bad why?
emushas joined
MattJ
You mean the id attribute?
lovetox
yes, not Ge0rG new thing :d
MattJ
;)
MattJ
Because it is optional, and not guaranteed to be unique
MattJ
If two users send id='foo' and both add <markable/> nobody can know what <received id='foo'/> means
lovetox
hm indeed
Ge0rG
MattJ [15:16]:
> Can it also be used on presence?
Yes, but the name shall remain the same.
adiaholic_has left
lovetox
why not just adding a new MUC feature that lets the MUC add the message-id?
pep.
MattJ, tbh others are just as optional. You need to implement the XEPs :)
lovetox
and sidestep all the problems
MattJ
It can do that now, if it wants (if it doesn't advertise muc#stable-id)
adiaholic_has joined
MattJ
Conversations bypasses this by using origin-id instead
werdanhas left
MattJ
Now the MUC /could/ rewrite the origin-id, but that would be very bad :)
lovetox
hm MattJ stable-id does only mean the MUC has to reflect the user chosen id
lovetox
exactly the opposite of what we want
MattJ
Oh, but you mean it might send a different id to other occupants? Right
MattJ
I think everything is simpler if we just say stanza-id should be used
lovetox
yes and just disable markers if MAM is not activated
MattJ
Works for me :)
lovetox
or fall back to message-id
lovetox
i already save message-id and stanza-id
lovetox
i somehow beeing reluctant to add a third database field for origin-id
xelxebarhas left
lovetox
every client that uses origin-id should set the message-id accordingly
MattJ
I agree (though the XEP still doesn't say that :( )
lovetox
yeah but thats not a big problem, really thats a nice to have thing a read marker
lovetox
if it does not work perfectly because there are malicious clients in some MUCs
lovetox
i dont really care ..
lorddavidiiihas left
Alexhas left
Alexhas joined
lorddavidiiihas joined
xelxebarhas joined
andrey.ghas left
serge90has left
calvinhas joined
serge90has joined
infnullhas joined
mukt2has joined
Jeybehas left
Jeybehas joined
pdurbinhas joined
lovetoxhas left
mukt2has left
lovetoxhas joined
pdurbinhas left
lskdjfhas left
Jeybehas left
larmahas left
Jeybehas joined
lskdjfhas joined
andyhas left
larmahas joined
Maranda
🤔
andyhas joined
Jeybehas left
Jeybehas joined
Jeybehas left
Jeybehas joined
paulhas left
paulhas joined
j.rhas left
Jeybehas left
Jeybehas joined
mukt2has joined
j.rhas joined
archas left
archas joined
Jeybehas left
adiaholic_has left
adiaholic_has joined
Jeybehas joined
Neustradamus
When there are S2S TLS problems, and when an user@xmpp.tld try to join a mucroom@conference.xmpp.tld, it is not possible and the XMPP client has not an error.
Can you add new informations to inform XMPP client?✎
rion
Neustradamus: of course we can, but how do you think it should work?
Neustradamus
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? ✏
rion
oh I thought it's Psi channel, but the question is anyway valid :)
mukt2has left
Jeybehas left
Jeybehas joined
remkohas joined
Jeybehas left
Jeybehas joined
oxpahas joined
Neustradamus
I have created: https://github.com/xsf/xeps/issues/916
Note: https://github.com/xsf/rfcs/issues not updated since several years.
gavhas left
gavhas joined
alexishas left
Jeybehas left
Ge0rG
Neustradamus: the server on xmpp1.tld will create a presence error response to the user
Jeybehas joined
calvinhas left
Jeybehas left
Jeybehas joined
Neustradamus
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.
Jeybehas left
Jeybehas joined
vanitasvitae
> 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?
vanitasvitae
I mean, apparently the users server can reach the muc service
MattJ
Probably it means the s2s is one way
vanitasvitae
ah that may be
MattJ
So server1 sees no issue, server2 is unable to send an error back to the user because it can't establish a connection
vanitasvitae
Right
vanitasvitae
So server1 should probably return some timeout error to the client?
MattJ
server1 is not performing any operation, the connection server1->server2 succeeds
MattJ
at the MUC level, the client could implement a timeout
vanitasvitae
#MIXWhen?
MattJ
:)
Ge0rG
MattJ: shouldn't server2 close the incoming connection when dialback fails?
MattJ
MIX doesn't solve this
MattJ
Ge0rG, there is no dialback, auth happened via TLS
jonas’
MIX has its own share of fun failure modes when s2s fails :)
Daniel
#198s2sWhen?
Ge0rG
jonas’: it also has all the previously existing failure modes
Ge0rG
MattJ: so we can't do anything against asymmetric s2s?
pep.
does 198s2s even help with this? it's not like server2->server1 was even a thing to start with
pep.
Daniel, I'd say bidi rather
Zash
https://xmpp.org/extensions/xep-0288.xml !
MattJ
server2 could only accept the connection if it can make a return one
MattJ
Some people think bidi is the solution
MattJ
bidi just makes it worse IMHO
MattJ
It just moves the failure to some other point in time
jonas’
MattJ, accept as in accept(2)?
jonas’
MattJ, bidi would make the failure more discoverable though
pep.
I'd say possibly less(?)
MattJ
jonas’, no, it would make a return connection before informing the incoming stream that it is authenticated
jonas’
either it succeeds (server1->server2) or it fails (server2->server1). There’s no half-open state anymore.
Zash
With bidi you either get a working connection or not. No half-failuers.
MattJ
jonas’, it makes it less discoverable
pep.
No half failures, but then you're not seeing server2->server1 fails
MattJ
In this case, let's assume you have bidi. Joining the MUC will work!
jonas’
pep., the sender of stanzas from server2 sees it though
MattJ
and then later when the s2s connection closes for whatever reason, it fails
pep.
jonas’, assuming they initiate the connection
jonas’
pep., if they don’t, there’s nothing which gets lost.
jonas’
MattJ, sure, you drop out of the room. That’s discoverable.
pep.
Sure, but I get why MattJ is saying "moves the failure to a later time"
MattJ
My preference would be not being able to join the room with a broken setup
pep.
I do think no half-failures is better
jonas’
BIDI provides a *consistent* view across the system at any point in time, which I think is valuable.
MattJ
Instead of pretending it's not broken
Zash
MattJ, you know what gets you that? Dialback.
MattJ
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
jonas’
MattJ, I slightly prefer that world over "I can send messages to you always, but you can’t send messages to me at all"
MattJ
But that one is so simple
MattJ
You can send messages out? Ok, outgoing connections work
MattJ
You can't receive messages in? Ok, your firewall or DNS or cert is messed up
MattJ
With bidi, how do you even debug that?
MattJ
Without a hack to disable bidi on the server for testing
Zash
By looking at your server logs?
MattJ
Yeah, that's not the world I want to live in (telling people to look at server logs)
MattJ
But I think you miss my point
MattJ
If bidi is enabled, I test outgoing, and there is no way to test incoming without force-closing the outgoing connection
MattJ
It will just appear like it works anyway
MattJ
Until later, when it randomly doesn't (but you won't know, because by then nobody will be able to contact you)
archas left
archas joined
xsfhas left
Zash
Well. Trade-offs be that.
emushas left
Edlisonhas joined
Edlisonhas left
remkohas left
remkohas joined
werdanhas joined
Dvdhas joined
Zash
Thing that could be done.. relax the requirement for error replies to be sent on a stream in the proper direction.
Zash
Hm, but that doesn't fix MUC
Zash
Tool that tests your DNS and connectivity from the outside and gives you a green checkmark?
Dvdhas left
oxpahas left
oxpahas joined
remkohas left
Jeybehas left
Jeybehas joined
mukt2has joined
emushas joined
mukt2has left
remkohas joined
oxpahas left
oxpahas joined
Jeybehas left
Jeybehas joined
calvinhas joined
Jeybehas left
Jeybehas joined
Marandahas left
Marandahas joined
Jeybehas left
Jeybehas joined
Jeybehas left
Jeybehas joined
jonas’
like xmpp.net?
jonas’
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?
jonas’
more of a "yes/no" type result, not full cipherlist
Zash
So useful I almost made this already :)
jonas’
what if I told you all I need to do is open a port in my firewall?
Zash
Hm, I did have a thing like this but it was hooked up to a DANE-only server for testing your DANE validation stuff.
> Secure s2sin_unauthed connection from blackbox@zash.se to zash.se failed.
jonas’
that sounds wrong
jonas’
but my prober agrees
Zash
Verily
Zash
I'm surprised Prosody don't reject the @ in the stream.
jonas’
so I take it that I should spin up a second instance of this and expose it to the world?
jonas’
maybe behind a reverse proxy on the search.jabber.network domain
!XSF_Martin
jonas’: What's this good for? Checking if the MUC component is reachable by muclumbus?
jonas’
!XSF_Martin, I could see integration in tools like `prosodyctl check`
!XSF_Martin
Hmm, but not every prosody instance will have the MUC component reachable from external I guess.
jonas’
!XSF_Martin, in that case, don’t probe the MUC component but something else ;)
jonas’
!XSF_Martin, it’s not specfic to MUC at all
!XSF_Martin
Yeah, but would prosodyctl know if you have SRV records for you MUC component?
jonas’
yes, it already checks that
jonas’
(IIRC)
!XSF_Martin
Ok
Zash
`prosodyctl check dns` already checks everything, but it naturally can't test that it really works from the outside
jonas’
the tool is also 100% unrelated to search.jabber.network
Zash
probe.jabber.network? poke.?
!XSF_Martin
Hmm, chat.mdosch.de is probably cached because it's listed at s.j.o but holy crap, connecting to mdosch.de takes ages
jonas’
Zash, bikeshedding!
!XSF_Martin
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
jonas’
!XSF_Martin, it doesn’t cache anything
testhas joined
jonas’
it’s a fresh connection every time
jonas’
it’s, again, 100% unrelated to search.jabber.network
jonas’
(except that it runs on the same box)
jonas’
also, note that both probes fail
Zash
jonas’, how far does it go with the s2s?
!XSF_Martin
Ugh, I thought returning 0 is SUCCESS
jonas’
Zash, good question!
testhas left
testhas joined
jonas’
Zash, I think it only does STARTTLS
pep.
!XSF_Martin, using integers as bools do this to you yeah :P
Zash
jonas’: But it doesn't provide a certificate, and also the wrong stream name.
jonas’
pep., floats, not integers
pep.
sure
jonas’
;>
!XSF_Martin
>probe_duration_seconds 8.2175e-05
Zash
And why the heck does nameprep allow '@' ?
jonas’
Zash, no, it doesn’t provide a certificate (it also doesn’t start authentication). Wrong stream name being?
jonas’
uh, was that blackbox@zash.se from me?
Zash
jonas’, blackbox@ name of thing you probe
Zash
jonas’: Yes
jonas’
uh
jonas’
how did that happen :)
!XSF_Martin
>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
!XSF_Martin
Zash: jonas’: This? ^
Zash
That
testhas left
Zash
jonas’, do you see stream errors? Prosody trunk should be sending nicer descriptions there :)
hm, so this is going to break now that dialback is going to be phased out?
Zash
That can't possibly have worked with dialback already
jonas’
I use it all the time
jonas’
also, the curl command I pasted earlier also returns with success
Zash
Because it gets past the TLS and then you simply don't authenticate?
Zash
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)
jonas’
away for tonight
!XSF_Martin
We didn't target at scaring you away.
!XSF_Martin
But enjoy your evening jonas’. Bye. :)
mukt2has joined
jonas’contemplates whether to leave that port open
pdurbinhas joined
Jeybehas left
Jeybehas joined
Jeybehas left
mukt2has left
Jeybehas joined
andrey.ghas joined
calvinhas left
Jeybehas left
serge90has left
Jeybehas joined
pdurbinhas left
Douglas Terabytehas left
serge90has joined
Douglas Terabytehas joined
Jeybehas left
lorddavidiiihas left
Jeybehas joined
lorddavidiiihas joined
Jeybehas left
archas left
Jeybehas joined
archas joined
Jeybehas left
Zash
On a tangental topic, I set up something like badssl.com for xmpp: https://badxmpp.eu/
Jeybehas joined
pep.
fancy
Jeybehas left
Jeybehas joined
!XSF_Martin
The bulb should look bad, so let it wear a hoody!
!XSF_Martin
😃
!XSF_Martinhas left
archas left
archas joined
archas left
archas joined
!XSF_Martinhas joined
!XSF_Martinhas left
Jeybehas left
Jeybehas joined
Nekithas joined
waqashas joined
!XSF_Martinhas joined
adiaholic_has left
adiaholic_has joined
mukt2has joined
xsfhas joined
jonas’
Zash, nice!
Nekithas left
Nekithas joined
!XSF_Martinhas left
Jeybehas left
!XSF_Martinhas joined
Jeybehas joined
!XSF_Martinhas left
Zash
Sent a longer announcement to jdev@
!XSF_Martinhas joined
mukt2has left
Jeybehas left
moparisthebest
Zash: oooh been wanting to set up something like that for awhile, specifically to test various srv fallback behavior in both c2s and s2s
moparisthebest
Not the same but related I guess
Jeybehas joined
Yagizahas left
calvinhas joined
!XSF_Martinhas left
!XSF_Martinhas joined
!XSF_Martinhas left
!XSF_Martinhas joined
Zash
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.
Jeybehas left
Jeybehas joined
eevvoorhas joined
Jeybehas left
calvinhas left
calvinhas joined
Jeybehas joined
moparisthebest
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
Jeybehas left
Jeybehas joined
adiaholic_has left
Zash
Yeah. There's one thing already that's just pointed at a http port. A SRV setup with [ http, normal xmpp ] would be interesting.
Jeybehas left
moparisthebest
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
Jeybehas joined
etahas left
etahas joined
moparisthebest
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