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. * Section 7.2 stipulates that archiving of all messages is mandatory - did you really mean that? * 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. * I'd dearly love to s/node/stream/ for the nodes within a channel. * 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. * 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? * 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? Should we have a all-participants node containing every participant ever (so a get-item is simple for lookup)? Should MIX messages include the stable participant id? * 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. * 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!). * 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: * 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. 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. 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. 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. Dave.
_______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: [email protected] _______________________________________________
