Wnode (whisper node) is a command-line diagnostic tool. It does not have a nice user interface, because its main purpose is diagnostic, and it's meant to be very light-weight rather than beautiful. Wnode might be used for different purposes, including:
- running a standalone bootstrap node, in order to set up a private whisper network
- connecting to particular node for debugging or other purposes
- engaging in command-line chat with another peer in order to test its functionality
-fileexchange: file exchange mode (send and receive files instead of text messages)
-forwarder: forwarder mode (only forward; neither send nor decrypt messages)
-mailserver: mail server mode (delivers expired messages on demand)
-mailclient: request expired messages from the mail server
-standalone: don't actively connect to any peers, wait for incoming connections instead
-test: use of predefined parameters for diagnostics, including passwords
-generatekey: generate a new private key (ECIES) and exit
#### Arguments
In case of missing arguments wnode will either use default value or ask you to provide them. For security reasons, you can not provide passwords in command-line arguments. Only in test mode hardcoded passwords are used.
-verbosity:
Verbosity level of logging. Int value between 0 and 5. Default value 1. For example: -verbosity=5.
-ttl:
Time-to-live for messages in seconds. Default value 30. For example: -ttl=20.
-maxsize:
Maximum allowed message size in bytes.
-work:
Maximum time in seconds allowed to spend on proof of work in order to achieve the target (set by 'pow' argument).
-pow:
PoW target for normal messages in float format (e.g. -pow=2.7).
-mspow:
PoW requirement for Mail Server request.
-ip:
IP address and port of this node (e.g. 127.0.0.1:30303).
-pub:
Public key of your peer (for asymmetric encryption). For example:
my public key: 0x040ef7acd60781c336c52056b3782f7eae45be2063e591ac6b78472dc27ba770010bde445ffd2f3623ad656f3859e00d11ef518df4916c4d4e258c60b15f34c682 enode://15454fc65bbf0031155f4eee83fa732f1454c314e9f78ade9cba4d4a098d29edbf5431764ee65b200169025c3f900cacc3348a000dda7a8a0d9643d0b7618712@127.0.0.1:30379
Bootstrap Whisper node started
After the bootstrap node has started, another local node can connect to it, using the resulting enode:
Now, if you restart you bootstrap node, its enode will be different, because new ID will be randomly generated. If you need to repeat the tests multiple times, it will be extremely boring to copy and paste new enode every time you restart. Instead, you can load ID from file using 'idfile' argument.
my public key: 0x04be81a00a90f5c21ead8887eaa254b3f7a37e06f8f2d776dcc46954a228bc50c6fb6dfd155f7e44e6fef9b62fdf6dad041759b864d2cbe4089b6f5c16a817ff46 enode://7d13360f5b1ddcf6947f244639113597a863abba0589d2fa5fffb2816ead0acea6211d5778a8be648e45e81ed881f4c1f5c9bbbf0e79065dfb54bcd97de3beab@127.0.0.1:30379
Filter is configured for the topic: 5a4ea131
Bootstrap Whisper node started
Now you can always use the same command to connect to your bootstrap node:
Now we will start a chat between two or more nodes sharing the same password, using symmetric encryption. One of the nodes should be started with 'standalone' flag, and another must connect to the first one. It is easy to do on the same machine or on a dedicated server. But what if two peers are behind distinct NAT? In that case, you need a third bootstrap node on a dedicated server, which both peers can connect to. At the time of writing we have out test node with the following enode:
Then you will be prompted to enter the password for symmetric encryption. From this password symmetric key will be derived. The topic will be derived from the password as well, unless you provide your own (which is strongly encouraged for any meaningful communication):
You will see your own message successfully decrypted and printed on the screen. The first number (1493061848) is UNIX time in seconds. This format is useful for Mail Client/Server tests. The number in brackets is ID with which the message is signed. In this case -- your own ID. If you see only zeros there, it means the message is not signed, although encrypted with the right key. Another wnode peer will show the same output:
First line of the output contains the key which should be passed to anther peer, and vice versa. Then you can proceed with the chat as in the previous case.
#### Sending and receiving files
Start wnode with 'fileexchange' flag, and 'test' flag for simplicity. Suppose we want to store the incoming messages in the directory /home/tester/tmp/msg. In that case:
After you will type and send messages from the second node, you will see the first one to display something like this:
1493124416 {624fdf6983940c7ffa8a4742f76dc78ae9775c47}: message received and saved as 'aa6f339e830c86718ddf4254038dd9fa8da6494e3f3c856af500a5aeaf0df62d' (4 bytes)
As you see, messages are not displayed, but saved instead. Now you can open the file /home/tester/tmp/msg/aa6f339e830c86718ddf4254038dd9fa8da6494e3f3c856af500a5aeaf0df62d and examine its contents.
If you want to send a file from the 'fileexchange' peer, just type the file name. For example:
Whisper protocol allows you to exchange messages with other peers only if you are online. But what if you go offline? Will important messages be lost forever? The golang implementation of Whisper v6 has a built-in support for Mail Client/Server functionality, which allows to create very secure (and even dark) anonymous email-like system. Wnode is designed to demonstrate the viability of such project.
Mail Server and Client must have direct connection, since they exchange special kind of messages, which are not propagated any further. The reason for that is simple: if you receive the old (expired) message from the Server, and try to send it to other peers, they will recognise the message as expired, and drop connection with you.
