Ralph, > -----Original Message----- > From: Standards <[email protected]> On Behalf Of Ralph Meijer > Sent: 18 March 2019 18:07 > To: [email protected] > Subject: 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 <subscribe/> elements in an element > that may be empty to denote no subscriptions, and absent to accept defaults. [Steve Kille]
I don't see that there is anything wrong with the current text. You note here the idea of a "server default". This adds complexity to the current model (client chooses). I can't see the benefit. > > > > * 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. [Steve Kille] Let me know if there is anywhere that the text needs clarifying > > 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? [Steve Kille] Yes. This all seems useful. I think the benefits are clear, but I also agree that the change to make the archive optional is sensible. > > 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. [Steve Kille] Nicks are NOT required. If you think the text is not clear, let me know what to fix > > > > * 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? [Steve Kille] This is for Dave > > > > * 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 for non-anonymous MIX channels, and are in any case only used > > in '404 for private messaging (I think!). > > What are you suggesting instead then? [Steve Kille] For Dave. I don't think any change is needed MIX-PAM section deleted [Steve Kille] Steve _______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: [email protected] _______________________________________________
