Modern XMPP project discussion - 2021-08-23

😚

o/

Hey!

Hey, welcome 🙂

Seems like someone posted the project to HN

Yep Matt

yeah that's where I wandered in from 🙂

Hello

well-timed for me; I set up a Prosody server a couple weeks ago just to mess around

Great project!

Thanks!

giggles, great to hear that - I'm one of the Prosody team as well 🙂

oh cool! I'm a fan, wasn't hard to set up at all

it's nice to meet you 🙂

oh hi giggles, welcome!

👋️

👋

Lovely to see more activity around xmpp, last time I used it a web client like the one on https://chat.modernxmpp.org/ was pretty hard to conceive of. Good job and keep it up 🙂

Dino is nice on the Linux desktop, too

From what I can see there seems to be some renewed interest in XMPP these days

😬

🇦🇮

jhackett, sounds like that was extremely long ago then, back when I started using XMPP around 2005 there were already web clients such as MUCkl (discontinued since).

I wandered in from a post on fedi

Fedi likes XMPP in my experience

Ah yes, it was randomly posted there a couple of times today as well. Not sure why all the sudden interest, but it's good :)

Probably someone new came in board and wants to share

First I'd heard of this MUC though

Hey all, I just started writing a XMPP server for fun and educational purposes and a friend pointed me at docs.modernxmpp.org . I'm about 2 weeks into understanding XMPP and am happy to provide any feedback or contributions from someone with that perspective. Lemme know if I can help!

greg, I was you in 2008, so yeah... feedback and contributions definitely welcome :)

It's always good to have fresh eyes on stuff

Anywhere in particular to start? Or read around the site and open PRs/issues for things that might use a little clarification or further explanation?

Most of the docs here are focused on clients at the moment, but are probably a good overview for server devs too for what features to prioritize

But yeah... feel free to ask questions or suggest stuff you feel is missing

I'm curious about your opinion on this XEP https://xmpp.org/extensions/xep-0201.html

Hello folks.

I only wanted to brag a bit, that I'm developing a commercial app using XMPP as backend, instead of usual REST API.

Hi haael, welcome! Sounds interesting 🙂

giggles: I think the XEP is fine, but threading UIs are very hard to get right. Some people love Slack's threads, but many people hate them. Same applies to other apps that implement message threads. Extend that to a whole ecosystem of software and... you'd better get it right 🙂

Are there any servers/clients that actually support the XEP that you know of? Seems more straightforward to support on the server side (because you are so, so very right, about the UI) but I'm curious what support is out there and I haven't yet been able to figure out if the XEP is actually supported by anyone or if it's still basically just a proposal

In short I think threading protocols are easy, threading UIs are hard. I think someone would need to make a candidate implementation. There are some XMPP clients that do threads in one way or another, but none wildly successful that I've seen.

Server support isn't really needed. I know one or two implementations were based on Converse.js, not sure if they were open-source though

Oh really, server support isn't needed? So one could theoretically e.g. just use Prosody and focus on writing a custom client?

Yep

that's really interesting

Many XEPs just route stuff through the server, and the server doesn't need to understand it

that makes a lot of sense actually

are there any modern xmpp chat clients that can auth with SCRAM-SHA-256? I'm attempting to test my implementation and it seems libpurple doesn't support it. ✏

in general I don't know what the landscape looks like in terms of auth mechanism support

greg, libpurple is pretty obsolete in its XMPP implementation, pretty much anything would be better for testing stuff.

I personally use Gajim as a well-updated generic client for my testing.

gotcha thanks!

greg: there will be wider support for SCRAM-SHA-1, since it's older and was mandatory to implement for a long time, plus it's complicated to upgrade the hashes

I think Gajim does support SCRAM-SHA-256 indeed. And so does Conversations (Android), for example.

Easier for clients tho

Yes.

is there a mechanism support recommendation or best practice? I think I'm gathering DIGEST-MD5 and SCRAM-SHA-1. md5 being considered obsolete but necessary for many clients, sha-1 being considered required? ✏

DIGEST-MD5 is dead and buried

Don't even think about it!

word, appreciate that!

SCRAM-SHA-1 is fine, attacks on SHA-1 aren't relevant to it AFAIK

Yeah, DIGEST-MD5 is a no-go. SCRAM-SHA-1 is designed differently (the designers having learnt lessons from DIGEST-MD5). A new server should support SCRAM with SHA-1 and SHA-256. Migration between the two is impossible because you need access to the plaintext password.

At some point we need to figure out how to make that easy (e.g. by forcing users to reset their password when an admin wants to upgrade)

And once they're done, repeat for SHA-512!

I'm just waiting for someone to say that SCRAM is broken and to just use PLAIN

moparisthebest was arguing for that the other day. :|

Definitely has advantages.

All depends on your trade-offs.

i wish i could use something not PLAIN with LDAP :/

Works for HTTP :)

*Works for HTTPS :)

(in ejabberd)

Theoretically it should be possible to tunnel SASL to LDAP. There's an authentication backend that does that with Dovecot, it's pretty nice.

all great insight much appreciated!

Zash: ooh, interesting

LDAP libraries that allow that may be harder to come by tho

And there may be impedance mismatches, like it is with email, where usernames (in the SASL sense) is often the entire address, while in XMPP it's just the localpart, so it ends up not working in practice without hacks.

Who let the dogs out?

go test ./...

...... wrong box. Sorry everyone.