XSF Discussion - 2019-03-22

Phew. Council duties completed. Only delayed by a week and some.

is there known clients that are implementing https://xmpp.org/extensions/xep-0367.html ?

HipChat, and a bot I wrote

*HipChat (RIP)

oh really ?

I'm planning to implement it in Movim

Great! :)

I discussed XEP-0367 with Dele Olajide the other day

as a suggestion for Pade

Yes, I really would like to see it more widely implemented

Some work was started for Dino, but afaik that's about it so far

Reactions?

Message attaching

Which I think it possibly not the best name, to be honest

So what's the deal with attaching vs references?

Right, I was going to ask

Exactly

Was this something discussed at the summit?

Not this specific subject iirc, or at least not this year, but we've had this discussion before on xsf@ at least

References is still full of TODOs and has various open issues regarding how to count characters, etc.

>Guus: I discussed XEP-0367 with Dele Olajide the other day Yes Indeed. That was for emoji reactions

That XEP needs some work though, I wonder if it should be splitted, one for reactions and one for attachments. Problem is, you cannot decide what should go first if multiple things are attached (like reactions and images and whatnot)

XEP-0377: Spam Reporting https://xmpp.org/extensions/xep-0377.html Is there still interest in this or something like it?

IIRC someone thought it should be detached from xep-191

yes i think its better

otherwise you remove any chance this gets send without a blocking action

which will then lead to some hacks like send blocking iq without item or stuff like that

but interest must come from server operators i guess

i think this is useful and most applications have a spam button

What comes first, XEP or server? Or client?

Why would you want to report spam and *not* block the sending JID?

honeypot?

What about it?

depending on the honeypot use-case, one might want not to actually populate a blocklist to further observe the spambots behaviour before termination

MattJ, i dont know, but why do you want to rob us of the possibility to do so ?

save all the roundtrips.

also atomic operations are nice

spamreporting is not a operation that happens so often that we would have to consider efficiency

i would argue

(I agree with you)

either way, this should come in that or another form

I don't really understand why people want to reject the simple solution here

Whats not simple about the other solution?

and nobody rejects it

Sending two iqs?

we all love the simple (2 IQ) solution

no sending one iq to report spam

and then not blocking the JID

?

Code is probably going to be pretty simple either way

The server is likely going to block it anyway

So whatever, go ahead, I won't object :)

hm, having it in one operation has the advantage that there’s something to lose for the user for reporting false spam

jonas’, yes, that came up before. Didn't mention it now because it's easy to argue against - just send a second iq to unblock

sure

But I consider it a nicer UI to report+block at the same time

Other systems don't have two separate buttons

what if some server wants to tell another server that he blocked a server or jid?

lovetox, that is not what this protocol is for

Does it really matter that much on the wire?

lovetox, and if you want this protocol to do those kinds of things, there are many many previous XEPs that do this

and they got nowhere, because they are too complex and impractical in reality

MattJ but making it not dependend on blocking makes it able to easily reuse for use cases we didnt think about

but ok i see there are pro and cons

There are various components to consider with battling spam

it doesnt matter let this get advanced

One of these components is the ability for users to report spam that has slipped through the net

It is unrelated to the other components, it's a feedback mechanism

i understand that if executed by the user this will be 99.99% with a blocking

If you see it as block(jid, [reason]) then the current thing seems fine

my argument was, its not reusable in other circumstances we didnt think of

lovetox, that kind of argument leads to generic complex XEPs, of which we have many

but yeah we can always add another XEP for that

and nobody knows how to use them sensibly

Because they support using them in so many different ways

I'm currently fighting to tie up all those loose ends and document them, I don't want to introduce more

store hints come to mind

was this XEP ever put to last call or vote?

https://xmpp.org/extensions/xep-0287.html

https://xmpp.org/extensions/xep-0161.html

Hmm, what's the other one

hm ok abuse report seems exactly what i asked about

ip is a bit lol

but ok

lovetox, but someone might need it!

lovetox, for example service operators who want to report bots registering on their server

we really have a problem with people adding XEPs but than dont follow through

> Kev: yes, XEP-268 (instant reporting), XEP-236 (Abuse), XEP-287 (SPIM markers and reports), XEP-377 (SPAM reporting).

https://wiki.xmpp.org/web/Minutes_of_the_2018_Summit:_Day_two#3._SPAM

lovetox, because "following through" typically requires multiple interoperable implementations

which a single XEP author can't do, and even if everyone in the individual projects agrees it's a good thing to do, there are other priorities...

for draft status you dont need implementations or?

No, but I'm assuming by "follow through" you include implementing

hm no i meant the author adjusts the xep after feedback

Oh right, sure

it seems people maybe think experimental xeps are not changed, so they add new ones

because i dont see why the first abuse report XEP 161 could not add the example to use it with blocking

What XEPs are there, what's the good and bad of each? Write down there.

https://xmpp.org/extensions/xep-0268.html

Ah, that's the one I was looking for

It perfectly fits "easy to reuse for use cases we didn't think about" :)

It doesn't fit "easy to use"

I think 377 is more in the spirit of simple clients, complex servers

IODEF might be fine to generate from the server and send wherever

Yes, agreed

I know that I sound like a broken record, but in the current situation, if a user needs to report spam, it essentially means the admin is a lazy bastards who doesn't do due diligence

Yes

Ge0rG, so you filter 100% of spam?

and I know you don't, so follow-up question: wouldn't you like feedback to know about stuff that slipped through your net?

This mostly being taken care of by server-side black box magic does reduce the apparent need of these reporting mechanisms

the deployment of a reporting mechanism prior to a black box magic filter won't do anybody any good.

The black box magic filter needs data

Black box 22

I'm in the position to make use of such a reporting, because I'm filtering out 99% of spam, so I'll only receive maybe 0.1% of reports. Other server admins don't have a black box, so they are going to receive 10% of their server's spam. Based on the typical 10% engagement rate.

Sure

We need to teach everybody to walk before giving them wings.

But I'd argue that it is better to have the mechanism in the server and clients, even if it isn't connected to anything more than "block this JID"

MattJ: no. It's actually worse.

Waiting until we perfect magic boxes until we deploy this is the wrong approach

MattJ: blocking an individual JID won't have any impact on the amount of spam received by a user. But the ineffectivity of the spam report button will teach them not to use it.

I'm not sure I agree with that

(that they won't use it)

MattJ: if you find out that something doesn't work, will you keep using it?

If it's as easy to click "close tab" as it is to click "report and close tab"

They won't find out, that's the beauty

It's never as easy.

I receive spam in my inbox, I still report it

They report and block, half an hour later they receive the same spam from a different JID.

The Algoritm thanks you for the input.

Ge0rG, I'm not denying that will happen

MattJ: you also assume that your report isn't merely silently logged into prosody.log without any further action

Do I?

I think you're over-thinking things on behalf of users

If they continue to receive spam they'll likely just stop using the service, client, protocol

regardless of whether there was a report button or not

So the absence of a report button is really not a fix for anything

(I have actually lost contacts who stopped using XMPP entirely when they received daily spam)

Ah, it's too late already.

WE'RE DOOMED

You can do whatever you want, and you can deploy whatever you want, wherever you want. Feel free to focus your efforts on re-solving the 99% of spam problem.

I know many people who just continue using IRC/Freenode even with the spamwaves when server operators are almost useless.. I don't think a button would help much during these tbh

freenode is kind of a specific population

(and even then, spam is much easier to deal with in a single IRC network)