[Standards] Summit MIX Decsions

Steve Kille steve.kille at isode.com
Wed Feb 8 15:33:12 UTC 2017


Sam,


On Wed, 08 Feb 2017 15:16:00 +0000 (GMT), Sam Whited wrote:
>On Wed, Feb 8, 2017 at 3:32 AM, Steve Kille <steve.kille at isode.com> wrote:
>>9.  It is agreed that MIX Channels will be represented in the roster.
>>
>>
>>10.  It is  intended to mark MIX clients in the roster with a server
>>generated annotation, so that MIX clients can clearly show MIX channels
>>without needing to do discos.  These clients will be marked offline, so
>>should not be unduly obtrusive to non-MIX clients.
>
>There was some discussion in the MUC recently about how roster
>requests are actually IQs and theoretically other entities besides the
>server could maintain a roster (which you could request from them by
>sending an IQ exactly like you would to the server for your main
>roster). I hadn't considered this when we were discussing it at the
>summit, but maybe it makes sense for the MIX service to maintain its
>own roster of MIX channels / proxy JIDs? The users client would
>request it from the MIX service and could show it separately or merge
>it as needed. Clients that don't support MIX obviously would not
>request this roster from the MIX server.
>
>At first glance this feels cleaner to me than having the MIX service
>modify the users main roster, but I'm sure that I haven't thought it
>all the way through and there are consequences to this approach too?
>
>—Sam

A key reason to put the channel in the roster is that when there is a client  
presence status change, it will get communicated to the MIX channel using  
standard presence mechanisms.   This buys you an awful lot of goodness for  
free.

I think that this alternative would be a good deal more complex to specify


Steve





More information about the Standards mailing list