The paper definitely seems like something we could implement, but it comes with some significant limitations. Namely, time is divided into rounds (of a few seconds in the example product), and each client can send at most one message of a fixed size during each round.
This could be generalized to allow each client to send multiple messages per round, but ultimately the amount of traffic from each client must remain constant, or it is trivially easy to do traffic analysis. So the more messages each client can send, the more the overhead grows as well.
And we would also need a way to come to a consensus on which nodes act as the “servers” described in the paper.
This sounds like something that could be implemented on top of libp2p, but I would be reluctant to build it into the core messaging protocol, since not everyone would want to accept those tradeoffs.
Metadata privacy is a very interesting area though, and I could definitely see value in offering a “vuvuzela cloud” of nodes that provide anonymous message routing. That seems like something that could be adapted to a generic messaging interface, so we could always try to add it down the road if there’s strong support and bandwidth to implement.
@yusef, vuvuzela it’s a very interesting way to enhance privacy to P2P networks. I personally think that the building blocks for adding privacy should live in layer on top of libp2p, while using its interfaces. I’ve been working p3lib (https://github.com/hashmatter/p3lib) that defines a set of specs and building blocks for privacy preserving mechanisms to use in P2P networks, while being 100% compatible with libp2p. The idea of p3lib is to offload privacy mechanisms from the core libp2p and to create a set of a plug and play modules that although independent, are fully compatible with it. This could be one approach for your idea of having vuvuzela+libp2p.