jdev - 2025-05-13

Someone brought up the idea earlier that if you want to write a client, You shouldn't write your own library but rather reuse an existing one. I was wondering if there are any existing ones that would actually have good documentation, ideally with examples available and would support modern things like omemo, calls? For example, for java I found jaxmpp, but documentation is non existent.

In what language?

Java, for example. Or C. I'd like to hear about any language for which a documented library exists

There is a site on xmpp.org that list libraries

Gloox for c++ has reasonable documentation. It only implements the basic things (so no omemo and calls out of the box) but it is extensible to support more things. A well designed xmpp library doesn't need to implement everything, but at leastyou won't need to implement streamed xml parsing and all the boring low-level parts, you can move straight into more interesting things

I'd say XML streaming isn't the hard part. Annoying and stupid yes, but not too heard to implement yourself. Or at least easier than dealing with somebody else's code.

Err, I wouldn’t be so sure, in xmpp.rs it took us quite a long time to get something working correctly and in a performant way, and there are still things to improve here.

Generally in client software I don't think you'd care how performant the xml parsing is. You receive human readable text messages in it, not streamed video frames

Not typically, anyway; theoretically you could use raw XMPP for any application regardless of how much sense it makes

Given the absurdities XML people come up with, yes it's almost surprising nobody has come up with that yet.

Well we use it as last fallback for file sharing, base64 encoded... 😀. But likely server throttling might apply there, more relevant then the client? ✏

I've never read about xml people 🙂. Doubt they exist.

doge, tell that to my client which takes well over five minutes to receive and parse and act on all the things happening on launch, before it is fully usable!

Did you benchmark it, are you sure the XML parsing is the bottleneck?...

(That’s on a fourteen years old ARM CPU, using Python for most of it, but still!)

The slixmpp conversion from expat to a more Python-friendly format is, yes.

Before that it was JID parsing, but we’re now doing it in Rust so it’s an order of magnitude faster.

Is slixmpp's format more elaborate than gajim's?

Reusing xmpp.rs’s jid crate.

doge, I don’t know, I’ve never profiled Gajim on my main account.

I just cannot imagine a processor so slow nowadays where jid parsing would be a significant issue....

And certainly not on that ARM board.

And by nowadays I mean like the last 20 years probably....

doge, try https://en.wikipedia.org/wiki/ARM_Cortex-A7

So where do you even use that...

I’m talking to you from it. ^^

So where do you even use that

What do you mean?

Like is it the phone or what is it? how did you even end up with this

Ah no it’s that board: https://www.olimex.com/Products/OLinuXino/A20/A20-OLinuXino-LIME2/open-source-hardware

I’ve been using it as a server for eleven years now, it runs my XMPP client (poezio) but also server (Prosody), a web server (nginx), Mercurial server (hgweb), email server (OpenSMTPd) and DNS server (bind9).

… but now I realize we’re in jdev@ and not somewhere more off-topic, sorry everyone about that.

How dare you talk about your XMPP setup in the XMPP development channlel <mood xmlns="http://jabber.org/protocol/mood"><sarcastic/></mood>

Goot the ticklegoblin!, well, this is explicitly about development, not about operation.

Not too far off but fair

> I’ve been using it as a server for eleven years now, it runs my XMPP client (poezio) but also server (Prosody), a web server (nginx), Mercurial server (hgweb), email server (OpenSMTPd) and DNS server (bind9). Oh so you're just masochist I get it ↺

Not something a normal user will ever encounter ever

Abnormal users have rights too

I have several "normal" users who can't afford a computer built in the last 20 years or don't want to use one. Client performance is important to them. Maybe your defiaition of "normal user" is too narrow

> Java, for example. Or C. I'd like to hear about any language for which a documented library exists For a low level library in C, libstrophe is quite good and I have found the docs acceptable for doing my work with it. ↺

doge: for java, have you considered Smack?

Should do omemo, unsure about calls

