ProtoXEP: MUC2 Addressing/Occupancy (only)

[dwd]

Take two...

Hopefully this one takes less than a month.

This only deals with the addressing and occupancy, which I believe are intrinsically linked.

There is a PoC server-side implementation here: igniterealtime/Openfire#3305

[mwild1]

While I appreciate flexibility in specs when possible, I would suggest making this a 'MUST'. The reason is that we have a bunch of extensions which build upon occupant-id, and if the same occupant has different ids depending on which protocol is used, things won't line up.

[mwild1]

I encountered this issue in my work on a GC3 prototype. This solution is a bit hacky, but I can't think of anything better.

I think the precise translation should be specified in the XEP though, so that clients can map from occupant-id to room JID in all contexts.

[dwd]

You could do it by rejecting any nickname that is (for example) a 40-character long string consisting only of hex characters, too, but that's going to be a weird UX.

In any case, I accept your point entirely; if we always prefix by a known character, and strip it, it obviates your other comment rather neatly too I think - we can just mandate the resource string be ("-" + occupant_id) and mandate that the occupant-id is the same XEP-0421 occupant-id in classic '45.

[singpolyma]

Can't you reject any nick that is an occupant id? Or I guess the fear is that a future join could suddenly overlap with a previous nick? However in that case one could kick the nick-based session at that time?

[mar-v-in]

What is the from attribute of a MUC PM message when sent to an occupant that has a MUC1 presence-based occupancy session and a MUC2 bare jid occupancy session at the same time?

Or will this be send as two/multiple messages with different from attribute? Won't this confuse the clients because they now end up receiving multiple messages for the same message, but with different from attribute?

[dwd]

It really depends on how we model occupants, which is an open question with a thread on the Standards list.

The user's server's support of MUC2 is intentionally primitive at this stage, but I could see it simply not fanning out identified PMs at all, or we might need client signalling to indicate support for MUC2. I appreciate this isn't specified.

I'd expect the server would send the PM under MUC1 to the MUC1 connected client(s) as well, that'd be unchanged.

[mar-v-in]

It really depends on how we model occupants

Shouldn't it be the purpose of a XEP titled "MUC2 Addressing/Occupancy" to specify how to do Occupancy in MUC2. And not leave that part out and say "we are still discussing on list"? What is the value of this XEP if not for specifying that?

[mar-v-in]

There is no writing which 0310 annotation should be used. 0310 currently only has two:

• connection-paused for when a BOSH connection is paused
• server-unavailable for when s2s connections break

Both seem unsuitable for this purpose.

[dwd]

It'd be connection-paused I think; it's not listed as being specific to BOSH anywhere, though that was the only example given.

I'm not wed to using XEP-0310 here, but I thought something ought to be present.

[mar-v-in]

The only mention of connection-paused outside the bosh example is in normative text related to bosh:

Benvolio's client then uses the BOSH 'pause' feature for suspending the session. The montague.lit server MUST then send an annotated presence to Romeo's client saying that Benvolio's session has been paused. This MUST include the connection-paused element, MUST include a 'from' attribute of the entity doing the annotating (montague.lit) and MAY include a human-readable description element

In other words, there is no writing in XEP-0310 that connection-paused may be used except for the one case of BOSH.

[singpolyma]

Why would we send presence for "occupants" who are not online? Isn't that just confusing?

[dwd]

'45 ties presence state to occupancy, yes, but this spec aims to break that tie. Eventually, I'd expect to be able to PM offline occupants, bring them into group calls, and so on, none of which are possible if they're not occupants, or if the other clients don't know about them.

[dwd]

Affiliations don't have any stanza routing, and an affiliation of "none" is equivalent to, and implemented as, no affiliation at all. Every Jid in the network has an affiliation with every chatroom in the network otherwise. Affiliations are also given (or not) with the jid. In a [semi-]anonymous room, the affiliations are not accessible as a list anyway. OMEMO in a MUC relies on this affiliation list being public; and honestly it's a hack. If we can "fix" offline occupants (and this is done here via bare jid occupants) then we can handle these use cases much better.

If you want to look at it another way, in PubSub the affiliations are the same (more or less), but the occupants in '45 are equivalent to subscribers in '60. These are clearly orthogonal in '60; they are in 45 as well.

