XSF Discussion - 2025-09-30

When a client joins a MUC room, the service sends the client a message stanza with the subject of the room. What are considerations for that stanza to be either a copy of the stanza that was originally sent to the room to change the subject, vs. the stanza being a recomposition based on the subject text, the nickname of the author and the timestamp?

Put it slightly differently:_if_ there is additional data in the original stanza that changes the subject, is it desirable to filter that data out (preventing it to reach other clients), or is it desirable to keep that data with the subject change broadcast?

I assume it's desirable to keep.

but I also assume it's not specified.

I don't have a "normative" answer for you, but as a data point slidge does a "recomposition based on the subject text" (in many cases there is no "original stanza" anyway)

(bridges are different in that regard anyway because they need to provide consistency between the XMPP and the remote side)

I would tend to think like jonas' though, I think extensions that the MUC service does not understand may be useful. Maybe there are security considerations though, I don't know.

> (bridges are different in that regard anyway because they need to provide consistency between the XMPP and the remote side) haha, well, consistency regarding subject is hard. MUCs have mandatory subjects (they can ben empty strings, but still), most networks do "pinned messages" (emphasis the plural) instead, I do my best but it is not perfect ↺

> I would tend to think like jonas' though, I think extensions that the MUC service does not understand may be useful. Maybe there are security considerations though, I don't know. That's exactly why I am wondering.

to me, any <message/> you send to a MUC (with or without <subject/>) you have to expect to be broadcast to all participants

at least without further specification

to all *current and maybe future* participants (considering MAM) ✏

so there should not be any security surprises there

Yeah, that's right. I'm looking at a 'muc join' scenario, but that shouldn't differ (apart from the timestamp?) from a "live" subject change, I suppose.

indeed

I don't remember the exact details but I do remember having a use case for putting additional extensions into the subject

Ok thanks

But in practice the server I was using stripped that information (and/or didn't include it when recreating the subject message). So I never implemented it

Hello everyone!

I just wanted to let you know that the PR for the XMPP Newsletter September 2025 is open and ready for review.

https://github.com/xsf/xmpp.org/pull/1565

If you made a release, gave a talk, made a presentation, wrote an article, guide or how-to, published a video or any other bit of news during the month of September and you feel it should be published on the Newsletter but it's not, please let head over to the Comm MUC and let us know.

Also, don't hesitate to ping us if you know about anything that we may have missed or that you think that should've been added to the Newsletter!

Thank you for your attention!