Re: [Standards] MIX
Hi, I started working on this reply last week, I still need to fully address the PubSub/MAM/MIX thing, but that'll have to be a separate message. The rest is below. On 12/03/2019 13.00, Dave Cridland wrote: Hi all, I've been writing a quick and dirty implementation of MIX. > > [..] > * 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. In general, I think that explicit is usually better than implicit. While I can see how a sensible default might be useful. It brings up some issues with users that use multiple different clients. Say that a server defaults to 'messages', 'presence', 'participants', and 'info'. Most desktop clients currently show presence in a side panel. Mobile clients, though, usually don't have/reserve screen real-estate for this, so wouldn't want to receive that. I'm going to guess that therefore, mobile clients might not subscribe to the 'presence' node, when joining [fn 1], whereas desktop clients would. As node subscriptions are per user, not per resource, if you joined with that mobile client, you might not get presences in your desktop client. The desktop client might subscribe after the fact, when it finds out, but that's not ideal. Of course a solution might be CAPS based notification filtering, but this requires your server to support MIX. This would also help the suggestion of a set of default subscriptions. As for participants with no subscriptions, I think there is a valid use case for this: bots. My suggestion is that we maybe wrap the elements in an element that may be empty to denote no subscriptions, and absent to accept defaults. * I'd dearly love to s/node/stream/ for the nodes within a channel. And only refer to PubSub nodes being the thing that implement streams? Ok with me, but I wonder how that jives with the protocol, with `node` attributes in many places. * 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. First of all, it should be more explicit that when we talk about the MAM archive of a channel, we mean the archive of the _messages stream_, not the other streams. Indeed the upshot of having your own server record the history of messages from a channel, is that you get the combination of messages from all the streams you've been subscribed to. Also, it just comes in along with all of your other archived messages from contacts, instead of having to explicitly query all the archives of channels you are in. To me, using MAM on the channel and other streams is useful for these cases: * Seeing what's in a channel without joining. * (Partially) back-filling a channel's history after you joined. * Maybe cover messages missed because of s2s outages? That said, our implementation actually discarded stanzas of type 'groupchat' from the user's archive, and indeed relied on the MIX MAM archive. :-( * 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? It is not clear to me why a nick would need to be required. In our own implementation, we only had non-anonymous rooms, used the user's phone addressbook to match JIDs, and filled in the blanks with vCard requests. * 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. [..] I don't understand what this is about. Can you expand? * 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. I disagree, but will respond to this in a separate thread, as this is a big topic itself. * 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
Re: [Standards] MIX
On Mon, 18 Mar 2019 at 17:07, Steve Kille wrote: > Dave, > > > > Thanks for all this input. Let me go over it. > > > > > > *From:* Standards *On Behalf Of *Dave > Cridland > *Sent:* 12 March 2019 12:01 > *To:* XMPP Standards > *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: > > > > * 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 element already defined > elsewhere. > > *[Steve Kille]* > > *I didn’t know about . This is sensible, and also avoids the > need for any special handling for the sender copy. * > > *Have removed 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
Re: [Standards] MIX
Dave, Thanks for all this input. Let me go over it. From: Standards On Behalf Of Dave Cridland Sent: 12 March 2019 12:01 To: XMPP Standards 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: * 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 element already defined elsewhere. [Steve Kille] I didn’t know about . This is sensible, and also avoids the need for any special handling for the sender copy. Have removed 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
Re: [Standards] Move XEP-0353: Jingle Message Initiation to Draft
Am 14.03.19 um 15:52 schrieb Xander Dumaine: Genesys implemented XEP-0353 for both voice and video calling, and we've been very happy with it. The following code uses it on top of code written by Lance and for jingle.js and stanza.io https://github.com/purecloudlabs/purecloud-streaming-client-webrtc-sessions/blob/master/src/index.js https://github.com/purecloudlabs/purecloud-streaming-client-webrtc-sessions/blob/master/src/index.js#L575-L635 https://github.com/xdumaine/jingle-stanza/blob/master/stanzas/jingleMessage.js I'm unable to share the XMPP server implementations, but we've implemented in two separate components, one which coordinates voice calls and is a bridge between XMPP and SIP to a PBX, and one which coordinates video conferences between both SIP backed and XMPP backed media servers. We also use this for p2p video calls. Thanks, Xander Dumaine Looks like the mailing list ate this so reposting. Thanks for the feedback Xander! ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
