On Mon, 18 Mar 2019 at 18:08, Ralph Meijer <ral...@ik.nu> wrote: > 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. >
Yeah, and bots, and so on. I'm convinced we need the functionality as-is. > * 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. > > Indeed, many XML nodes are named "node", to reflect both nodes and nodes - though we never encode the node identifier in the node, which is interesting, and rarely transport nodes on their own, so nodes never contain nodes (but nodes named "node" of course, contain nodes). You're right, we should stick to calling them node, there's less chance of confusion. :-) > > > * 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. > > I thought that was clear enough from the text. Archives of other streams are considerably more niche, at least for the most part. > 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. :-( > > Yes - also, if you have multiple clients, and on some of those you don't normally catch-up on most chatrooms, do you want those clients to have to get all the chatroom traffic during catch-up? > * 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? > Given a message, (some/many/rare) clients need to know who actually sent the message. This means knowing detailed information about the sender - we can do this in (roughly) three ways: * Include the key information in the message itself. This is roughly what we're doing in the <mix/> element currently. * Include pointers to the information. MUC does this pattern, but it suffers where the pointer expires (points to someone who is no longer an occupant/participant) * Include pointers to the information and expect client to locate that information in the *archive* of the participants node. MIX started off on the third option and has moved to the first, generally. > > > > * 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. > > You're allowed to disagree. Someone has to be wrong, after all. :-) > > > * 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? > > If you have the stable identifier - and I think we actually always do - then you can derive the jid if its hidden, and you need it. But you really only ever need <nick/> for anonymous senders. > > > * 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: > > But messages come from the JID of the channel with the stable > participant ID of the participant that sent the original message to the > room. How is this different from MUC? > > It isn't. I wrote my notes as I went, and I admit I've drifted toward whimsy on this one. > > > * 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. > > Alternatively, as discussed at the Summit, as above but with these > differences: > > b) MIX channel additionally gets a presence subscription from the user > (see below) and sends messages to the full JIDs of available resources. > Potentially it could filter on clients supporting MIX by CAPS. > > c) unneeded > > Nice. > As for the MIX channel and client arranging for the presence > subscription of the channel to the user, I think the mechanics from > XEP-0379 (Pre-Authenticated Roster Subscription) could work well here. > The join response could contain a child element that carries the > pre-auth token, and then the client proceeds with section 3.4. I don't > think the normal roster-add dialog should be shown here, though. The > whole exchange could be done without user interaction. > > Yuck - clients can just do <presence type='subscribed'/> along with the join instead, and (hopefully) pre-authorize the subscription on servers that support it. Otherwise, they can just silently accept the subscription. > The big advantage of this approach that there's no MUC-style leave-join > behavior from the perspective of the room. Of course there are some > drawbacks compared to the server-assisted approach. Messages could be > not consistent if there's a presence delivery issue. Hopefully MAM can > cover that, by having the local MAM server not drop messages of type > `groupchat` (see also that other mail promised above), and/or by > querying the MIX MAM archives of the channel and all the nodes > subscribed to. > > I feel the drawbacks concern corner cases and not worse than with MUC. > We will have to swallow them until servers do support MIX. > > I think MUC < HalfMIX < FullMIX - I don't dispute that a PAM-less "Half MIX" is inferior, but I think it should have clear advantages against MUC. > [fn 1] Having 'urn:xmpp:mix:nodes:messages' (plural) and > 'urn:xmpp:mix:nodes:presence' (singular) feels a bit inconsistent. "Presence" is somewhat plural. (I was going to say the singular was "present", just to wind you up). One would certainly say "This stream contains messages" and "This stream contains presence". Dave.
_______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org _______________________________________________
