On 6/25/15 8:39 AM, Kevin Smith wrote:
On 25 Jun 2015, at 15:28, Peter Saint-Andre - &yet <[email protected]>
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.
True.
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
--
Peter Saint-Andre
https://andyet.com/
