emusFor 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
MattJDaniel, 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
MattJI'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)
MattJBut then it loses compat with Conversations
mukt2has left
DanielMattJ: yeah I guess that be OK
MattJNot sure how best to keep backwards-compatibility, but I'll have a think about it all
MattJI 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
Danielhaving an either-or situtation is also bad on the parsing end
calvinhas left
MattJI 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
Ge0rGMattJ: we need to introduce a new unified ID that removes all the drawbacks of pre-existing ID schemes
MattJGood idea
Ge0rGIt shall be called "message ID"
MattJPerfect
MattJCan it also be used on presence?
lovetoxMattJ, so you plan that a client references a stanza-id in its read marker?
MattJIn a MUC, yes
lovetoxok and the message-id is bad why?
emushas joined
MattJYou mean the id attribute?
lovetoxyes, not Ge0rG new thing :d
MattJ;)
MattJBecause it is optional, and not guaranteed to be unique
MattJIf two users send id='foo' and both add <markable/> nobody can know what <received id='foo'/> means
lovetoxhm indeed
Ge0rGMattJ [15:16]:
> Can it also be used on presence?
Yes, but the name shall remain the same.
adiaholic_has left
lovetoxwhy 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 :)
lovetoxand sidestep all the problems
MattJIt can do that now, if it wants (if it doesn't advertise muc#stable-id)
adiaholic_has joined
MattJConversations bypasses this by using origin-id instead
werdanhas left
MattJNow the MUC /could/ rewrite the origin-id, but that would be very bad :)
lovetoxhm MattJ stable-id does only mean the MUC has to reflect the user chosen id
lovetoxexactly the opposite of what we want
MattJOh, but you mean it might send a different id to other occupants? Right
MattJI think everything is simpler if we just say stanza-id should be used
lovetoxyes and just disable markers if MAM is not activated
MattJWorks for me :)
lovetoxor fall back to message-id
lovetoxi already save message-id and stanza-id
lovetoxi somehow beeing reluctant to add a third database field for origin-id
xelxebarhas left
lovetoxevery client that uses origin-id should set the message-id accordingly
MattJI agree (though the XEP still doesn't say that :( )
lovetoxyeah but thats not a big problem, really thats a nice to have thing a read marker
lovetoxif it does not work perfectly because there are malicious clients in some MUCs
lovetoxi 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
NeustradamusWhen 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?
rionNeustradamus: of course we can, but how do you think it should work?
NeustradamusWhen 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?
rionoh 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
NeustradamusI 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
Ge0rGNeustradamus: the server on xmpp1.tld will create a presence error response to the user
Jeybehas joined
calvinhas left
Jeybehas left
Jeybehas joined
NeustradamusGe0rG: 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?
vanitasvitaeI mean, apparently the users server can reach the muc service
MattJProbably it means the s2s is one way
vanitasvitaeah that may be
MattJSo server1 sees no issue, server2 is unable to send an error back to the user because it can't establish a connection
vanitasvitaeRight
vanitasvitaeSo server1 should probably return some timeout error to the client?
MattJserver1 is not performing any operation, the connection server1->server2 succeeds
MattJat the MUC level, the client could implement a timeout
vanitasvitae#MIXWhen?
MattJ:)
Ge0rGMattJ: shouldn't server2 close the incoming connection when dialback fails?
MattJMIX doesn't solve this
MattJGe0rG, there is no dialback, auth happened via TLS
jonas’MIX has its own share of fun failure modes when s2s fails :)
Daniel#198s2sWhen?
Ge0rGjonas’: it also has all the previously existing failure modes
Ge0rGMattJ: 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
Zashhttps://xmpp.org/extensions/xep-0288.xml !
MattJserver2 could only accept the connection if it can make a return one
MattJSome people think bidi is the solution
MattJbidi just makes it worse IMHO
MattJIt 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(?)
MattJjonas’, 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.
ZashWith bidi you either get a working connection or not. No half-failuers.
MattJjonas’, it makes it less discoverable
pep.No half failures, but then you're not seeing server2->server1 fails
MattJIn this case, let's assume you have bidi. Joining the MUC will work!
jonas’pep., the sender of stanzas from server2 sees it though
MattJand 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"
MattJMy 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.
MattJInstead of pretending it's not broken
ZashMattJ, you know what gets you that? Dialback.
MattJI 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"
MattJBut that one is so simple
MattJYou can send messages out? Ok, outgoing connections work
MattJYou can't receive messages in? Ok, your firewall or DNS or cert is messed up
MattJWith bidi, how do you even debug that?
MattJWithout a hack to disable bidi on the server for testing
ZashBy looking at your server logs?
MattJYeah, that's not the world I want to live in (telling people to look at server logs)
MattJBut I think you miss my point
MattJIf bidi is enabled, I test outgoing, and there is no way to test incoming without force-closing the outgoing connection
MattJIt will just appear like it works anyway
MattJUntil 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
ZashWell. Trade-offs be that.
emushas left
Edlisonhas joined
Edlisonhas left
remkohas left
remkohas joined
werdanhas joined
Dvdhas joined
ZashThing that could be done.. relax the requirement for error replies to be sent on a stream in the proper direction.
ZashHm, but that doesn't fix MUC
ZashTool 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
ZashSo useful I almost made this already :)
jonas’what if I told you all I need to do is open a port in my firewall?
ZashHm, I did have a thing like this but it was hooked up to a DANE-only server for testing your DANE validation stuff.
Zash> Secure s2sin_unauthed connection from blackbox@zash.se to zash.se failed.
jonas’that sounds wrong
jonas’but my prober agrees
ZashVerily
ZashI'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_Martinjonas’: 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_MartinHmm, 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_MartinYeah, but would prosodyctl know if you have SRV records for you MUC component?
jonas’yes, it already checks that
jonas’(IIRC)
!XSF_MartinOk
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
Zashprobe.jabber.network? poke.?
!XSF_MartinHmm, 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_Martinmartin@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
Zashjonas’, how far does it go with the s2s?
!XSF_MartinUgh, 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
Zashjonas’: 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
ZashAnd 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?
Zashjonas’, blackbox@ name of thing you probe
Zashjonas’: 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_MartinZash: jonas’: This? ^
ZashThat
testhas left
Zashjonas’, do you see stream errors? Prosody trunk should be sending nicer descriptions there :)
jonas’hm, so this is going to break now that dialback is going to be phased out?
ZashThat 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
ZashBecause it gets past the TLS and then you simply don't authenticate?
ZashWhereas 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_MartinWe didn't target at scaring you away.
!XSF_MartinBut 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
ZashOn a tangental topic, I set up something like badssl.com for xmpp: https://badxmpp.eu/
Jeybehas joined
pep.fancy
Jeybehas left
Jeybehas joined
!XSF_MartinThe 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
ZashSent a longer announcement to jdev@
!XSF_Martinhas joined
mukt2has left
Jeybehas left
moparisthebestZash: oooh been wanting to set up something like that for awhile, specifically to test various srv fallback behavior in both c2s and s2s
moparisthebestNot the same but related I guess
Jeybehas joined
Yagizahas left
calvinhas joined
!XSF_Martinhas left
!XSF_Martinhas joined
!XSF_Martinhas left
!XSF_Martinhas joined
Zashmoparisthebest: 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
moparisthebestZash: 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
ZashYeah. 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
moparisthebestyep, 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
moparisthebestI still have deep on my list to write a, maybe informational, xep with guidelines about when to continue SRV fallback and when to abort