Sam WhitedWas anyone here around during the JSF days? I'm trying to get a sense of how its mission was different from the XSFs since my understanding is that it was more software focused
KevSam Whited: Very few people who're still active. Alex, Edwin, Ralph. Me just about. Not sure about Dave, but I suspect not.
KevI've probably forgotten someone, but it's that sort of number of people, I think.
Sam WhitedKev: thanks, I'll reach out to them directly
Ge0rGSam Whited: are you going to make a history write-up? That'd be very interesting
Sam WhitedGe0rG: I wasn't planning on it, but that would be fun if I learn anything interesting
Ge0rGAs somebody who is very interested in having a JSF 2.0 of sorts today, I'm probably too biased to do such a thing.
Sam WhitedGe0rG: I've been vaguely thinking about that which is why I asked. I'd like to have something like Apache but for XMPP projects. Something that can act as a fiscal sponsor to help projects raise money, provide a common set of guidelines and dev practices and infrastructure for stuff under its umbrella, etc. but before I ask people what they'd want out of it I figured I'd see what existed before. I'm also not convinced that there is enough interest in XMPP in general to even make it possible, but you never know. Anyways, just doing very preliminary research.
jonas’Sam Whited, you should attend board meetings more often
jonas’also maybe become a member again so that you see what’s going on on members@
Sam Whitedjonas’: I still don't see the point of being a member of the XSF.
jonas’so that you get a say on that matter
Ge0rGSam Whited: nobody is _against_ creating such an organization, but the XSF isn't it, and looks like so far nobody had the resources to actually start it.
Sam WhitedGe0rG: right, that's why I was thinking about doing it separate from the XSF.
jonas’you’re most definitely not the first one with that thought
Ge0rGI think that the XSF (and XMPP overall) would vastly benefit from having it, though.
Sam Whitedyah, probably not
Sam Whitedjonas’: a say in what matter?
jonas’Sam Whited, the direction of the XSF and how funds are used.
Sam Whitedjonas’: I don't think this should be the XSF, they should be two separate organizations.
jonas’MattJ, cc @ you, I think you brought something like that up in one of the more recent board meetings, too ^
jonas’Sam Whited, yes, and I think such an organisation should have its roots in the XMPP and XSF communities
Sam Whitedjonas’: I agree, but like I said, this is just me doing some preliminary research.
jonas’I’m saying there’s already efforts in that direction and I suggest you join them. the more the better.
MattJI bring it up all the time
pep.I'm also interested fwiw
MattJto anyone who will listen, or who thinks the XSF is capable of doing all the things people want it to do :)
pep."jonas’> Sam Whited, yes, and I think such an organisation should have its roots in the XMPP and XSF communities", I agree
MattJWell it's unlikely to have its roots in the Matrix community, I agree :)
pep.No but it could be perceived as a "FU the XSF, it doesn't work, we're doing our own thing"
MattJI almost thing, so what if it is? (which is unlikely if you're up-front about the goals)✎
MattJI almost think, so what if it is? (which is unlikely if you're up-front about the goals) ✏
MattJModern XMPP also has/had that risk
MattJEven the name and domain :)
Ge0rGI'm pretty sure it won't, because the XSF is very clear about its razor-sharp focus on Protocol.
MattJ(XSF should register legacyxmpp.org on 1st April)
Ge0rGMattJ: you could do it right now.
MattJOh look, that's tomorrow
MattJMust finish my MAM update in time
Sam WhitedI kind of forgot about modern XMPP, I'm glad to see this exists. I like the goal of providing docs and UI/UX guidelines and what not.
Ge0rGMattJ: because you want it to appear on the Humorous track?
MattJWith DNS-over-XMPP on the Standards Track and MAM on the Humorous track we'll be good
MattJHmm, I wonder how many libraries/clients would get tripped up by an iq type='get' in one namespace, and the result having a payload with a different namespace
Sam Whitedseems like the easiest thing to do would be to match based on ID then just decode whatever is in the result, and I would assume most people would do the easiest thing and it wouldn't cause problems
Ge0rGMattJ: you'd be surprised how many implementations ignore the xmlns altogether
flowwell it does
flowif you only match on the id, then you are potentially open to spoofed replies
MattJYou match on (jid, id) though
Zash(jid, id, type=(result|error))
Ge0rGMonal won't work on my account because I have a Cisco user on my roster who has a Cisco-namespaced <presence> element inside the jabber:client <presence> element
jonas’or have a sufficiently unpredictable ID :)
pep.I'm just patching our minidom implementation in Rust to force namespaces everywhere. It's just not possible to retrieve an element without specifying a namespace, unless you loop over everything all the time
flowand even (jid, id) is not that trivial as it seems, since there could be multiple values for jid
flowincluding, in some cases, nil
jonas’don’t get me started on the ambiguity of an absent @to/@from on stanzas
flowso you may simply want to generate "good" IDs and be done…
Sam WhitedWhy would there be multiple values for JID? Do you just mean the server being the domain or the empty attribute?
jonas’Sam Whited, that’s not what empty attribute means
Zashjonas’, when is it ambigous?
jonas’absent attribute refers to your *account*, not to the server domain.
Sam Whitedoh right, that one. Is that what you menat?
jonas’Zash, you can’t simply match on the verbatim string, you have to take into account your currently bound-to JID after resource binding, since some servers will always do one thing (present or absent attribute) even if you always send present/absent
Sam Whitedyah, that's irritating. I just have my library normalize that on all incoming stanzas
jonas’so you have to, in your processing loop, alias empty jid to locally bound bare JID, which is annoying to do
jonas’I recall having issues with normalising that actually
Ge0rGjonas’: nothing wrong with empty @from/@to... Until you send a message to yourself and the Carbon copy you receive doesn't have one of those set, but it means a different thing ;)
ZashJust don't find the text that suggests that empty to/from is different from the bare account jid.
flowjonas’, do you remember which issues you had exactly?
jonas’(also, of course it requires the stanza broker to know your local JID, because we all hate self-contained things)
jonas’I’ll have to check the git log
Sam WhitedWhat is a "stanza broker"?
jonas’Sam Whited, the thing which takes the stanzas from the XML stream and hands it to handlers
jonas’I think it’s called mux in mellium
Sam WhitedOh, that's not what does the noramlization in my case (I don't think, if it does it shouldn't be, I can't remember)
Sam WhitedThe session (or connection) knows your JID, and whenever any tokens are read from it it can normalize them
jonas’my point is that there’s *no* layer which should need to know about your locally bound JID in the stanza processing pipeline
Ge0rGSam Whited: are you also normalizing <forwarded> stanzas? :D
Sam WhitedGe0rG: I don't remember how that works, but those are wrapped in an actual stanza, no? I should probably look, if not I'm probably breaking something there
jonas’flow, possibly the normalisation issues were purely in aioxmpp
Ge0rGSam Whited: yes they are, but they are also <message/> stanzas and there are no guarantees whatsoever on them having @from/@to set correctly
Sam WhitedGe0rG: I don't do any automatic handling at all of those right now, my library is a bit low-level for that. If a package was ever written to handle them, it would have to do its own normalization to remain self contained.
ZashI like to think of it as stanzas inheriting the logical to/from of the parent stream.
ZashAfter resource binding one could think of those as from=full jid to=bare jid
Ge0rGZash: that's the logical thing indeed, except that for some people it's not obvious that you have a stream to your account.
jonas’Zash, however, as a client, you set @to to the domain, not to the bare account JID✎
jonas’Zash, however, as a client, you set stream:stream/@to to the domain, not to the bare account JID ✏
Zashjonas’: Imagine that it changes during resource binding
jonas’that does make no sense to me
ZashI kinda wish resource binding was a stream restart thing
jonas’changing on SASL, that’d make sense, because that actually binds you to a JID✎
jonas’changing on SASL, that’d make sense, because that actually binds you to a bare JID of some kind ✏
ZashDrop the resource binding iq hack, server tells you to/from in the post-sasl restart
jonas’that’d be kind of sexy, except that the client speaks first on stream resets
Zash+ SASL2 gets rid of the stream restart
ZashTho you could just drop the to/from that the client sends. The server knows who you are after auth and it knows who you authed to.
ZashAnd by drop I mean the server ignores it.
Sam WhitedI'm always torn about the restarts. On the one hand, they're logical and they're probably good from a security perspective. On the other hand, the entire connection process takes forever on a crappy network and anything we can do to speed that up makes me happy.
ZashI did something like that in an experimental CBOR protocol once. No stream restarts, just a message that updates top-level properties like to/from
jonas’I don’t even know what stream restarts are supposed to do. the @to is only interesting for client->server really pre-STARTTLS as an SNI-surrogate
flowjonas’, rumar is that they are supposed to reset the xml parser state✎
flowjonas’, rumor is that they are supposed to reset the xml parser state ✏
Zashand thus throw away auth related state that might linger
Zashwhich is why it's weird to me that SASL2 drops the restart
jonas’flow, ah, that makes sense
jonas’I’ll probably forget that again, but it *does* make sense
MattJPretty sure there have been protocol security problems in the past that didn't apply to XMPP because we do restarts
ZashAlso older SASL mechanisms can negotiate encryption and stuff, which requires a clear point where it's activated.
flowI think it's not that bad to have them
flownot sure about the motivation to drop them in sasl2 though
KevYou need a stream restart after integrity is negotiated.
KevBoth starttls and SASL can negotiate integrity, I think.
jonas’Kev, see, that argument I don’t get
ZashNever seen it used in SASL tho, only seen the traces of it in DIGEST-MD5
jonas’I can see the argument that you want to throw away an XMPP parser/serialiser after having done auth with it, or that you don’t want to keep an XML pipeline hooked up to a stream potentially in the middle of a TLS handshake. But I don’t get that integrity argument
Sam Whitedrealizes that as we speak I am extremely far behind on my phone because the connection got dropped and on this crappy mobile network it takes ages to be re-established.
Sam WhitedI'm always confused when I walk up to my laptop and there's a ton of new messages I hadn't seen.
Kevjonas’: Because if you assume pre-integrity that things might have been injected into the stream, people could have mangled your to/from and stream id, as well as injecting things into your XML parser.
jonas’right, so to/from/stream id are 100% irrelevant, aren’t they?
KevSo you're potentially doing authorisation based on injected data.
KevI don't believe they are, no.
jonas’you authenticate the server with TLS/SASL, likewise for the client.
jonas’I never saw the stream ID used for anything
ZashIt's used in dialback
jonas’that’s more interesting
jonas’(maybe my view is too client-centric?)
KevI think it might be :)
jonas’but clients are most hurt by stream restarts either way
ZashDidn't the non-SASL auth also use the stream id?
Zash> SHA1(concat(sid, password))
ZashObsoleted nearly 12 years ago? Why do we still ship code for this?
ZashAltho I fondly remember typing https://xmpp.org/extensions/xep-0078.html#example-3 into a telnet console once upon a time
moparisthebestI think it should be brought back, just the PLAIN though, and only over TLS of course
moparisthebestif it's good enough for HTTP why not XMPP
moparisthebestSASL made sense before TLS was mandatory, I don't really think it brings any advantages nowadays though
ZashThis notion makes me sad
moparisthebestunless you see "complexity" or "not being able to upgrade ever" as an advantage
moparisthebestare there actual advantages to SASL ?
lovetoxyou mean SASL SCRAM?
KevThere's an advantage to having a choice of mechanisms, if that's the question. And once you've got a choice of mechanisms, why not use SASL.
lovetoxyeah there is more than sasl scram
lovetoxyou need a protocol to tell the server how you are going to auth
lovetoxmay it be via 2FA or external via client cert or even PLAIN
Zash"good enough for http", but the web uses a lot of OAuth and stuff that only works if you're a browser
moparisthebestclient cert can be handled at the TLS layer, 2FA can just be a token appended to your password which makes it the same as PLAIN
moparisthebestfair re: oauth ugh
ZashAlso, I sure hope you're not making the argument that popular == good
moparisthebestno, I'm arguing that PLAIN user+pass is "good enough" and KISS and sasl-scram and friends is needless complexity for no gain
lovetoxi agree about sasl scram over tls is probably not very useful
lovetoxbut not about getting rid of extendable protocol that can define any kind of auth mechanism
Ge0rGit's useful because you don't need to store the password on the client
Zashor on the server
Zashor send it over the wire
Zasheven if TLS helps there
Sam WhitedMore useful than not having an upgrade path if SHA-1 gets broken?
Zashand it's cheap to verify for the server, even if you did a billion rounds of PBKDF2
ZashDoes this exact discussion with these exact words get repeated every couple of months?
Sam WhitedUnrelated: but is Apache Vysper still being developed? Randomly wound up on its Git page and there are a bunch of recent commits by names I don't recognize. That is suprising