On Mon, 18 Mar 2019 at 17:07, Steve Kille <steve.ki...@isode.com> wrote:
> Dave,
>
>
>
> Thanks for all this input. Let me go over it.
>
>
>
>
>
> *From:* Standards <standards-boun...@xmpp.org> *On Behalf Of *Dave
> Cridland
> *Sent:* 12 March 2019 12:01
> *To:* XMPP Standards <standards@xmpp.org>
> *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*
>
>
>
That would, mind, be a breaking change - so I hope you're bumping the
namespace.
>
>
> * 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.*
>
>
>
MUC requires the last N messages to be kept if a history replay on join is
desired, but nothing beyond that.
But archiving isn't always desirable, indeed.
> * 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.*
>
>
>
Ah, yes - that's the use-case I wasn't thinking of.
> *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.*
>
>
>
Everything has nodes in XMPP. Even at the XML level.
>
>
> * 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?*
>
>
>
I think we always support both models implicitly. The issue is that the
client has to guess which one to use, so MIX-PAM has to be able to tell the
client when it joined. Efficient support of clients and slow links probably
means that we need to do both, but it feels like an area where we could
improve - perhaps MIX-PAM could mediate MAM queries and service them from
the local cache if available, rather than just dumping messages unfiltered
into the "general" MAM?
>
>
> * 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.*
>
>
>
This is what I thought.
> *On Sending, you must send a Nick if one is set. Of course you need one
> for JID Hidden.*
>
>
>
I don't think either of those statements are true, are they? §7.1.6 and Ex
27 don't discuss the sender putting in a nickname, and I don't think
there's any difference between jid hidden and jid visible except what the
jid is, is there?
> *Presence (XEP-0403 3.5) is also clear. You must share the Nick if set.
> Again, no Nick only works for JID Visible.*
>
>
>
Again, looks to me like if the nickname isn't set, it'd all work fine.
> * 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*
>
>
Specifically, I'm suggesting replacing:
<message ...>
<mix xmlns='..'>
<stuff-here/>
</mix>
</message>
with:
<message ...>
<participant xmlns='..'>
<stuff-here/>
</participant>
</message>
where the <participant/> here is identical to the definition in §4.7.3.
The two elements are almost identical anyway - the major difference was the
possible inclusion of the submission-id, but that's now gone.
>
> 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.*
>
>
>
It's also a decision that's easy to postpone.
>
>
> 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)*
>
>
>
I don't think it's needed - especially if the element becomes the
participant element - but I've a nagging feeling it might prove useful, and
it should be a small enough number of characters to be a non-issue.
An interesting benefit of this is that in a Jid Hidden room, there's no
need to include the <jid/> element anymore if the stable identifier is
known (including within the <participant/> element as used in the
participants node).
>
>
> * 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.*
>
>
>
I feel a whole new XEP needs to fill this rather gaping hole.
>
>
> * 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.*
>
>
>
See above.
> * 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 agree.
> * 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. *
>
>
>
Agreed.
>
>
> 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.*
>
>
>
I think it's almost certain that without MIX-PAM, there will be a slew of
multi-client issues left unfixed.
It might be worth looking at the various "MUC Lite" proposals to see if
there are any cheap ways to partially address these that have already been
thought of.
>
>
> 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).*
>
>
>
It's an absolutely unapologetic hack, yes.
The question is can we get something that - while certainly flawed - might
be sufficiently better than MUC that we can use it as a stepping-stone?
> *I’d like to see other opinions on this, before I consider any editing*
>
So would I, very much.
>
>
>
>
> *The changes noted above have been made and pushed as a XEP-0369 update.*
>
Thanks!
>
>
>
>
>
>
> Dave.
>
> *[Steve Kille] *
>
>
>
> *Regards*
>
>
>
>
>
> *Steve*
>
>
> _______________________________________________
> Standards mailing list
> Info: https://mail.jabber.org/mailman/listinfo/standards
> Unsubscribe: standards-unsubscr...@xmpp.org
> _______________________________________________
>
_______________________________________________
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
_______________________________________________
