The practical way to implement this idea today is to use TAILS OS and publish gpg --hidden-recipient messages on ethereum blobdata. The person who wants to receive your message can run a node that archives and searches all ethereum blobdata, to find your messages.
Downsides
As of today the anonymity set of such a scheme is very low, but if enough people start doing it, it could become more popular. See also: Moxie Marlinspike on why coordinating protocols is hard (This is also why I prefer using ethereum blobdata as opposed to inventing some new p2p network for it.)
gpg doesn't have forward privacy hence preserving such messages on a blockchain is not ideal, in case your key ever gets compromised. Probably you can implement signal protocol or similar but store messages on ethereum blobdata anyway (I have not studied signal protocol).
I will have to read more about how ethereum p2p gossip stuff works, to be sure this scheme works though. For instance, if all the nodes connect to the same directory node to obtain an initial set of nodes to connect to (or worse, use Infura or Alchemy or similar), this again breaks the anonymity
mostly written by 2025-06-18, minor edit 2026-07-12
Internet anonymity without Tor
Disclaimer
As of 2025, there is no empirical evidence of successful deanonymisation attack on Tor. If any govt has this capability, they're successfully keeping this info private. There is public evidence of many of the internet's fiber optic cables being tapped.
Summary
Governments can wiretap fiber optic cables and obtain metadata about which sender is connected with which receiver, along with timestamps. If Alice sends a payload at a timestamp and Bob is receiving a payload of same size at similar timestamp, most probably Bob is the receiver for Alice's message.
If senders send their pgp-encrypted messages to everyone, and the receiver retrieves the entire dump of all messages from one of these users same hours or days later, then this metadata is much harder to collect.
This setup is expensive hence it only works for <1 MB text payloads sent on >1 gbps connections.
Main
Intelligence-agency-resistant internet anonymity is hard because the physical infrastructure can be inspected by someone with a monopoly on violence.
Fiber optic cables cannot hide sender/receiver identities as the attacker can wiretap the cables and then follow the physical path to identify which cable exactly carries a given message. Then they can break into the building that the cable enters.
(also fiber optic connections usually requires KYC in most countries, but that's a legal limit not a physical one)
Radio signals cannot hide sender/receiver identities as the attacker can triangulate the signal based on signal strengths. Then they can break into the building that is transmitting the signal.
(also encrypted radio is illegal in many countries, but that's a legal limit not a physical one)
Success criteria of attacker
When considering intelligence-agency-resistant anonymity, getting the metadata alone is enough to count as an attack, even if they don't get the message content.
Metadata includes sender/receiver irl identities, sender/receiver pseudonyms, message sizes and timestamps.
If the receiver is marked as suspicious, then any sender that connects with them is also marked as suspicious.
Attack 1: Get view access into majority of exit nodes
Tor relies on the sender passing each message to three other random users before it reaches the receiver, and hoping the three intermediaries don't all collude with the attacker.
If an intelligence agency has view access into majority of exit nodes, they can deanomyise Tor completely.
This could be done by controlling exit nodes themselves or by breaking into exit nodes run by others. They can do the latter using hardware or software backdoors, using targeted cyberattacks or using spies.
Attack 2: Wiretap source and receiver machine
If the intelligence agency is tapping fiber optic cables of both source and receiver, the timestamps of packets sent will match. This means they are aware of the physical addresses of both machines, the fact that there's a connection between them and the time interval in which this connection occured.
possible solution
What if the sender just sent the message to everyone instead of sending it to their intended receiver?
Assume that some receivers may be publishing public proofs (via youtube, twitter etc) of their latest uncompromised PGP keys.
Assume that each user sends a single payload of X bytes to all users each day. This payload can include encrypted messages to specific users. If they have less than X bytes to send, they fill the remaining bytes with junk data.
Assume each user sends their X bytes at approximately the same time each day.
Only the actual receivers of the content can decrypt the message. It is junk to everyone else.
Assume 'gpg --hidden recipient' was used, so there's no way to tell which pubkey was used to encrypt a given message, from a given set of pubkeys.
Throughput
8 billion users, each user has 1 gbps unmetered fiber optic
1 gbps / 8B = 0.016 bytes/s = 1350 bytes/day
100 million users, each user has 1 gbps unmetered fiber optic
1 gbps / 100M = 105.4 KB/day
100 million users, each user has 10 gbps unmetered fiber optic
10 gbps / 100M = ~1.03 MB/day
Potential problems
Real-time messaging not possible. This is slow like courier.
Running servers from residential area requires effort. ISPs and OS developers can make this difficult. Renting a cloud server to download the messages does not work, as the cloud server owner knows which subset of these messages you downloaded to your local machine or display.
Subscribe
Enter email or phone number to subscribe. You will receive atmost one update per month.
Alternatively, you can subscribe via RSS, or a third-party service like blogtrottr