It's well-known that direct message metadata is public on nostr since everyone can see who is messaging whom and when. One solution to this problem is for the entire event including its metadata to be encrypted and only revealed to an intermediate party responsible for forwarding messages to their intended recipients.
On receiving a kind 16 event a forwarding service should decrypt the content and then determine the kind and recipient of the inner event. If this event is kind 4 it should be re-encrypted and then forwarded along to its destination. If the inner event is kind 16, then its content must itself be decrypted (hence the content of the outer and inner events need to be encrypted with the public key of the outer event recipient), and the inner event recreated using the keys of the forwarding party. Recreating the event in this way serves to remove any association between the message and the original sender before being forwarded on to the next recipient. And by allowing for forwarding rounds to be chained together in this way we enable use cases that would add further plausible deniability as to the source of a message.
One such use case would be if ordinary clients were allowed to opt into being forwarders themselves. Then one could send a kind 16 to any one of these users, and when they forward the message along it's impossible to know if they are forwarding a message or are the source of a message themselves. This could create a large mesh network within which it would be nearly impossible to interpret who is messaging whom.
To add further anonymity, forwarding could also be configured to inject timing delays (for instance, using the difference in `created_at` timestamps between the outer and inner events), or to only forward messages once enough have been collected into a queue, thus creating a type of "message join" on nostr.
