XSF Discussion - 2024-08-15

Guus, One for you (possibly). '45, 7.2.1, "If the user does not specify a room nickname [...], the service MUST return a <jid-malformed/> error" - but if the service knows, and will enforce, the nickname anyway, can't it just join the user with that nickname?

dwd: in case the user is a registered member, you mean? How would it otherwise know the nickname?

Guus, Yes, something like that.

That's probably technically an acceptable shortcut, but I'm wondering if it would mostly act to hide a deeper problem. If (existing) clients currently do not send the nickname, I'm guessing there's more trouble. By allowing that traffic, we might see a surge in undesired MUC joins that are based of malformed presence (which may or may not be malformed join stanzas - maybe they're completely different stanzas?)

Do you see some kind of new feature/functionality that's enabled by this, rather than this being 'just' an optimization?

More than I'm thinking aloud. And yes, there's no way for the client to know if it needs to supply a nickname, as you say, so it's not very useful.

XEP-0045 specifies in Sending a Private Message https://xmpp.org/extensions/xep-0045.html#privatemessage: > This privilege is controlled by the "muc#roomconfig_allowpm" room configuration option. How does this map to this being optional/required functionality?

What is optional? PM?

the restrictions implied by allowpm

Also, I don't think it's defined how an illegal message is to be rejected.

i dont understand your question, maybe you can rephrase it

or rather at what you are getting at

If the room configuration does not define `muc#roomconfig_allowpm`, does that mean that private messaging is not supported by the implementation at all, or does that only mean that the room does not support control over exactly who can send private messages (maybe suggesting that anybody can send PMs)?

It means unspecified I guess, but in practise that probably means normal uncontrolled pms

i would expect a server not supporting pms still sending allowpm = false in the disco info

but if it is missing i would default to allowed as a client

there is really nothing bad that can happen, user tries to PM, server answers with not supported

the disco info is really just there to provide nicer GUI information to the user

iirc some rooms allow PMs only to mods and some clients refuse to send any

allowpm isn't a boolean value, it is a single-list of roles

(indicating which role is required to be allowed to send a pm)

ok, so its empty ? if none is allowed

Hence the problem I mentioned (where any can send but the recipient is restricted based on role)

I'm confused by the wording of "This privilege is controlled by" - that kind of suggests that the option _is_ a boolean