There are two different problems. The first problem is preventing people from learning who (IP) has seen what. The second problem is preventing unwanted people from learning who (pseudonym) has seen what. PIR protects from the first problem, it allows an IP address to download messages for a pseudonym without anybody being able to determine which pseudonyms messages they are downloading. Problem two is more a concern from a network analysis perspective. But in many cases we do want many people to know which pseudonym has seen what, so they know who to respond to. I can give an example with Pynchon Gate. Pynchon Gate is designed for person to person communications, not for group communications (unfortunately, because it is comparatively easy to implemented, in that I could be done with it in like a month given what we already have done). Pynchon gate makes use of the following components: Mix Network -> To send forward messages Nymserver -> To receive messages for users, it processes messages sent to a user and bunches them together into buckets for the PIR server PIR Server -> To store messages for distribution, to let users download message buckets anonymously Alice wants to talk to Bob. So she makes him a message and sends it through the mix network to the Nymserver, addressed for Bob. The Nymserver gathers many messages for Bob over a period of time called a cycle. At the end of each cycle, the Nymserver groups together all messages for Bob into what is called a bucket, then it pads the bucket to a fixed size , uploads it to the PIR servers. The PIR servers put Bob's bucket in a certain numbered position in their database (PIR is usually indexed by number, if it is indexed by keyword then it is something else based on PIR, usually. The only exception I can think of is everybody gets everything PIR), and then they release a list of every pseudonym and its current bucket number, which everybody downloads with Everybody Gets Everything PIR (username to bucket position is downloaded with everybody gets everything PIR, actual message buckets are downloaded with a more sophisticated PIR). Every cycle every client downloads the entire list of pseudonym:bucket_number pairings. Then they find their current buckets index number and perform the more sophisticated PIR protocol with the PIR servers to download their messages. Because of the PIR, the PIR servers cannot tell which IP is linked to Bob, because even though Bob gets the message bucket at the position known to be 'Bob's messages' , the PIR servers cannot tell this. Anyway this is fine and great for person to person communications. The Nymserver cannot link Alice to Bob, or anybody else to Bob, because they don't need to say who they are when they send messages to Bob. But if you try to turn this into a group communication system, a lot of problems come up. Let's say that Alice wants to send a message to Bob and Carol. Okay, there are two options here now. Either Alice can send a copy of the message to Bob, and then re-encrypt it and send a brand new copy to Carol, or Alice can send a single message to a node that sends a copy to Bob and Carol. In the first case, it is simply bandwidth prohibitive. If Alice communicates with 100 people, we cannot have her sending 100 copies of the same message. That drains bandwidth from the mix network in such a huge way that it is not feasible. The second option greatly reduces the bandwidth requirements. In this case, Alice sends the same message to her 100 contacts down the same circuit, and only the key to decrypt the message is encrypted uniquely to each of her contacts. Alice would need to include for the final mix node each of the contacts to send the message to, and at the final mix node the message can be split off to the different nymservers (and where many people share a single nymserver, only one message needs to be sent to it with the list of recipients). This brings the bandwidth requirements into the realm of reasonable, Alice doesn't send 100 messages individually through the mix network, for each one to individually be sent to a nymserver. Now she sends a single message down the mix network and then it is sent one time to each nymserver from the final mix. So this is much better, but there is still a huge problem! The nymservers can see that the same ciphertext has arrived for multiple people, and now they can socially link those people together. This is a social network analysis problem. Since PIR is being used, the PIR servers still cannot link an IP address to a pseudonym, but pseudonyms communicating can be linked together by a third party (the nymserver, the final mix). Using Keyword Search instead of a nymserver can eliminate all of these problems. Now instead of sending a message to Bobs' nymserver and telling the nymserver the message is for Bob, Alice merely sends a message tagged with a shared secret between her and Bob directly to the PIR-like server. The PIR-like server no longer associates this message with "A message for Bob", but rather can only tell that it is some message for somebody. So now Bob can download the message by doing a keyword search. And this actually scales to group communications. Because when Alice sends the same message for all 100 of her contacts, yes there is a single ciphertext still but it is indexed by 100 different arbitrary strings. It is not a message for Bob and Carol and Doug etc, it is a message for 100 random strings that will never be used in the future and have never been used in the past. So this solves the problem of network analysis and actually allows us to totally remove the nymserver. But of course if Alice sends a message to Bob and Carol, she wants Bob to know to tell Carol about any replies he makes to it. Otherwise there is not group communication taking place. So the problem is third party network analysis, communicating parties should be able to determine who all is involved in the communication. So yeah there are a few closely related things here but they are distinct. Internet network analysis and social network analysis. PIR takes care of the first problem, but not the second problem. I think we can use Keyword Indexed PIR-like-systems to take care of the second problem. But in some cases it is not even a problem, because we need communicating parties to know that they are communicating with each other, we just don't want unwanted third parties to know this. If we allowed for unwanted third parties to know who is communicating with who from a *social network* perspective, and only not from a *computer network* perspective, we could just use a modified Pynchon Gate and be done with this a hell of a lot faster .