Add contact blocking

[TheLastProject]

Today, I have been forced to remove a contact I can otherwise get along with fairly reasonably, just because I needed them to shut up for a moment. A block feature would prevent me from being forced to take such extreme measures in cases like these, and is an universally understood concept in Instant Messaging.

[alexbakker]

Isn't this something clients should handle?

[TheLastProject]

This is basic IM functionality that should be done exactly the same through different clients, so I don't think so. The point of blocking is also to no longer connect with someone, so that they can't send you messages and see you as offline, which is basically the same as removing a friend and sending a friend request for confirmation.

Having a basic idea of Tox, but no in-depth knowledge, this would be best implemented in the core like this:

• Friend gets an additional is_blocked int, being either 1 or 0, which clients can easily check
• Clients can call block_friend(id), which removes the friend, yet keeps the ID in the list
• Clients can call unblock_friend(id) to send another request without confirmation

Basically, adding friend blocking in the core should be simpler to implement than in clients, and also ensure that blocked contacts are properly shared between clients.

I do see one issue, which is the fact that you can't be sure that your friend hasn't changed the nospam value, which is why I feel toxcore should be notified of the current nospam of friends as they login or change it.

EDIT: Blocking could probably also be useful to stop specific users from spamming you with friend requests.

[DanTheBritish]

Could you not remove them from your contacts, then change your nospam so they can't send you more requests? Isn't that the point of the nospam value?

[TheLastProject]

@LapFox Fine, then my EDIT is less necessary. Still, the actual point of the issue seems very much valid, and changing the nospam does nothing to temporary block contacts who you just want to not talk to for a bit, but want to talk to again later.

[DanTheBritish]

Ah, I see what you mean now.

Potentially, this could be done with a core function, but it can equally be done on the client. Ultimately, I see them both working in the same way.

User A is having a tantrum and is spamming User B. User B blocks this contact. In the backend, the ID of the blocked user is saved to a list, whereby any requests are automatically denied, and User B is not notified. At any time, User B can go into their list of blocked ID's and unblock them, allowing new requests to be seen.

I think this should be implemented in the core, with a basic add_to_block_list(userID) function, since it saves multiple clients having to implement this same feature separately, all they would have to do is add UI for blocking the user, and to get the list of blocked users with a get_block_list() function. Of course, there would be an equal remove_from_block_list(userID) function.

(Sorry for shoddy pseudo code, normally a Python developer but been working in Java for the last 4 hours, minds a bit muddled)

[aaannndddyyy]

this needs to be done in core, because you don't want tohe contatc to see that you blocked him. So he would not see that you are online at all. This feature is also known from yahoo messenger where it is possible to selectively be shown as offline to certain users

[zetok]

this needs to be done in core, because you don't want tohe contatc to see that you blocked him. So he would not see that you are online at all.

lol

@aaannndddyyy it seems that you don't know how blocking in Toxic works.

[aaannndddyyy]

@zetok indeed I have not tried Toxic yet. So you say in Toxic I can block and unblock a peer without the peer ever noticing it and receiving all the queued-up messages that I couldn't receive when I was blocking him, after I unblock him again and he comes online again?

[zetok]

@aaannndddyyy When you block peer, you basically remove public key from contact list, which results in you appearing as offline to that "friend".

Upon unblocking you just add peer to your contact list again, which results in peer being able to send messages to you again.

If particular friend uses client that supports faux offline messaging (µTox doesn't support it), peer upon you coming online will send stacked messages to you.

[aaannndddyyy]

yes, that's pretty much the behaviour I'd like to see. Thing is, if I want to move from one client to another, I want to have the same contacts still. I don't know if this should then be a core function or a STS thing, but a blocked contact should still be on the user list in the client you migrated to, e.g. grayed out. Upon right clik->unblock or /unblock $nick it's there as a normal (unblocked) contact.

[Spencer-H]

I think blocking should be implemented in the core, that way it will be constant throughout the entirety of tox. However I don't think that blocking a user should be invisible to them, as there's no point in wasting someone's bandwidth, or especially data on a mobile device, pinging a client who has blocked them.

[TheNain38]

@Spencer-H It is important for privacy to not show to someone that you blocked him or else it should be optionnal, but I also think it should be implemented in core so that .tox profile could contain blocked contacts and it would make blocked contacts portable between clients.

[Spencer-H]

That may be true from a privacy sense. But the least the system could do is find a way to stop the client attempting to connect with each other. Otherwise you're throwing data to the wind. Which is a problem Tox has anyway considering how much data it eats.

On Wednesday, October 14, 2015, TheNain38 notifications@github.com wrote:

@Spencer-H https://github.com/Spencer-H It is important for privacy to not show to someone that you blocked him or else it should be optionnal, but I also think it should be implemented in core so that .tox profile could contain blocked contacts and it would make blocked contacts portable between clients.

— Reply to this email directly or view it on GitHub https://github.com/irungentoo/toxcore/issues/1125#issuecomment-148062044 .