Modern XMPP project discussion - 2024-04-22

Is this an appropriate channel for asking of XMPP client dev questions, or is it intended more for Working Group style discussion for the modernxmpp.org website?

arcanicanis, hi! it depends; normally the place for XMPP development is xmpp:jdev@muc.xmpp.org?join, but if you're having questions specific to the topics addressed by modernxmpp.org, this here may also be a good place.

I guess one confusion I have is: I see use and mentions of `<session xmlns='urn:ietf:params:xml:ns:xmpp-session'/>` in the old XMPP RFC (RFC3921 from 2004), and zero mention in the latest XMPP Core and XMPP IM RFCs, is it something no longer required then?

arcanicanis, correct.

unless you happen to be talking to a _really_ ancient version of some server softwares

relevant: https://datatracker.ietf.org/doc/draft-cridland-xmpp-session/

I did encounter servers which actually required session in 2015. I suspect it's not the case anymore today.

We can certainly hope :)

So with latest server implementations, that if I've authenticated, reopened stream, performed resource binding, then I should be free to perform any standard messaging activity, or is there another step I'm missing? Or strongly recommended to enable Stream Management, or?

Question is if clients still send it, requiring that servers answer it (by doing nothing)

arcanicanis, enabling stream management is a good idea unless you are in an extremely well-controlled networking situation

but otherwise, yes.

Zash, aioxmpp will send it, unless it is explicitly marked as optional via that draft

For context: I'm writing a very minimalistic webclient from scratch, in plain JavaScript, no dependencies, using WebSockets for transport, to demo the concept of how simple an XMPP client can be, and possibly extend that further with building a WebRTC video/voice call, to also show that such a thing isn't profoundly novel, as an argument against people that think there's some special novelty to Discord, MS Teams, etc (which all are just lipstick ontop of a signalling layer and WebRTC)

So effectively I'm trying to take the shortest path possible, while still having something functional enough. I could even continue it further as another whole complete web-based client afterward

arcanicanis: are you using an existing library?

Noap, no library; within 2 days I'm already gotten through implementing SCRAM-SHA-256 from scratch, no external libraries, just the plain primitives provided in WebCrypto

and with resource binding, in ~250 lines of plain JavaScript

Now the rest is just adding a little bit of an interface, basic MUC support, etc

that sounds impressive.

my idol is diogenes ✏

"now the rest..." famous last words :) but keep going!

I think 250 lines for an XML stream implementation is pretty good

I can probably add host-meta resolution for WebSocket endpoint discovery, and then pop up what I have for progress, as right now I just have it hard-coded to my server's WebSocket endpoint

Obviously right now you can't use an interface to send message yet, it's just connection establishment, auth, binding, etc, as you watch in the developer console

But I'm sure in another ~100 lines of code and few things of HTML, it could

arcanicanis: was just thinking SASL2/Bind2 would probably make things a lot easier, that was the intent. But they are still relatively new so most servers don't have them yet.

> arcanicanis: was just thinking SASL2/Bind2 would probably make things a lot easier, that was the intent. But they are still relatively new so most servers don't have them yet. Yes, I was actually poking at that and bizarrely, I was getting an error of <encryption-required /> back from ejabberd 24.02 over a wss:// connection

```xml <failure xmlns='urn:xmpp:sasl:2'><encryption-required xmlns='urn:ietf:params:xml:ns:xmpp-sasl'/></failure> ``` ✏

for SCRAM-SHA-256 over a TLS-encrypted WebSocket connection

Is there some kind of reverse proxy involved, or does the connection go direct to ejabberd?

Straight to ejabberd, no nginx/Apache/etc in the middle. Straight to port 5443 where it's served on.

Then probably an ejabberd bug

Worth reporting

So here's my foundation of the client code hacked together from scratch, it's definitely not cosmetic code: https://arcanican.is/demo/xmpp-bare.htm

as proof that you can trivially start an XMPP client from scratch, no libraries, and just using the primitives the web browser already provides (WebCrypto even include PBKDF2 apparently)

(requires a server with a WebSocket endpoint, and with it discoverable from /.well-known/host-meta)

arcanicanis: nice!