Dave,
Thanks for all this input. Let me go over it. From: Standards <[email protected]> On Behalf Of Dave Cridland Sent: 12 March 2019 12:01 To: XMPP Standards <[email protected]> Subject: [Standards] MIX Hi all, I've been writing a quick and dirty implementation of MIX. So far, I've started with an even quicker and dirtier PubSub, and glued in the MIX stuff on top. There's no MAM etc yet. The following are comments I've had so far, in no particular order: * <submission-id/> is sent to the sender for correlation. This assumes that messages sent from all the user's clients will have unique message ids - that's a stronger requirement than RFC 6120 dictates. It feels as though this could include the original full jid as well - or perhaps even instead - and might benefit from using the <origin-id/> element already defined elsewhere. [Steve Kille] I didn’t know about <origin-id/>. This is sensible, and also avoids the need for any special handling for the sender copy. Have removed <submission-id/> and added reference to XEP-0359 * Section 7.2 stipulates that archiving of all messages is mandatory - did you really mean that? [Steve Kille] This is needed for MUC compatibility. However, I think there are sensible non-archive use cases, so I’ve added text to relax this, but clearly warn of the “MUC Service” requirements. * Section 7.1.2 jumps through several hoops to ensure that joining a MIX Channel without subscribing to any nodes at all is a legitimate choice. I think the specification and implementation would be radically simpler if we didn't allow this - is there a use-case for this I'm missing? Without this, we can choose to have a "sensible default", or just make it an error. [Steve Kille] I can’t see any complexity as a consequence of this. Use case for no subscriptions is minimal, but might be wanted for a client that needs to send, but not receive. The complex bit is when you ask to subscribe to multiple nodes and there are ACI issues. I don’t think any change is needed * I'd dearly love to s/node/stream/ for the nodes within a channel. [Steve Kille] It would be neat, as stream is a clean way to think of things. But PubSub has nodes, not streams. * Section 7.1.5 suggests MIX messages should be archived at the server. This is very different to MUC, where clients always request messages directly from the MUC. It's a useful model with non-chat and other non-trivial cases, where the archive might actually be synthesized on demand from the source of whatever history is. Is there a rationale here? The existing MUC/MAM model seems to work very well. I imagine this probably doesn't matter, beyond clients having to guess when they joined a channel in order to redirect MAM requests. [Steve Kille] This model seems to arise naturally from the MIX-PAM model. Every message is sent to every client. It feels right to keep a copy at the client’s server, particularly to efficiently support multiple clients. It also works well if servers don’t have 24x7 connectivity. I do think we want to support the model of MIX-PAM server doing the archive. We could explicitly support both models, and have a MIX-PAM capability, so that the client does not have to guess. What do you think? * The XEP explains that a nickname is not needed, but also says it's needed for both presence and sending messages - or at least in Section 7.1.4, it says it's not needed if you don't do either. Does this mean that a participant without a nickname cannot send messages or presence? [Steve Kille] Nicks are genuinely optional. On Sending, you must send a Nick if one is set. Of course you need one for JID Hidden. Presence (XEP-0403 3.5) is also clear. You must share the Nick if set. Again, no Nick only works for JID Visible. * Old participants never die, they're merely removed from the pubsub node and require endless searching through MAM, or having all their data copied to the outgoing messages. MIX has lent toward both those options over its development, currently leaning toward the latter. Should we just include the participant element in the outgoing messages, instead of duplicating its contents? [Steve Kille] It does not matter much, but I think the current approach of including the information as cleanly as possible is best Should we have a all-participants node containing every participant ever (so a get-item is simple for lookup)? [Steve Kille] This does make it easier for the client, but seems like a real hack on the server side. Feels wrong to me, but can add if there is consensus to do so. Should MIX messages include the stable participant id? [Steve Kille] I don’t see why this is needed. For JID visible, you don’t need it. For JID hidden, it comes anyway (as part of the JID you get) * Nobody knows how MAM interacts with PubSub. I think it should store an archive of the stream of events emitted by the pubsub node: at least item publication events, and probably retractions. While this is all that's required to make MIX/MAM work well, I note that numerous other events also exist, which might be useful eventually. [Steve Kille] This sounds like a valid point, but I can’t determine any editorial actions. * Participants always have jids, even when anonymous. It's not wholly clear to me this is needed - the jids are the same computed ones used in presence for non-anonymous MIX channels, and are in any case only used in '404 for private messaging (I think!). [Steve Kille] I think that is right. Clearly, real JIDs need to be included. Anonymized JIDs are derived from stable ID, so there it is redundant to store. The wording is not clear, so I have tightened. * Having messages come from the channel jid allows for lots of flexibility, but does mean that in the "classic" chatroom case it's harder for clients to block participants without blocking the entire chatroom. That said, a MIX-aware server can help here, and a MIX-unaware server would struggle more in this case I think, which brings me onto: [Steve Kille] It feels wrong to change this. * I think MIX can be made to work (albeit less efficiently) without MIX-PAM. This last point needs a detailed explanation, of course, both in terms of motivation and design. Firstly, the motivation here is that currently, MIX needs a substantial fork-lift upgrade to get deployed. Every entity on the path of MIX needs to implement, and deploy, some MIX in order to work. The benefit of this is obvious, of course - it means an efficient, and very solid, design, and it's certainly where we need to get to. But getting There form Here is going to be difficult, since who wants to implement MIX in their client if the servers need to support it, and so on. By having MIX channel servers able to directly interoperate with MIX clients even if the home server doesn't support MIX, I think we're able to accelerate deployment. [Steve Kille] The motivation is clearly a good one. It seems clear that this should be supported if not overly disruptive. The changes needed are: a) A MIX client needs to determine if its home server supports MIX-PAM. If it does not, a "Direct Join" is used - which is simply exactly the same join but sent directly to the MIX with full jids. [Steve Kille] I think that makes sense. It can be optional for a MIX server to support this, so there is no overhead for a MIX implementation that does not want to support this. b) A MIX channel receiving a direct join implies the client's home server does not support MIX-PAM. It then uses bare Jids in its Participants items still, but sends messages addressed to the full jid of such clients. [Steve Kille] Going offline needs some consideration. Messages addresses to the full JID would be discarded. I think that this means that the direct client would need to leave before it goes offline. Also, if the MIX channel gets a bounce from the bare JID, it needs to assume that the client has gone away, and auto-leave the client. There is also danger of getting back into a slew of multi-client issues in MUC, which MIX fixes. A simple approach would be to only allow one Direct Join for a given bare JID. c) When reconnecting, a MIX client which has performed a direct join in a previous session may have to leave and rejoin - assuming it cannot maintain the same resource. [Steve Kille] I think the client needs to leave if going offline. This operation without MIX-PAM seems messy, once you get into the details (and there will likely be more). I’d like to see other opinions on this, before I consider any editing The changes noted above have been made and pushed as a XEP-0369 update. Dave. [Steve Kille] Regards Steve
_______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: [email protected] _______________________________________________
