On 3 January 2018 at 16:40, Steve Kille <[email protected]> wrote: >> >> * §3.9.5 / §3.9.6 still seem massively awkward to me. When we >> >> implemented this, we implemented it such that it was a single node >> >> which administrators viewed differently to ordinary participants, and >> >> it was easy enough to do that way. But our client access was deeply >> >> inefficient where we really wanted to show users by their real jids and >> names. >> > [Steve Kille] >> > >> > This all comes out of requirements (clearly agreed) to control JID >> > visibility. >> It is quite complex, but I think is a clean way to address the requirements. >> >> Well, there's two issues here: >> >> a) jidmap works fine if all its items might not be visible to everyone. This >> feels >> much cleaner than having multiple nodes to handle jid mapping for different >> access levels. >> >> b) Keeping the jidmap solely in a pubsub node made presenting the real jid >> against messages very painful, especially in the case where the jidmap >> contained many more items than the message node had archived messages. > [Steve Kille] > > What do we do instead???
I'm not sure. We could pack the metadata into messages on transmit, of course. Maybe we could include join options to handle what metadata gets packed into messages. But if the use-case is that you want to present users with the real messages by default, and you want historical messages shown, then the current mechanism is a real PITA. >> >> >> * §3.9.7 is curious - it implies that there may be presence here from >> >> non- participants. Is this right? Would this presence still be fanned >> >> out to all channel subscribers interested in presence? I feel I'm >> >> missing a use-case here. >> > [Steve Kille] >> > >> > This is not driven by a core requirement, but there definitely was a >> request/requirement somewhere to have participation by clients that are >> not participants. Default is "participants" only. This is >> complexity that I'd >> be quite happy to lose, but I am certain that there was a good reason it went >> in! >> > >> > >> >> I can totally agree that non-participant clients MAY be able to access >> message >> archives, and other read-only cases. But it seems wrong that a non- >> participant could share presence. > [Steve Kille] > > Might be sensible to clarify requirements for non-participant access to MIX > channels. Perhaps an Agenda item in Brussels? > Yes, sure. But I think it can loosely be anything could be visible to non-participants, but you cannot submit any data or get live updates without participating. (I can bend on the live updates, but I think the mechanics mean it's a natural requirement). >> >> * §5.3 - the node='mix' here seems superfluous, I think, though I >> >> could be wrong. >> > [Steve Kille] >> > >> > The reason for this is to support MUC/MIX sharing. If you don't see >> node=mix, the query is from a MUC client, and you should not send >> confusing MIX stuff. >> > >> >> I think that's needed in §5.4's disc#items, but not in §5.3's disco#info. If >> a >> disco#info response with both MIX and MUC confuses clients, something is >> broken in XEP-0030. > [Steve Kille] > > You are probably right that 5.3 is OK without, but given that MIX specific > information is returned, it feels safer to include. > No. If the MIX disco#info features are not safe to include in a normal XEP-0030 disco#info query, there's something gone badly wrong. It must, almost by definition, be safe to include the MIX information in the same response. I'm not even convinced it's not safe to include both MIX and MUC items in a disco#items response, but it would certainly be clutter at the very least. > >> >> In addition, how does a client know to try a disco#info with node='mix'? It >> would need to discover MIX support first, surely? > [Steve Kille] > > This is the channel. It will know MIX support from the domain. So a common pattern here is that a user is passed (or enters) a jid of the room/channel to join. The client needs to discover if the room/channel can support MIX or not. The standard method for achieving this is to use Service Discovery to find the supported features of the jid, ie, disco#info. Your proposal is that standard disco#info does not work with MIX channels, and instead the client would need to do one of: a) Query the domain of the jid, and then query the channel with node='mix' if MIX is supported by the domain. b) Query the channel speculatively with node='mix' alongside the standard mechanism. Neither seems very efficient. Now, if you're correct in your implicit assertion that XEP-0030 is fundamentally broken, and MUC-only clients would be hideously confused by the presence of both MIX and MUC data in the same disco#info response, then how are the same clients going to cope with the MIX data in the domain-level response? Dave. _______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: [email protected] _______________________________________________
