Module BlockingCommandModule is implemented.

Please provide code examples for the following:

• Retrieve list of all blocked JIDs
• Add JID to blocked list

@andrzej.wojcik if I block a JID, on one resource will I get a notification about this new blocked JID on other connected resources?

Sorry, added previous comment to a wrong ticket. Copied it to issue #42 ticket.

For this one, I have question though. Do we have Spam reporting implemented yet?

@andrzej.wojcik I am not sure what was the last conclusion from our discussion about spam reporting/user blocking.

From what I remember we decided to have Spam Reporting only and user blocking would be implemented on the server side as part of the server side implementation for handling spam?

Yes, but we have decided to use XEP-0377 for spam reporting and that is based on using BlockingCommand and specifying a reason to block the user. What we will do with the information that user wants to block a jid due to the fact that this jid sends spam is up to us.

Yes, this is what we wanted and good thing is that we are reusing blocking command mechanism.

Ah, in such a case, this is even better.

@bmalkow does the library API support both options? I mean can I choose with the API whether to simply block the user or report a spam? Please provide code examples.

BlockingCommandModule supports Spam Reporting and Blocking Command.

It is hard to invent code example:

halcyon.getModule<BlockingCommandModule>(BlockingCommandModule.TYPE)
	.block("spammer@server.com".toBareJID(), Reason.Spam, "It is SPAMMER!!!")
	.response {
		it.onSuccess { println("Done") }
		it.onFailure { println("Oops!") }
	}.send()

You can also may listen for information about updates of blocked list:

halcyon.eventBus.register<BlockingCommandEvent>(BlockingCommandEvent.TYPE) { event ->
	when (event) {
		is BlockingCommandEvent.Blocked -> println("$event")
		is BlockingCommandEvent.Unblocked -> println("$event")
		is BlockingCommandEvent.UnblockedAll -> println("All blocked contacts are unblocked now!")
	}
}

But those events will be fired only when client previously retrieve list of blocked contacts (in other case, server do not push information):

halcyon.getModule<BlockingCommandModule>(BlockingCommandModule.TYPE).retrieveList().response {
	it.onSuccess {
		println("Blocked: $it")
	}
	it.onFailure { println("Oops!") }
}.send()

It's not hard. The above examples is exactly what we need. You can incorporate them into the Halcyon documentation.

@andrzej.wojcik just to confirm. We are implementing here XEP-0377, not the XEP-0191, right?

I can see 2 possible reasons for blocking: Spam and Abuse, (there is also third - NotSpecified in Halcyon API). Could you please describe what exactly happens on the server depending on reason used? I plan to have 2 cases in the Convene UI (at least at the beginning):

• Spam reporting - so this would be not just blocking the JID but can also affect the JID's reputation so communication from the JID could be blocked on the server level instead of just a user level.
• Blocking a user - a temporary blocking a user, something like temporary silence a user. Not sure if this is really needed but I can imagine that sometimes ppl would want to block somebody who is not really an abuser or spamer. They may just do not want to receive messages from somebody. So this should not affect any kind of blocked user reputation. It should just block communication from the JID on the user level.

@kobit We have support for XEP-0377 and XEP-0191 (XEP-0377 is addition to (extension for) XEP-0191).

I can see 2 possible reasons for blocking: Spam and Abuse, (there is also third - NotSpecified in Halcyon API). Could you please describe what exactly happens on the server depending on reason used?

XEP-0377 specifies 2 reasons for "blocking" and reporting user as a spammer or abuser. However, there is still a possibility to use just XEP-0191 by just omitting <report/> element specified in XEP-0377 - that is 3rd option in Halcyon named NotSpecified (maybe it should be called None to mark that we are blocking but not reporting this JID?)

Currently, when any reason is specified (spam or abuse) then server blocks user by adding it to PrivacyList (just as Blocking Command does - that is shared code) and then notifies SpamFilter that user was marked as a spammer with some "probability". If enough reports are received, then SpamFilter blocks user globally. Probability is configurable on installation basis.

I plan to have 2 cases in the Convene UI (at least at the beginning):

Spam reporting - so this would be not just blocking the JID but can also affect the JID's reputation so communication from the JID could be blocked on the server level instead of just a user level.

In this case just use reason Spam.

Blocking a user - a temporary blocking a user, something like temporary silence a user. Not sure if this is really needed but I can imagine that sometimes ppl would want to block somebody who is not really an abuser or spamer. They may just do not want to receive messages from somebody. So this should not affect any kind of blocked user reputation. It should just block communication from the JID on the user level.

Use reason NotSpecified.

Thanks, now everything is clear. I will close the ticket once I get it all working in Convene.

Sevan will be taking over client implementation, so we need to have it documented in one place. @bmalkow please add this to our documentation for the Kangaroo project in the Kangaroo github repo.

I meant, of course above description with code examples.

Documentation to module is here: https://github.com/tigase/halcyon/blob/master/src/docs/asciidoc/text/modules/BlockingCommandModule.asciidoc Should I also add it to Kangaroo GitHub repo? If yes, then where exactly?

I am assigning this to Sevan who now works on the client code.

@sevan.evans this might be overwhelming for you right now but you will understand this once you get deeper into the code. In any case, please do not hesitate to ask questions either to me or to Bartek.

Spam reporting added to client.

When blocking a user, the client will be prompted with whether they would like to report the offender for spam. If yes is clicked, the JID will be reported with the Report.Spam tag.