This conversation is a waste of time as you're clearly going to reject this anyway, but the intent here (as noted in the document) is that bare jid occupants give us the tooling and structure to build more features on top, such as push notifications and similar features that require stanza routing. Bare jid occupants get stanzas routed to them within this spec; affiliated users do not.

[mar-v-in]

Bare jid occupants get stanzas routed to them within this spec; affiliated users do not.

The only thing the spec does is to request the server to not act RFC6121 compliant by not returning an error (which they MUST, according to 8.5.2.1.1).

We already have enough examples for "failed" XEPs that provided the "tooling and structure" but not the actual usecases and then later it was found they are neither fit nor needed for the actual usecase. I would suggest to first create XEPs for the actual usecases and once you established two or more XEPs for actual usecases that could profit from having a common tooling and structure, you can still create such as a XEP and adjust the usecase XEPs to use your tooling XEP.

Regarding stanzas routed, there is prior art to using affiliation for that. Tigase supports that out of the box, Prosody has a module for this (mod_muc_offline_delivery). As part of the XEP-0077 registration form, clients can request to receive messages to their bare jid when offline.

For push notifications the above affiliation-based stanza routing can be used. But, there is also prior art to allow clients to register for push notifications at a MUC using the same protocol they use for registering push notifications on their own server (that is XEP-0357). Again this works without requiring a "bare jid occupancy": offline users remain offline, it's just that they receive a notification.

I don't see why routing for push notifications should be tied to a "bare jid occupancy" that shows the user as online in the room when they actually are offline. As prior art has shown, those two things are completely unrelated and push notifications can work perfectly well without being displayed as a room occupant, only using affiliation and potentially even without that.

[dwd]

Taking your paragraphs in order:

1. That's the minimum required, and we're breaking a MUST by mutual consent, so it's OK (in case you think that's wrong!). This alone allows some useful behaviour, though, despite appearances, and I'm very confident that other capabilities will surface.

2. We have lots of cases of very successful XEPs that are "tooling and structure". XEP-0060 is utterly unsuccessful by most measures, except that it's heavily used in XEP-0163 - which itself is also just tooling and structure. PEP in turn is only really successful outside of its stated goals of providing a framework for rich presence, which we really don't use. Instead, it's used most for XEP-0223, itself a tooling and structure XEP to replace XEP-0049, a tooling and structure XEP that had huge traction. We also have lots of cases of XEPs which are not "tooling and structure" which have failed, like the MIX suite, or any of the myriad E2EE attempts, or XEP-0194 - XEP-0197 (some "interesting" suggestions for rich presence). I don't think that "tooling and structure" is the right discriminator, based on the evidence we have.

3. Yes, I'm aware - I used to like this approach, but after a lot of thought I think it's architecturally the wrong approach (possibly why nobody wanted to standardise it). Muclight (MongooseIM) takes an approach closer to this specification, but resource strings are mandated to be bare jids rather than resource ids, and it's far too oversimplified. MUC-SUB (ejabberd) uses an explicit subscription, wrapping offline MUC messages as pubsub events [I've only used in in closed environments with a client client per user, no idea how it copes outside of that]. I think "subscription to messaging" is much like "subscription to pubsub events", and thus orthogonal to affiliations, which are "permission levels" fundamentally. Even if we used affiliations for this, in order to get visibility you'd still need to present them as occupants (including in anonymous rooms), and you'd need it to be opt-in (like Prosody's module), and you still need server participation in some form to make it useful (almost - ejabberd's approach skips this being essential I suppose). So you're proposing doing all the same things as this specification, just combining the bare jid occupants into affiliations, without any gain as far as I can tell.

4. XEP-0357 explicitly precludes this on security/privacy grounds, and I think that's the right call. It uses a shared secret, and since this can be used to push essentially anything to the push server and thence the client device, I don't think we should be encouraging this. On the other hand, XEP-0357 can work with this specification with no changes to the wire protocol at all, which seems like a neat emergent property, and gives me a little confidence that this is the right direction.

