<div dir="ltr"><p dir="ltr"><br>
On 26 Jun 2015 07:24, "Steve Kille" <<a href="mailto:steve.kille@isode.com" target="_blank">steve.kille@isode.com</a>> wrote:<br>
><br>
> ><br>
> > I would like us to Get This Right, though. People have been mumbling about replacing MUC for years, and I’ve always been resistant;<br>
> > the discussions at the summit this year persuaded me that we finally have requirements that MUC1 can’t easily meet, but I really do<br>
> > not want us to do MUC2 now and MUC3 in 2017 to fix the stuff we got wrong in MUC2.<br>
><br>
> [Steve Kille]<br>
> Kev -  I strongly agree with this goal.<br>
></p><p>I think a key criterion for success will be if MUC2 can meet all commonly deployed use-cases across both XEP-0045 and other multiparty chat (including non-XMPP cases).</p><p dir="ltr">
> It seems to me that the default semi-anonymous MUC1 is generally seen as "the way MUC works" and is not a conscious option selection choice.<br>
></p>
<p dir="ltr">It's tempting to go that way, but it's very close to saying "I disagree with the outcome, so the evidence must be wrong."</p><p>The problem is that the only evidence we have as to how desirable this feature is is the number of chatrooms commonly using it. That *could* easily be that it's the default in many servers, but that in turn raises the question of why that's so.</p><p>In short, I don't claim to know, but I hesitate to ascribe all such use to ignorance on behalf of the administrators.</p><p>What I can tell you is that when I asked about the Prosody default (it's semi-anonymous), the response was that "we try to make the defaults privacy friendly"; this implies that the default, at least, was a conscious choice.</p><p>I've a feeling that M-Link defaults the same way for the same reason - maybe that's changed (and if not, maybe it should).</p>
<p dir="ltr">> I've not seen use where this behaviour seems particularly desirable.   I have seen significant customer concern about controlling mis-leading use of nicks and people misrepresenting themselves in MUCs.     I suspect that non-anonymous would be better behaviour for many MUC users, but there has not been active consideration to use it.<br>
></p><p>So what you're saying is that in all the chatrooms I'm usually in, only the Openfire project leads have considered how to configure their chatroom? I'd note for the record that I'm usually present in both Prosody chatrooms and XSF chatrooms (xsf@ and jdev@), all of which are semi-anonymous. It seems odd to me that anonymity is such a problem if the administrators there are content to leave it in place - they're hardly unaware of "the way MUC works". After all, many of those administrators are on this thread.</p><p>I think within government, military, and enterprise, strong identity is an absolute requirement, but I'd note that "misleading use of nicks and people misrepresenting themselves in MUCs" is soluble already by nickname enforcement and registration, as part of XEP-0045. So if your customers are concerned about that, you should show them that, as well as (of course) the non-anonymous configuration.</p><p>Finally, I'd note that under the semi-anonymous model, both the chatroom itself and any administrators are fully aware of the real jid of the occupant, and can act directly upon it - so the scope for abuse is limited entirely to what the chatroom allows. (Unless the abuse is also possible by non-anonymous users).</p><p dir="ltr">
> MUC2 will allow MUCs to allow users to read MUCs without sharing presence.   This seems a highly desirable option (lots of reasons).   This option will allow people to read MUCs anonymously, which I think for some MUCs can be a sensible and desirable privacy option.<br>
></p><p>I don't think that the absence of presence means (or should mean) that subscriptions are anonymous or invisible. Part of basic privacy would be being aware of people reading your messages, even those messages to a group.</p><p>The only way to read such messages would be if the archive was available to unsubscribed users.</p><p dir="ltr">
> I think that if you want to share your presence with the group or send a message to a group, that enforcing that you also share your jid is highly desirable.    In XMPP the jid is "who you are".   I can't see a clear use case for allowing people to post to a MUC without clearly identifying themselves.</p><p>I absolutely agree that making non-anonymous "better" is highly desirable. In a number of markets, and certainly in Isode's and Surevine's, "hiding" the real jid behind an occupant jid is problematic, and the relative obscurity of the real jid in MUC means that non-anonymous rooms are somewhat of a second-class citizen. From a technical standpoint, having the address of an occupant, and therefore the identity, selected by that occupant causes a number of issues, including security ones.</p><p>However, just because non-anonymous is useful for some markets should not preclude anonymity for others.</p><p>Dave.</p>
</div>