Consider the problem of one time pads. If I have two messages the same length, one made of 'good data' and the other consisting of 'bad data' and I encode them both with different one time pads, then it is possible for the resulting ciphertext version of each message to be identical. Another way of putting this is that for any given ciphertext that has been properly encoded with a one time pad, the only information available about the plaintext is the length of the message (assuming you know already that a one time pad was used) and nothing else.
So not necessarily following any of the specifications of the system in the article.
I read his specification to mean that users are anonymous, they can post data and it can not be tracked to them. I do not see this necessarily requiring the data be filtered in a encrypted state only that it can not be tracked back to a submitter who took reasonable precautions.
That it is paradoxical does not necessarily make it impossible, though. The goals are certainly contrary but I am not certain that they are contradictory.
If you think about community-based censorship, this could probably be arranged even in an anonymity community, as long as it had active-enough participation. A popular search engine like Google can have tremendous ability to censor others even on a network like Tor where people cannot easily be censored.
The chief problem is that «api» faces is that his/her aspirations are too individualistic and unimaginative. You could always put the to-be-censored material in an encrypted archive and distribute the link to the material with the password to it -- this sometimes happens with BitTorrent (and then you'd have to click on ads to get the password and it becomes a nightmare). Then nodes cannot inspect the content. So what are you going to do, limit content-types? This was done by Napster, where only MP3s would be shared -- but a piece of software quickly came out called Wrapster which "wrapped" other files in MP3s. There exist JPEG steganography tools as well, both hiding files within the least-significant bits of the image data as well as in parts of the JPEG which do not get interpreted by a normal JPEG reader (e.g. appending a RAR archive to the end of the JPEG image).
I say "too individualistic" as well because any sort of relay net where the nodes themselves inspect the content that they trade is going to expose itself to a possibility of systematic censorship. "I know that you know what you were sending me" is a horrible way to start your cryptosystem.
Nonetheless, there might be hope for a sort of global data-store which the nodes collectively take responsibility for, which nodes collectively trade and where nodes can vote to "veto" certain indexed files. The idea would be that you can't take down the data store by taking down individual nodes, you can't prove which node "uploaded" a file, and you can't necessarily fault the nodes for failing to down-vote a file tracked by the community since hosting the file is a collective decision, not an individual one. It would have to use central aspects of the design of BitCoin alongside central aspects of anonymity networks, but I don't see why it would be impossible.
Though I do not study cryptograph professionally that would be my current guess.