5. I heavily dispute "perfectly well" - but also the bare jid occupancy only shows users as online in the compatibility mode for classic XEP-0045. "Online" and "Offline" is not the same as occupancy, but it's conflated in '45 - you simply can't be "in a room" without being online. "Subscribed" and "Unsubscribed" is occupancy. "Member" and "Owner" is not occupancy. I think, if you're defining "occupancy" as "who will see the messages I send to the room" - and that's the core of the definition I'm leaning toward in this specification - you have to show them as occupants in the protocol. I'd like a better way for compatibility, if there is one, but I feel any compatibility layer is going to have some hackery to it.

[mar-v-in]

I feel that to some degree this seems to really be about wording. To me an occupant of a physical room is physically present in this room. It's not enough to receive notifications that something is happening in the room to be considered an occupant. When we talk about hybrid meeting rooms, we may consider people occupant not physically present in the room, if they're currently (online) connected using the meeting room system and therefore able to speak and listen to and see other occupants as if they were physically in the room. If someone joins the room remotely and then loses connection, we typically consider them no longer an occupant (we might wait a minute for them to reconnect, but certainly being disconnected for hours doesn't make you an occupant anymore). Often, but largely independent to occupancy, you can be subscribed to a meeting room, meaning you are notified of events taking place there and even have access to room recordings.

Anyway, ignoring wording for a while, your bare jid occupancy currently has two purposes:

1. Display to other users as present in the room when offline or at least display differently to how other offline users and offline affiliated users are displayed.
2. Subscribe to notifications for incoming messages.

Not only do I fail to see how or why these two things need to be done together with the proposed addressing change, but also I don't see why they need to go together.

If I look at only these features individually, I can generally see why people might want to have them. And individually for them, I'd say the following:

• The user should be able to freely pick the presence send for him while offline (e.g. they might want to have their legacy pgp signature in it). It would also make sense to add a delay element or similar.
• Instead of having the message send as a type groupchat message that current RFC rules require to reject and that also mandates active server support, you could use XEP-0297 in some container element, which would even work without any further server support and allow current online clients to discover their messages if they do support such subscriptions.

[dwd]

OK, I think because the join reports occupancy, we need the joiner to understand bare jid occupancies, and I'd rather minimize the numbers of extensions to get there. That's why I've kept these two together - as noted before by me and others, '45 has ended up with lots of interlocking extensions and it'd be nice to avoid the patchwork. Ideally, I'd build the entire replacement in a single XEP, batteries included, such that '45 could be eventually deprecated, but at least I'd like to get interlocking things combined. You're right that it's physically possible to make these distinct extensions, but then one would have to be predicated on the other, and if we end up putting if and how occupant jids forward traffic to the "real" jid behind them in the same XEP - and I think that's also ultimately sane since it's not specified anywhere currently - then bare jid, online, offline, etc all end up in the mix. (If you'll pardon the expression).

I agree that having the user pick their presence would be nice, good call.

For the rest of your note, and much of your comments in this thread, it could be summarised as "I wouldn't have done it that way". Which is fine, of course. But I don't follow why "I would have done it differently" means that this specification is so wrong as to be rejected.

To the specific, as I have said, ejabberd's MUC/Sub does much of what you suggest; it's wrapping in pubsub events rather than forwarded but the essential principle remains the same. MUC/Sub uses full-jid messages of type normal, so if the client is offline they don't get fanned out, but it also means you're reliant on stable resources to work properly, and there are certainly some quirks with build-up of subscriptions. My overall experience with MUC/Sub is that it's a pragmatic attempt, and quite reasonable given the constraints it needs to work within, but server involvement would be considerably better.

As I've said a few times (sigh), I've had significant operational experience with both MUC/Sub and Muclight over the past few years. I've worked on systems based on one or the other for most of the past 7 years. I dislike them both, but they equally both have features that - if done properly - would be highly beneficial. MUC/Sub was never submitted as a XEP (as far as I can recall), but had it been when I was on Council I wouldn't have vetoed it. It's ugly, and not for me, and has design problems in its current form, but it's not actively harmful. Muclight I did veto, but my reasoning was that it was a dead-end - incompatible with '45, no obvious way to extend it, and precluded anonymity. I didn't block it for not having a way for users to join rooms (really - it's by design); I assumed that would have been added during Experimental. I work on it every day now, and still dislike it - but the clean offline messages are very convenient, and luckily the other problems aren't an issue for me.

But for roughly two and a half years, my work was a system based off MUC/Sub, and while that is a design that respects the existing ecosystem much more, it was also really awkward to work with since messages change shape depending on the client state, you're utterly reliant on stable resources, and doing gatewaying middleware was awful. Admittedly, the latter is a niche case.

Ultimately, I think server-mediated MUC is going to be useful for a number of cases, and is in any case the right architectural model, so we may as well get it started - I've said as much since around 2010 or so, so I get to claim consistency (for once). This is also why MIX got server involvement in early; but it also was such a violent departure from '45 for so little gain - I'd like to this I've got the balance better with the effort/benefit here. For one thing, I think the IM server changes for minimal conformance are very straightforward; those on the room side are much more involved.

You've mentioned a couple of times that the RFC mandates rejecting groupchat messages; this is true of course, the specification points this out. You also seem to imply this means we can't change that. But this is a negotiated change. The RFC (RFC 6120, this time) also mandates using the original SASL profile for authentication (in section 6.1 / 6.3.1); SASL2 changes this, too. Servers using XEP-0078 were, similarly, still conformant to the RFC. Deviations from the base spec are fine between consenting entities.

[mar-v-in]

For presences, this switches position of the occupant-id and the nickname (between presence payload and from attribute). I assume the same should happen for messages, but there is no sufficient description for that. I understand the <nickname> is supposed to be in the <x> element, but there is no such element on messages in MUC, so do messages no longer include the nickname at all? If so, how do I know the nickname of the sender of a message after they left the room?

[singpolyma]

"bare jid occupancy session"? are we conflating occupancy with membership now?

[dwd]

No, quite the opposite. There's a whole section later on which explains how clients cause a bare jid occupancy to come into existence. But they are occupancies, not affiliations.

[singpolyma]

This is an interesting idea, but commented out? Probably it should be in or out?

[dwd]

Council insisted it should be removed last time.

[singpolyma]

I'd suggest to re-use https://xmpp.org/extensions/xep-0172.html -- probably right on the presence too, without the intervening layers.

[dwd]

We could. XEP-0172 currently explicitly rules out its use in MUC, so I avoided it. But that can be revisited.

[singpolyma]

Since this can't be done if the nick isn't resource-compatible, there could be a clarifying note reminding that any target JID is actually fine, since the server will know the desired nick from the enclosed nick element or otherwise and issue a "joined you with different name" flow as per 0045

[dwd]

There could indeed. As noted, I'm quite sure this doesn't match the quality gate for Stable. But given you have identified the case, and suggested the obvious fix, I'm sure you agree this can be addressed in Experimental.

[singpolyma]

Another commented out section.

[dwd]

Another requirement to remove it from the spec by Council last time.

[singpolyma]

I assume this means to say that a presence type=unavailable should be sent for such "bare jid occupants". While I remain opposed to the concept, this is much less bad than the above proposal to send an available presence with a tag no one implements IMO

[dwd]

I think that's what it does say.

XEP-0045 seems to have once allowed unavailable presence of member affiliations, judging by the status codes 102 and 103, but I'm pretty sure it's unsupported by implementations.

But having bare jid occupancies means we need a mechanism to signal them when they're offline, and the cleanest way is unavailable presence (otherwise you just get compatibility shims like I've specified for MUC1).

And I agree that XEP-0310 isn't implemented, but it seemed like the closest fit. As noted elsewhere, I'm not wed to that approach.

[singpolyma]

What is the purpose of this mam summary? And why is it in with the subject?

[dwd]

Most clients prefer using MAM to the MUC history, and supplying the MAM summary gives a useful hint as to whether they need to run a MAM query at all. There's ways we could make this more efficient, by passing in MAM ids into the join, but those then cease to be backwards compatible, and equally are easy to add in later.

[singpolyma]

Is the purpose here basically to allow the user to get access to the subject without getting live messages? MAM they can get already. Registering as a member or other affiliation seems like it should use the registration protocol.

Or I guess this is less about "joining" and more about "subscribe to MUC-PAM"? Do we need a MUC-PAM XEP for people who want that kind of thing?

[dwd]

It's returned because it seemed like it might be useful. Like everything in this spec, we might decide it's not useful.

[singpolyma]

Maybe we should find out if something is useful before writing a spec for it? ...