XSF Discussion - 2023-01-11

There is no way to share some MUC rooms around, like on a PEP node

Would be interesting for discoverability

It's already the case with Pubsub nodes :)

Wasn't that one of the proposed ways to do spaces

Spaces :D

https://upload.movim.eu/files/9d94237298995552fa13436420195fbca436dce7/HRdzSXquNuPU/image.png

Interop question: Openfire hasn't always been the most conforming server, in a server-to-server context. I know of at least one other server implementation that introduced an 'openfire compatibility' flag in their configuration, to work around issues at the time. Do servers still have those, and if so, what do they do? (Can we test if they're still needed with modern versions of Openfire)?

Not aware of anything in Prosody, quick search turns up nothing.

https://modules.prosody.im/mod_s2s_auth_compat

But I don't think it's in widespread use, so assume that if it's working with a modern Prosody it's working

I did _not_ remember that one.

yet you appear to be the author :)

Author: You

:P

Guus This is the comment from the M-Link Source: ``` // Openfire sends the correct from on initial stream open, but fails to generate a correct one after // TLS has been negotiated, so skip from header addressing checks for anything but the first stream open // if Openfire compatibility is set on the peer control. ```

I don't remember if we put other compat options in for Openfire, but that's the only one that's explicitly marked as such that I can see.

> There is no way to share some MUC rooms around, like on a PEP node We already have MUC discovery standardized right?

Thanks Kev - that seems to address the same issue as the Prosody code did. That bug was long ago fixed in Openfire.

https://www.outreachy.org/communities/cfp/

Openfire will use Dialback authentication when the remote server presents a self-signed certificate (when that fails SASL EXTERNAL authentication), even if Dialback is disabled by configuration. As Dialback offers a weaker identity verification as compared to TLS-based SASL EXTERNAL, I wonder if that fallback is desirable, as I wonder if Openfire is making it impossible to fully disable a weaker verification mechanism that way. Thoughts?

It seems pretty clear to me :)

If the admin disables dialback, it should be disabled

Unless the configuration option explains the behaviour you're explaining now, people are going to be surprised, and surprises aren't good when it comes to authentication protocols

and if you kept it with the current behaviour, you're right that a way to entirely disable dialback would be good

A kind reminder for XMPP related projects to do their setup if interested. Please also join this chat with all mentors latest once we have been accepted. xmpp:gsoc@muc.xmpp.org?join https://wiki.xmpp.org/web/Google_Summer_of_Code_2023 CC: dwd, thilo.molitor

I'm not sure that weblin is eligible, is it?

Because the license isn't OSI.

good point, I had a feeling we got an issue here