If two users pick the same nick then chat flows to
both of them. While this is an interesting "feature",
users are complaining. Perhaps we should switch this
for the client ID.
* You can now send chat to either clientid or public key
hash or username. This is a commandline only fearure from
the chat window. Don't bog me making this gui.
You can also use /whois [pubkeyhash] for example.
Perhaps I overlooked something in the chat message handling.
It's possible that before sending a chat packet it resolves
the hash to the nick and continues using the nick at the
protocol level, but if that isn't the case, and the protocol
will actually support hashes then it might be a small change
to fix this problem. I also came up with an idea to support
hashes in a backwards compatible way, which is to stick the
hash in the nick field of the packet and new clients would
check that field against their hash first and failing that
check it against the nick. Some GUI enhancements will be
needed to make this useful though.
I'm moving this back up to priority 5 because I think it
might be able to be fixed for 1.5 final.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
the original waste was made like this. so you could have a
work and home connection, share files/chat on both. remember
waste was made for secure trusted people. if you cant trust
the people on your network, you shouldnt be connected to it.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Logged In: YES
user_id=573676
Looks like this can't be fixed without a protocol breakage.
It's slotted for waste 2.0, then
Logged In: YES
user_id=573676
Found this in the 1.5b2 changelog:
* You can now send chat to either clientid or public key
hash or username. This is a commandline only fearure from
the chat window. Don't bog me making this gui.
You can also use /whois [pubkeyhash] for example.
Perhaps I overlooked something in the chat message handling.
It's possible that before sending a chat packet it resolves
the hash to the nick and continues using the nick at the
protocol level, but if that isn't the case, and the protocol
will actually support hashes then it might be a small change
to fix this problem. I also came up with an idea to support
hashes in a backwards compatible way, which is to stick the
hash in the nick field of the packet and new clients would
check that field against their hash first and failing that
check it against the nick. Some GUI enhancements will be
needed to make this useful though.
I'm moving this back up to priority 5 because I think it
might be able to be fixed for 1.5 final.
Logged In: NO
the original waste was made like this. so you could have a
work and home connection, share files/chat on both. remember
waste was made for secure trusted people. if you cant trust
the people on your network, you shouldnt be connected to it.
Logged In: YES
user_id=579253
ya , i've been saying this since v1