Hi,
On Mon, 2026-05-11 at 15:17 +0100, Dave Cridland wrote:
I think bare jid occupancy is sufficiently embedded into the concept that it's hard to remove, or at least hard to add in cleanly later. It doesn't work "equally fine" with XEP-0045, which is why there's a bunch of compatibility requirements around that exact case (ones you've commented about on the PR).
Just to confirm, the bare jid occupancy as described right now is:
1. Have the user display as present even when they are not (optionally modify the presence in that case)
2. Send around messages that are to be discarded
Those two things don't in any capacity depend on addressing.
The first part is explicitly described to work for both MUC1 and MUC2, thus seems to be independent of addressing.
The second part is underdefined in the proposal, but likely is meant to send around the messages exactly as they would be if the user joined using the traditional way, just that the bare jid is used in the to attribute instead of the full jid and thus messages get discarded. It would thus work equally well for MUC1 and MUC2 addressing, as the address in the from attribute is ignored and discarded. The only thing you are doing by putting it into this XEP is to make the MUC2 addressing mandatory for those messages. I don't see any need for this. If there is an element that is added as part of a presence-based MUC join to signal MUC2 addressing, the same element could be added to the bare jid occupancy join to signal MUC2 addressing, and when it's missing, old MUC1 addressing could still be used (on those messages that are discarded anyway).
Again, implementation isn't required for Experimental (or even Stable!), according to XEP-0001.
Exactly. Neither do useless/wrong/incomplete implementations provide proof that the XEP is implementable. That was my whole point.
I am not asking you to fix the implementation to show me that it's implementable, I want you to fix the specification.
The only part of the specification that is sufficiently detailed to be implemented at this stage is the bare jid occupancy: a means to be displayed as online when offline.
The addressing part still has too many unknowns to do anything useful with it if implemented. For some of those unknowns there may be reasonable sane things to do (also rewrite addresses in messages), for some it already gets more complicated (MAM responses, because if those are requested before the client joined the room, the server doesn't know if they should reply with MUC1 or MUC2 addresses) and for some there is just no meaningful thing one can do (discover the nickname of a message sent by a user no longer an occupant).
Also according to XEP-0001 "implementation of an Experimental protocol is encouraged in order to determine the feasibility of the proposed solution". It even says so twice. If I can determine the feasibility of the proposed solution already without implementing what is written in the XEP, what is the use of encouraging others to implement it? This is what Experimental means to me: "hey people, try implementing this and tell me what you think". And I don't get the vibe that's what you want to tell me.
If you want to say "hey people, I'm trying to come up with something, but I don't know how and what exactly, let's work on this document under XSF IPR policy", you don't need to make it Experimental. You can just say this and avoid any doubts on whether your XEP is encouraged for Experimental implementations or not. And if you think we need a venue that is explicitly under XSF IPR policy but not ready for experimental implementations yet, then talk to the board.
Marvin
PS: IPR policy applies as soon as an extension is submitted for consideration. When is that exactly? Shouldn't it be enough to open a PR against the xeps repo?