[Standards] MUC Spam and MUC invites
stpeter at stpeter.im
Wed Sep 5 16:19:24 UTC 2007
Dave Cridland wrote:
> On Wed Sep 5 16:21:18 2007, Adam Nemeth wrote:
>> Most of you may probably now that conference.jabber.org's rooms had
>> spam-problems recently - https://stpeter.im/?p=2041 .
> I had to read your comments there before this message made sufficient
> sense to me. One thing I'd note is that, IMHO, the capability to offer
> free-access conferencing services is a vital plus-point for XMPP.
> Discarding that feature is a step backwards, and while I'm not saying
> that jabber.org MUST reopen its chatroom creation, I do think it's
> important that the technology allows it safely.
Agreed. We may in fact open up the chatroom creation again at
conference.jabber.org. That will probably require more people to watch
over the deployment (e.g., receive a jabber message when a new room is
created so that admins can check up on it).
> Open user registration is something else - you're effectively allowing
> someone to create a new identity there. (I don't think "CAPTCHA" is the
> way forward here either). I think that's the root cause, here.
I don't think CAPTCHAs will really solve the problem, which so far is
not botnets but poorly-behaved humans.
>> You may also know that Google does not allow MUC invites because it
>> does not come from somebody on your contact list, but from the room.
> What you're saying here is that room invitations would benefit Google
> users by coming from the actual sender, rather than relayed via the
> room. This seems sensible, because blocking lists might otherwise
> intervene as well for other users.
>> A direct invitation would probably look like as follows (modified
>> example 46 and 47 from XEP-0045):
We've discussed this before. IIRC the list thread concluded that we
would use a different element (not <invite/>) to avoid confusion. But
that's the general idea.
> This seems much more logical to me than the status-quo. You'd quite
> possibly need to tell the room you're inviting someone, though.
There were reasons for the status quo. :)
>> There's already a place for 'to' element in the xsd, it's optional now:
> Both to and from are used, and to means something different to your
> usage. I think there's a risk that there's a degree of overlap here, in
> particular, a naïve client receiving your new message would attempt to
> join the MUC room at "crone1 at shakespeare.lit/desktop", and become
> horribly confused. Perhaps a different content might be better.
See previous list thread.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 7338 bytes
Desc: S/MIME Cryptographic Signature
More information about the Standards