getting libstrophe and/or xmpp.rs FFI bindings for other languages would go a long way, I imagine. An anecdote: My WIP client Spades is written in Dart (Flutter) and the best I could find when I started was moxxmpp. Now it's that and Whixp and they're both pretty iffy, moxxmpp is very closely tied to Moxxy and Whixp has things in it that it shouldn't have. I had to pick a pure Dart implementation because anything else would be iOS and Android only, and I specifically wanted it to run everywhere Flutter does. If I could have used a Rust-based library I wouldn't have to compromise on platforms or SDK quality, since Rust runs in the places Flutter does and then some! that being said, how hard would it be for me to generate* some Dart bindings for xmpp.rs? (yes I'm partial towards rust over C for familiarity and other reasons)

can you do dart bindings for C?

as in to call C from Dart? I think so: https://dart.dev/interop/c-interop I think it's also possible to do it the other way around too but it's not as well supported, I think the Flutter engine itself does this on Linux

if you can call C then yeah using libstrophe or something higher level like my SDK should be options. I should look into autogenerating dart bindings maybe

there is this - https://pub.dev/packages/ffigen and I think there are tutorials across the web for that kind of operation. It can get pretty complex though with more and more things brought in.

I suspect just making your own library can end up easier than writing bindings for somebody else's library, studying that library, probably eventually digging deep into it, modifying it etc.

I disagree. I've been saved days of work by using xmpp.js and libstrophe instead of starting from scratch

days? probably months, you can spend days just writing a validation method for JIDs

yeah I was about to say, if I had to try to get SASL to work all by myself I'd have stuck with Matrix

not to mention focusing SDK work onto a smaller set of SDKs is better, less people doing the same things over and over again, and more consistent behavior across clients. Keeping them open source and freely licensed also helps with disagreements, so maybe you end up with several SDK forks instead of several distinct SDKs. So things get done faster etc etc

> days? probably months, you can spend days just writing a validation method for JIDs huh? Clients don't validate JIDs, your server does ↺

> I suspect just making your own library can end up easier than writing bindings for somebody else's library, studying that library, probably eventually digging deep into it, modifying it etc. Judging by looking around you are correct lol, time to dust off ye olde meme https://www.moparisthebest.com/images/xmpp-client-devs.jpg ↺

> huh? Clients don't validate JIDs, your server does Server devs: wait, I though it was client role to validate those stuff ?! ↺

it's both, at different times

https://upload.movim.eu/files/9d94237298995552fa13436420195fbca436dce7/SjOygnG1a5yy/chat_image.png

> yeah I was about to say, if I had to try to get SASL to work all by myself I'd have stuck with Matrix now doge, you might have been right way back when there was no TLS or SASL and you sent your JID and password to the server in plaintext, but we don't live in that world anymore ↺

or when there weren't 5 different ways to represent profile pictures and 4 different ways to represent display names, stuff like that

oh or when open source devs were paid for their work-- oh nevermind that was never

i dont think those are the hard parts. There are sasl libraries that just provide sasl for you. tls is one line in any high level language. Now profile pictures are tricikerz then there are mucs, encryption etc. for these yes a library would help

halscode, shouldn’t Matrix use something similar to SASL for login? Or does it send plain text password over TLS with no additional security?

doge, why use a SASL library and write your own low-level XMPP library, when you can use an existing XMPP library which integrates both?

halscode, if you want to write bindings for tokio-xmpp, jid, or xmpp-parsers, feel free to get in touch with us at xmpp:chat@xmpp.rs?join

> i dont think those are the hard parts. There are sasl libraries that just provide sasl for you. tls is one line in any high level language. > Now profile pictures are tricikerz then there are mucs, encryption etc. for these yes a library would help you've got to be in one of the really big languages, or something along the lines of go/rust that has nearly-native C interop, for that to be true ↺

negotiation is also really weird, you advertise the wrong thing and oops, you can't connect

not really sure why that happens. being able to use a library that already has this figured out is awesome!! and then you can get to the good parts sooner

> halscode, shouldn’t Matrix use something similar to SASL for login? Or does it send plain text password over TLS with no additional security? you just send a json blob with your username and password lol, then get a token for that device https://github.com/jjj333-p/dendrite-admin-interface/blob/11385cc09aaa0617dfec91d2d2c29a33959a6e0f/index.js#L564 ↺

jjj333_p (any pronouns), :|

> halscode, shouldn’t Matrix use something similar to SASL for login? Or does it send plain text password over TLS with no additional security? I think it uses OAuth now but it might still support plain text passwords over HTTPS ↺

auth is hard. it's why you need a library for it lmao

> I think it uses OAuth now but it might still support plain text passwords over HTTPS oauth is still in beta, some clients support only oauth some clients dont support oauth ↺

Well, SASL also does support PLAIN, but it’s one of many options and hopefully no modern client uses that.

also they like rolled their own oauth

halscode, if you want to write Dart bindings for the sasl Rust crate, it’s also part of the xmpp.rs ecosystem.

> also they like rolled their own oauth bluesky and mastodon had to do it too because there is apparently no decentralized oauth ↺

OpenID is something quite different

I want to give a try at implementing XEP-0493 at some point.

> bluesky and mastodon had to do it too because there is apparently no decentralized oauth hm maybe. i dont trust matrix to have done it well though ↺

im wary

that is fair

they also are trying to push using matrix oauth as an identity login for other services

just ew

> I want to give a try at implementing XEP-0493 at some point. I'd love to have at least a token mechanism so I don't have to store passwords. ↺

> they also are trying to push using matrix oauth as an identity login for other services it is nice to have that option, tbh. see: "sign in with discord" ↺

> I'd love to have at least a token mechanism so I don't have to store passwords. one thing matrix did get right was being able to just "log out device" ↺

Yes now that we have fast I don't even have a way to store passwords in my SDK anymore

halscode, there is XEP-0484 for the token thingy.

i also would love to see qr logins actually become a thing

> Yes now that we have fast I don't even have a way to store passwords in my SDK anymore gajim still randomly asks me for my password every so often, and then i just cancel and set my status to online and it connects. ↺

> halscode, there is XEP-0484 for the token thingy. Oh so that's what that is. Apparently moxxmpp implements FAST but doesn't give me the token so I can't store it ↺

or give me a way to give it back to log in

halscode, in xmpp-parsers we implement it, but I haven’t written the integration in tokio-xmpp yet.

SASL is from a different time when TLS was barely used, no one would design XMPP with it in 2025

But it's not that bad

SASL is super important not sure what you're talking about

Which mechanism you choose may be determined by what else you have going on. But sasl is the right choice for every protocol, not just xmpp

> halscode, in xmpp-parsers we implement it, but I haven’t written the integration in tokio-xmpp yet. I have a vague architecture in mind, if I decided to make an xmpp-rs based SDK for Dart. I think I'd want to have the data-model stuff, dealing with the XML and all that, on the Dart side, and things like login/connection, encryption, stream management, and more "background" stuff done in Rust. It would be a tall task to switch SDKs in my client, though it might be worth it if it's more stable and hopefully means I have to deal with less of the weird hard stuff... it's all in parts, I think I'd mainly use tokio-xmpp and pipe the string XML stanzas to Dart to parse it there so I can use package:xml with it. It would have wrapper types there to get/set the data using the XML as source-of-truth so no extension gets lost. ↺

If you do that make sure any namespaces from the stream etc survive the process

If the to string in rust side is normalized it should be fine

I had tried to build from scratch but I couldn't figure out where to start with SASL or how to get TLS to work right in Dart because it's weird and restrictive there (less important for XMPP, actually it's more weird for implementing something like Gemini because you can't set custom certificates in Dart's TLS). I think the SASL package was way out of date and used JSON or something? I can't remember

halscode, so you’re likely to want to bind at the tokio-xmpp level, it’s the part which handles everything needed for the connection, and gives you a stream of stanzas.

halscode, we did a lot of work to get xmpp-parsers working and it’s going to get much more efficient soon, once we drop the DOM-like part in the middle, going straight from XML bytes over the wire to SAX-like events to XMPP-specific structs.

> Which mechanism you choose may be determined by what else you have going on. But sasl is the right choice for every protocol, not just xmpp singpolyma: it's literally not as evidenced by every protocol invented since TLS became required not using it ↺

Binding that to another language might be a lot though.

The entire world runs on "plaintext" user+pass over TLS being exchanged for a time limited token

Name a single standard protocol not using sasl for auth?

https

If you want plaintext that's fine sasl has that

> The entire world runs on "plaintext" user+pass over TLS being exchanged for a time limited token an implementation with any real security concerns would go the one step further of encrypting the password ↺

http auth predates sasl and TLS both, but there is sasl-over-http

Nah, any attempt to protect the password implies it might be ok to reuse that password elsewhere, and it's not

We're heading for a world where the server won't ever even know the password

good

This is already implemented for web and xmpp is mostly waiting on the standards process to finish to bother

Note your XMPP server gets your password in plaintext too so it's literally security theater

> Note your XMPP server gets your password in plaintext too so it's literally security theater Soon this won't be true ↺

> Nah, any attempt to protect the password implies it might be ok to reuse that password elsewhere, and it's not but people do it anyway ↺

> http auth predates sasl and TLS both, but there is sasl-over-http does anything use SASL over https ? ↺

>> Nah, any attempt to protect the password implies it might be ok to reuse that password elsewhere, and it's not > but people do it anyway Let them learn the hard lesson then ↺

↑ worst take on that topic.

SASL over http is about as rare as all http auth methods. Most web stuff does custom proprietary protocols with JavaScript instead 🤷‍♂️

web (again 99.9% of what people use the computer for) uses only plaintext user+pass auth, exchanging it for a short-lived token (cookie)

A lot of web stuff doesn't do plaintext. But even when it uses plaintext it uses a custom protocol nothing http related

some are moving to passkeys which only work on proprietary OS's which is obviously worse

most web stuff authenticate via Facebook or Google or whatever else that has all user's data already across the entire intetnet all for sale to the highest bidder

🤷♂️

passkeys? hahaha

I think moparisthebest is confusing sasl for scram?

But even so mitm stuff makes scram-plus valuable imo

i feel like passkeys are a step down in security

Passkeys as just client side TLS certs

Nothing new

biometrics are not considered private information

and PIN/pattern do not have as much entropy as passwords can have

Passkeys aren't biometric

singpolyma: yes i know

passkeys can be multiple types

It's just a local key, same as TLS client or ssh

How you protect the key is whatever

ah i thought it was something like *cough cough*

Microsoft Passkey

(and FIDO)

> Passkeys as just client side TLS certs You left out the critical part, services will only accept them from fully proprietary devices ↺

Yeah. I don't really know why we needed a new protocol (FIDO2) which is identical to one we already had deployed (TLS) but whatever it works out to the same thing

i don't like how biometric data is considered on-par with passwords

>> Passkeys as just client side TLS certs > You left out the critical part, services will only accept them from fully proprietary devices We run our own services we can do whatever we want ↺

Sure but I'm talking about normal websites normal people use

I thought we were talking about XMPP, my mistake

> some are moving to passkeys which only work on proprietary OS's which is obviously worse passkeys work just fine for me on linux so that's moot ↺

one has been legally defended multiple times in court, the other is legally considered to have "no cognitive exertion", therefore is unprotectable

That very much depends upon jurisdiction

sure

the point is, biometric data (as authentication) is more weakly-protected than passwords

and PINs have fixed number of digits... and i don't get why FIDO and stuff mention these as replacements for passwords

therefore.. i don't get the point of passkeys

State of the art is to set your password to 12345 but then forget you added the 5 so do email password reset every time

and emails are in plain text

😁