Also, Bob doesn't even need to rebroadcast Alice's public message for his friends to get it, he just needs to share the key for it as well as point them to it. As long as the messages in the PIR-like cache do not get wiped extremely quickly as new messages come in, this will require much less bandwidth. Since Alice's 50 KB message is already encrypted and stored/indexed by the PIR-like servers, Bob can just send to his friends the index tag that points to Alice's message, as well as the encrypted symmetric key to decrypt it. Here is the rough idea right now: Alice makes a public message for Bob. This is broken into two parts, the metadata and the actual payload. Metadata: A. An Emphemeral ECDH Key B. A shared secret contact tag C. The symmetric key that decrypts the payload D. The tag that the payload is indexed by Payload: The payload is the actual encrypted message, it is indexed by the index tag included in the metadata (so that is the keyword people search for to get it). A. Suggested title B. Private/public C. Introduce/hide D. Message, signed E. Senders contact details (if message is public or introduce is set) F. Information allowing the people who obtain the message to determine which of their other contacts have been pointed to the message First Bob engages in the keyword based PIR like system (whatever that ends up being, PSS and OWI both are options right now, EKS actually isn't as it allows the storage server to see the document returned just not the keyword searched for or the plaintext of the returned document) searching for any metadata packets that are tagged with the shared contact tag between him and any of his contacts. This allows Bob to obtain all metadata packets for all messages anybody points him to. We need to take care to protect from traffic analysis during this process, but because of the PIR-like system no third party or the server itself can tell which metadata packets Bob searched for or obtained. Next Bob uses the included ECDH ephemeral public key and his private ECDH key to derive a shared secret. He uses this shared secret to decrypt the index tag of the message he is pointed to as well as the key used to decrypt it. Next Bob engages in the PIR-like protocol again in order to obtain the payload data (now that he knows the tag it is indexed under). Again, the server cannot tell the tag of the message he searches for or the message returned, but we need to take care to protect from traffic analysis. Next Bob uses the key from the metadata packet to decrypt the message. He then checks who the message is from (he knows Alice pointed him to it, but not if she wrote it). If the message is from one of his contacts, then he verifies this by signature verification. Bob's client then uses the metadata from the message to ask him some questions. Perhaps it compares the suggested title of the message (that Alice picked) to content Bob already has in his local cache, and asks him if he would like to *perceptually* merge this post into an existing thread or keep it independent. Since the message is talking about the effect of a certain drug, and because Bob is already engaging in a coversation about this drug in another thread with twenty of his friends, the software suggests that Bob *perceptually* merges this new post with his current thread, and he does so. Now at this point if Bob replies to Alice's post in the thread, only Alice will see the message (since Alice wrote the message it in addition to pointing Bob to it). But since the message is marked public, and since Bob likes the content of the message, he decides to *socially* merge it into the thread in such a way that all participants can see it. He does this by making metadata packets for each of his twenty friends as follows: A. An Emphemeral ECDH Key B. A shared secret contact tag between Bob and one of the twenty posters in the thread C. The symmetric key that decrypts Alice's message, which is itself encrypted with the shared secret derived by Bob's ephemeral public key and his contacts private ECDH key D. The tag that Alice's message is indexed by. He also does the same thing for each of the other public posts in the thread for Alice, so she can see the previous posts as well. Now Bob's contacts engage in the PIR-like protocol and obtain the metadata packets that Bob pointed them to. At this point they download and decrypt Alice's message, but since they don't know who Alice is they cannot verify her signature. At this point they can select to whitelist Alice, which entails loading the contact information her message has included in it. This allows them to generate shared secret contact tags between them and Alice, so they can tag messages for Alice. Since Alice also is introduced to them, she also gets their contact information, which allows her to generate the shared contact strings for them as well. If they whitelist each other they now have a dynamic (per message), secret contact string that they can use to point each other to metadata that itself points to message content. Keep in mind that this is a rough protocol, but something like this is what I am picturing. We are just now starting on the PIR-like part of the system as we just finished forward anonymity and wrapping all the crypto and networking and database , etc, stuff up.