Look into verifiable shuffles, private information retrieval, and dining cryptographer networks.

By combining such techniques, it's possible to be much much better than naive broadcast, and also possible to use a client/server architecture so that low bandwidth endpoints can participate.

Have a look at systems such as Dissent and Riffle.

Thanks!

The Pynchon Gate solution boils down to private information retrieval: a number of distribution servers hold all blocks of information, and one then downloads from each server the XOR of certain blocks, such that XORing all blocks together yields the single block one is interested in.

And yes, mobile bandwidth is a killer.

One way your broadcast can be achieved is through a newsgroup. The best you can do is identify who is a member and who posts messages. But so long as the messages are encrypted, you can't tell who gets which message, since everyone in the newsgroup gets every message.

Still not perfectly metadata proof, but it carries a lot less metadata than peer-to-peer messages.

This has actually been done for decades with usenet. Every encrypted message winds up on a common list, and clients occasionally scan the list and see if they have a key to decrypt any new message. The metadata is then that you put a message there or that you asked for a list of new messages, though that can be reduced to "you used tor" which until such a message server became commonplace might be better.

In addition to all the systems and protocols mentioned by sibling posters, I'll add ricochet: https://ricochet.im/

It deals with the metadata leaks by using Tor. Every user runs a Tor hidden service, and the users identity is the address of that service. So no single point in the chain can tell who is talking to whom, without having to resort to a broadcast protocol like you describe.

A blockchain, of sorts...

Blockchains can do this. But they create relatively absurd systems of who can/can't send messages based on how much they've mined. Block chains are HORRIBLE for encrypted messaging. Since your message is PERMANENTLY part of the chain. So if a encryption is broken, or your password gets leaked. ANYONE can read your messages.

In most cases a DHT is far simpler. But naturally some nodes can be evil and log metadata. This is just a risk, but it also exists in block chains. Furthermore DHT's are lower latency then block-chains.

Blockchains aren't a magic fix all solution for network consistency/privacy models. Outside of currency transactions it is a horrible distributed system model.

This trend of proposing a blockchain to solve every problem is hilarious to me. Hammer/nail syndrome.

> Hammer/nail syndrome.

Blockchains address that problem too.

Bitcoin: the slowest, most expensive key/value store in history.

Also if you look at it in terms of the CAP Theorem:

Consistency (every read receives the most recent write or an error): Not True for block chains. All reads are dirty. The further back in time you go the higher the probability the read isn't dirty.

Availability (every request receives a response, without guarantee that it contains the most recent version of the information): 100% true.

Partition tolerance (the system continues to operate despite arbitrary partitioning due to network failures): Yes the system will continue to function. But you can suffer data loss when the partition is healed.

Sorta, but not. The only similarity would be that you download global state. But you could continously throw that state away if you don't need archiving of messages / long history.