## Decentralized messaging network that anyone can broadcast/subscribe messages anonymously.
## Anonymous decentralized messaging network
Anonymity is achieved by implementing Dandelion protocol on top of libp2p's pub/sub module, dandelion is a privacy preserving protocol to make message sender anonymous, it has 2 phases, the first phase is stem phase, where messages go through a psuedo-random path, the second phase is fluffing, when the message reaches the last node(randomly chosen), the message is diffused to its surrounding peers, so the third party observer cannot track back the node original node who send the message, because the message is relayed through an anonymous graph.
Message broadcasting is implemented by libp2p floodsub.
Blockchain has enabled decentralized value transfer. A bigger future is decentralized communication. One step forward is anonymous decentralized communication which provides a censorship resistence privacy preserved communication network that anyone can send/receive, broadcast messages anonymously without revealing message metadata(sender, receiver, who send to whom, etc). It will find broad use cases, e.g., whistleblowing, anonymous public channel, incident reporting, privacy served messaging in Dapps etc.
Anonymity is achieved by implementing Dandelion protocol on top of libp2p's pub/sub module, dandelion is a privacy preserving protocol to make message sender anonymous, it has 2 phases, the first phase is stem phase, where messages go through a psuedo-random path, the second phase is fluffing, at a random time of the stem phase, the message is diffused to its surrounding peers, so the third party observer cannot track back the node original node who send the message, because the message is relayed through an anonymous graph. Message broadcasting is implemented by libp2p floodsub.
**Dandelion implementation on libp2p-pubsub**: https://github.com/rairyx/go-libp2p-pubsub/tree/dandelion
## Demo
**Directory**: `pubsub`
**What it demonstrates**: Two Go peers, one JS peer, and one Rust peer are all created and run a chat server using a shared PubSub topic. Typing text in any peer sends it to all the other peers.
**What it demonstrates**: Three Go peers, one JS peer are all created and run a chat server using a shared PubSub topic. Typing text in any peer sends it to all the other peers.
**Quick test**: `cd pubsub` and then run `./test/test.sh`. Requires Terminator (eg, `sudo apt-get install terminator`). The rest of this section describes how to test manually.
(**TODO**: maybe eliminate centralized bootstrapper; any peer could then bootstrap from any other peer and peers could start in any order; downside is the code will be more complex in all peers)
The bootstrapper creates a new libp2p node, subscribes to the shared topic string, spawns a go routine to emit any publishes to that topic, and then waits forever.
(Note that the node ID of `pubsub-interop` is going to be `Qm...6aJ9oRuEzWa`. Node IDs in libp2p are just public keys, and the public key `Qm...6aJ9oRuEzWa` is derived from the private key file `../util/private_key.bin.bootstrapper.Wa`. That file is just an X.509 keypair generated by the included program `util/private-key-gen`). We use fixed public/private keypairs for each node in this example to keep things simple.)
(Note that the node ID of `raven` is going to be `Qm...6aJ9oRuEzWa`. Node IDs in libp2p are just public keys, and the public key `Qm...6aJ9oRuEzWa` is derived from the private key file `../util/private_key.bin.bootstrapper.Wa`. That file is just an X.509 keypair generated by the included program `util/private-key-gen`). We use fixed public/private keypairs for each node in this example to keep things simple.)
**Second terminal**: Create a go peer to connect to bootstrapper and publish on the topic
```
cd pubsub
./pubsub-interop ../util/private_key.bin.peer.Sk
./raven ../util/private_key.bin.peer.Sk
```
This peer, which is not in bootstrapper mode, creates a node, subscribes to the shared topic string, spawns the same go routine, and then loops forever requesting user input and publishing each line to the topic.
**Third terminal**: Create a JS peer to connect to bootstrap and publish on topic
**Third terminal**: Create another go peer to connect to bootstrapper and publish on the topic
```
cd pubsub
./raven ../util/private_key.bin.peer.W6 6001
```
**Fourth terminal**: Create a JS peer to connect to bootstrap and publish on topic
```
cd pubsub/js
@ -49,14 +59,6 @@ This JS peer will accept lines of text typed on stdin, and publish them on the P
(Note that the JS peer generates a new identity (public/private keypair) each time, and prints its public key to stdout. This is a deficiency in the demo; to be consistent with the Go code it should accept a private key on the CLI.)
**Fourth terminal**: Creates a Rust peer to connect to the bootstrap node and then subscribe and publish on the topic:
```
cd pubsub/rust
cargo run
```
The Rust peer starts up, listens on port 6002, and then dials the boostrap peer. (TODO: rust-libp2p#471) It is now subscribed to the same topic as the other peers.
If you return to the second, third or fourth terminals and type a message, the bootstrapper and the other 2 peers will all print your message.
Rai Yang
5 years ago
committed by