[Standards] [Members] 33C3 talk on Signal and current XMPP issue in providing a similar UX

Dave Cridland dave at cridland.net
Tue Jan 3 09:40:43 UTC 2017


On 2 January 2017 at 14:59, Sam Whited <sam at samwhited.com> wrote:
> On Mon, Jan 2, 2017 at 4:12 AM, Evgeny Khramtsov <xramtsov at gmail.com> wrote:
>> The problem is that spam/ham classification problem for SPIM is a bit
>> different from those for email because IM messages are short.
>
> That's fair; makes sense.
>

Although one really need not use Bayesian classifiers (etc) merely
with words; any indicators can be used as grist for the classifier's
mill - such as subscription state, if there has been an outgoing
message to the sender before, if the sender and recipient are within
the same MUC anywhere, what unicode blocks are in use in the message,
and so on.

I agree there's disadvantages in SPIM versus SPAM, but there are also
advantages in as much as the server knows a huge amount more about the
overall states of the recipient jid than an email server can possibly
know about its mailboxes.

>> Another problem, and I'm constantly repeating here, is that when you
>> detect a spam message on the server, what would you do with it? Block
>> silently? I'm not aware of any email server which acts that badly, e.g.
>> by simply throwing away a "suspicious" message.
>
> Probably just mark it as spam somehow (wasn't there an XEP for that?)
> and let the clients sort it out (eg. they can have a "junk mail"
> folder if they want). From a protocol perspective this seems like the
> easiest way to do it and ensure that each client can do the UX they
> want.
>

OK, for a concrete suggestion:

Suspected SPIM gets sent into a multi-item, well-known, PEP node.
Clients MAY subscribe to this, or MAY periodically poll this.

Dave.


More information about the Standards mailing list