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.
* 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 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?
* 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?
* 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
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.
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.
[fn 1] Having 'urn:xmpp:mix:nodes:messages' (plural) and
'urn:xmpp:mix:nodes:presence' (singular) feels a bit inconsistent.
--
ralphm
_______________________________________________
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
_______________________________________________
