I would like to object to removing user-controlled visibility. Of the two visibility controls, I would infinitely prefer to remove the channel-level control, in fact - the notion that the visibility of your jid should be under the control of a third party just seems fundamentally wrong - but I'm happy with it present as long as user-controlled visibility remains.
We already have a working implementation here, both in client and server, so arguing that it is difficult to implement is rather counterproductive. I agree that it doesn't quite work in the current spec as written, but the changes are simple: * jidmap items are visible only to those with access to see them - hence administrators see all of them whereas ordinary users will only see items where the jid is visible to them. * jidmap items need to include visibility information - so that administrators can know if they're seeing privileged information. This is fine-grained access control over pubsub items, and I appreciate the complexity involved - but again I'd reiterate that we have already implemented this in Openfire, and it's working out fine, so it's clearly not impossible. So why do we need this? In our case, we are building a collaboration system for discussion of sensitive "Cyber" information. Much of this information is discussed openly, with participants keen to demonstrate and take ownership of their personal expertise - and this is important to avoid information asymmetry - but some participants have drivers to make them participate in particular discussions anonymously. These might be due to legal requirements, or simply that a participant is concerned with the impact a disclosure - or overly-simple question - might have on their personal or organisation's reputation. I cannot stress highly enough how important anonymity is to our existing product. Using other forms of anonymity has problems - the "host" of the discussion (ie, the MIX service operator) - benefits from being able to penetrate the anonymity to mitigate risks of abuse, and gain understanding of the systems usage. In addition, a key issue is to allow all participants to identify clearly that two posts originate from the same user. I would expect other use-cases (health, for example) to have similar concerns. In fact, if you look at the discussion systems in existence where any kind of anonymity is supported, making anonymity a user-controlled option is by far the normal mechanism. It's possible that this mode of operation - where participants in a discussion are mixed between anonymous participants and identifiable ones - is more common in asynchronous discussion rather than the realtime, synchronous, chatrooms of MUC. But I think we would be fools to miss the opportunity to merge, at a low protocol level, these two modes of operation given the strong demonstration of utility and desire from Buddycloud, Movim, and others. On 16 March 2017 at 07:06, Steve Kille <[email protected]> wrote: > > The recent message from Dave Cridland caused me to look at the details of > making "Prefer Hidden" user preference to hide JIDs work (which it does not > in the current version). > > This needs a third type of Channel. In addition to "JID Hidden" and "JID > Visible", you need a "Some JIDs Visible" type and you also need another > channel node to remove this information. It will also add client > complexity. > > My plan to address this is to remove "Prefer Hidden" from core MIX. If > this capability is needed, it can be added as an add-on XEP. I will note > this in the MIX XEP. > > If anyone objects to this plan, please say clearly now. > > I plan to make this change quite soon, along with some other things arising > from Dave Cridland's MIX review > > > > Steve > > > > _______________________________________________ > Standards mailing list > Info: https://mail.jabber.org/mailman/listinfo/standards > Unsubscribe: [email protected] > _______________________________________________ _______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: [email protected] _______________________________________________
