Implement a block list

[GoogleCodeExporter]

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.

Original issue reported on code.google.com by prof7...@gmail.com on 22 Apr 2008 at 6:50

[GoogleCodeExporter]

"remove_me" is now implemented.

changed the title of this issue.

Original comment by prof7...@gmail.com on 11 May 2008 at 4:09

• Changed title: Implement a block list

[GoogleCodeExporter]

Original comment by prof7...@gmail.com on 18 May 2008 at 5:26

• Added labels: Milestone-Next

[GoogleCodeExporter]

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
information.

Original comment by tahc...@gmail.com on 19 May 2008 at 4:45

[GoogleCodeExporter]

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
longer.

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.

Original comment by prof7...@gmail.com on 19 May 2008 at 8:19

[GoogleCodeExporter]

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.

Original comment by tahc...@gmail.com on 19 May 2008 at 2:36

[GoogleCodeExporter]

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.

Original comment by prof7...@gmail.com on 19 May 2008 at 4:02

[GoogleCodeExporter]

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.

Original comment by prof7...@gmail.com on 19 May 2008 at 4:19

[GoogleCodeExporter]

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.

Original comment by tahc...@gmail.com on 20 May 2008 at 2:56

[GoogleCodeExporter]

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.

Original comment by prof7...@gmail.com on 20 May 2008 at 10:04

[GoogleCodeExporter]

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.

Original comment by tahc...@gmail.com on 20 May 2008 at 6:07

[GoogleCodeExporter]

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.

Original comment by prof7...@gmail.com on 25 May 2008 at 7:28

• Added labels: Milestone-Release1.0
• Removed labels: Milestone-Next