I thought I’d start a conversation instead of asking for help right away.I’m always interested in hearing what other people are building, whether it’s a personal experiment, an open-source contribution, or something you’re using at work.
What are you currently working on with the Ignite Realtime projects? Have you run into any interesting challenges, or discovered something that made development easier than you expected?
I enjoy seeing how different people approach similar problems, and these kinds of discussions always give me new ideas to explore. Looking forward to hearing about everyone’s projects and getting to know the community!
I’ll be honest with you: an introductory post like this, from a day-old account that’s liked a few posts and browsed a bit, tends to pattern-match to the kind of reputation-building we sometimes see as a prelude to spam. So I’ve capped the account’s trust level for now. That’s easily undone if it proved to be unneeded
That said, it’s a good question! I’d rather answer it in good faith than let a decent prompt go to waste. So here’s what I’m actually working on.
We’re about halfway through an NLnet-funded effort to modernise Openfire’s authentication stack. XMPP has standardised a lot over the last two decades, and Openfire has fallen behind a bit on the connection-establishment side, so we’re bringing it up to date with the current SASL authentication-related specs. Concretely:
Channel binding (SCRAM-SHA-1-PLUS to start), to help detect certain man-in-the-middle attacks that there’s evidence are being used in the wild
SCRAM-SHA-256(-PLUS), for stronger and longer-lived SCRAM mechanisms
XEP-0388 (SASL2), the next-generation SASL framework: fewer round-trips, more extensible, and room for things like second-factor auth and mandatory password changes
XEP-0386 (Bind 2), to cut down the login race conditions that tie together resource binding, carbons, MAM, and stream management
XEP-0484 (FAST), token-based authentication that reduces round-trips and leans less on passwords
Plus the negotiation and safety pieces: XEP-0440 (channel-binding type capability) and XEP-0474 (SCRAM downgrade protection)
A couple of the more interesting challenges that have come up along the way: Openfire’s plugin and API architecture means it’s not enough to implement these features; they have to be extensible, so third parties can inject their own SASL2 tasks (new 2FA mechanisms, say) at the right points. And channel binding depends on TLS APIs that aren’t always exposed by the third-party TLS libraries Openfire relies on, so some binding types simply aren’t reachable, which is part of why XEP-0440 matters for negotiating gracefully around mismatches. There’s also been a nice knock-on benefit: Smack and the XMPP Interop Testing project didn’t support SASL2/BIND2/FAST, so the work we’re doing there helps unrelated projects too.
So, over to you: what are you building on top of the Ignite Realtime projects, and what brought you here? Specifics welcome, the more concrete the better.
Thanks for the welcome, and I appreciate the honest explanation.Your project sounds really interesting, even though a lot of those standards are still new to me. It’s nice to get some insight into the kind of work that’s happening behind the scenes and the challenges involved in keeping everything both modern and extensible. I didn’t realize how much coordination was needed across Openfire, Smack, and the related projects.
As for me, I’m still in the learning phase. I don’t have a specific project yet—I joined because I wanted to learn more about the Ignite Realtime ecosystem, see what people are building, and better understand how everything fits together. Reading replies like yours definitely gives me a clearer picture, so thanks for taking the time to share all the details!