fe7c7088db
Currently we use a single topic for discovery. This provides the best obscurity at the cost of bandwidth, as a message sent on the discovery topic will be received by any peer. This PR changes this behavior and start listening on a partitioned topic. Each pk will be hashed to a limited number of topics. Everytime someone is in a conversation with someone from another topic they will have to listen as well to avoid loosing obscurity, because we only forward messages that we also advertise in the bloom filter. The choice for the number of partitions depends on 2 factors: 1) The expected number of users using the network 2) The average number of contacts each user Any change to the discovery topic will need to be split across 3 releases, to avoid breaking compatibility: 1) Listen to the new and old topic, publish to the old topic 2) Listen to the new and old topic, publish to the new topic 3) Listen to the new topic, publish to the new topic This is step 1. |
||
|---|---|---|
| .. | ||
| core.cljs | ||
| partitioned_topic.cljs | ||