[Standards] MUC2

Peter Saint-Andre - &yet peter at andyet.net
Thu Jun 25 14:46:05 UTC 2015

On 6/25/15 8:39 AM, Kevin Smith wrote:
> On 25 Jun 2015, at 15:28, Peter Saint-Andre - &yet <peter at andyet.net>
> wrote:
>> On 6/25/15 2:27 AM, Kevin Smith wrote:
>>> Thinking a bit about the MUC2 stuff. MUC1 had
>>> Anon/semianon/nonanon.
>> s/had/has/
> I think ‘had’ was right. Anonymous rooms were removed in 0.6 by a
> certain “PSA” :) Now it has semianon and nonanon.

Ah, I thought you were talking about XEP-0045 in the past tense. ;-)

>>> Can people share their thoughts on usecases for semi-anon,
>>> please?
>> Semi-anonymous rooms are like IRC channels. Draw your own
>> conclusions for whether that's good or bad.
> I don’t think that’s true, is it? Having or not having @ in a
> particular channel doesn’t affect your ability to whois a user on IRC
> to the best of my knowledge.


>>> It’s not entirely clear to me what these are (users who want
>>> anonymity seem to already be using throw-away JIDs to achieve
>>> that, instead of relying on MUC configuration).
>> We didn't have throw-away JIDs (well, SASL anonymous JIDs anyway)
>> in the old days.
> I didn't mean SASL ANONYMOUS when I said throw-away JIDs, I meant
> that people are registering single-purpose JIDs.
> There was a brief discussion in xsf@ earlier that if people wanted
> anonymity they’d be better served by someone writing an anonymising
> proxy. The only use case we came up with so far that wasn’t better
> served with throw-away/singleuse JIDs (at first glance; I’m happy to
> admit I’m missing things here) was a company-internal one where an
> anonymising proxy would probably be appropriate.

Something like an undernet for a company?

>>> There seems to be some significant merit in having MUCs always
>>> be non-anonymous in MUC2, to solve some of the addressing messes
>>> we’ve found ourselves in.
>> I do think that a system needing anonymity (say, a helpline) can
>> handle that using anonymous JIDs, not anonymous roomnicks.
> Great.

Violent agreement.


Peter Saint-Andre

More information about the Standards mailing list