My favorites | Sign in
Project Home Downloads Issues Source
New issue   Search
  Advanced search   Search tips   Subscriptions
Issue 13: Implement a block list
1 person starred this issue and may be notified of changes. Back to list
Status:  Accepted

Sign in to add a comment
Project Member Reported by, Apr 22, 2008
If I remove a buddy from the list immediately remove me from this buddie's
list too. There is absolutely no scenario where a buddy on one list would
make sense when it is not also on the other's list.

Therefore implement a "remove_me"-Message which will be sent in this case.
If the buddy is currently offline then the remove_me message must be stored
until the buddy comes online again. 

This cold be combined wit a block list with two levels of blocking: Level
1: delayed remove_me (buddy was offline), only send once and then remove
from the block list. Level 2: Permanent blocking: Each time the buddy
connects, a "remove_me" and a " blocked" message are sent (right over the
incoming connection) and then the connection will be closed.

May 11, 2008
Project Member #1
"remove_me" is now implemented.

changed the title of this issue.
Summary: Implement a block list
May 18, 2008
Project Member #2
(No comment was entered for this change.)
Labels: Milestone-Next
May 18, 2008
Removing a buddy should not be done automatically. It sends information to the buddy
that they have been removed. The buddy should not know they have been removed unless
they are told. It is better if the buddy just assumes I am no longer online. Also,
TorChat ID's are difficult to remember, and when playing with adding and removing
buddies, it can be a pain to remember the buddy that suddenly disappeared from my
list. TorChat should not do more than is necessary, especially if it provides
May 19, 2008
Project Member #4
It is impossible to hide the existance of a Tor-hidden-service, so there is *no* way
to make someone think i'm offline when i'm onnline. Someone always could look into
his logfile and see successful connections to this address, it is impossible to block
connections from certian buddies since all incoming connections come from localhost
(the tor proxy) and look exactly the same.

The automatic removing from the list is just for convenience, if i have removed
someone from my list, there is no reason, why i should stay on the other's list any

The only improvement of the user interface i could think of would be not to
immediately remove the buddy but to mark it with a special icon, indicating the
buddie's wish to be removed from the list, everything else would be intransparent and
give unexperienced users a false feeling of a non-existant security feature. It is
better to communicate openly what you can't hide anyway.
May 19, 2008
Why not just maintain a list of blocked ID's, and then permanently indicate
unavailable status to those ID's, while not displaying the blocked ID's or any
messages sent from those ID's? That's a very simple solution that doesn't require
sending any new information, or any fancy new programming or icons.
May 19, 2008
Project Member #6
blocked contacts will disconnect immediately after they have been told that they are
blocked. Otherwise i would have no way to stop certain people from connecting and
staying connected to my client.

unavailable has another meaning.

status "unavailable" means connected but buddy is unavailable.
the new status "removed" would mean disconnected and removed or even blocked

And this would information that would be known to the client so it is natural to
display this information to the user. There is no reason why my im-client should lie
to me or hide information. The client knows that it is blocked, so it should display
it to me.
May 19, 2008
Project Member #7
this all doesn't mean that it wouldn't be possible to set a per-buddy-status, so that
i can set a certain buddy to always see me as unavailable. This will likely come in a
future version, along with custom status messages, global and per-buddy.
May 19, 2008
That sounds like the ideal solution. I don't think it matters if they can actually
connect or not, I just don't want to see their messages, and I don't want them to
know I can't see their messages. A "permanent ignore list" is probably even better
than a "block" list, in this case. 

You see, if a person realizes they're blocked, they can just come up with a new
identity and trick me into communicating with them. Spammers will do this for sure.
But, if the spammer doesn't know that I have figured out he's a spammer and "blocked"
him (perm ignore), then he will not realize his spam is failing, and he will not try
a new method.
May 20, 2008
Project Member #9
I don't think that spam will become a big problem, at least not the sort of
widespread spam we have with mail and other im-services. It is very expensive (if not
impossible) to guess (and try) valid torchat-ids.
May 20, 2008
spam, harrassment, annoyance, etc. Permanent ignore works for all problems, and is
simpler to implement and modify from a programming perspective because no changes to
the protocol are necessary. Future versions will still be compatible with older
versions. It's a much better approach in every way.
May 25, 2008
Project Member #11
I am moving this from "next" to "1.0" because it will be more work than i initially
thought and i want to make a new release soon.
Labels: -Milestone-Next Milestone-Release1.0
Sign in to add a comment

Powered by Google Project Hosting