Dean writes: [emphasis added]
The scheme I always think of when envisioning positive reputation systems is that I get the feed of __everything I might be interested__ in, then sort and filter using whatever cleverness I desire.
Marc Ringuette's observation about the distinction between content and volume is relevant here. The existence of high-volume noise sources (and let us not call this abuse, merely an undesirable consequence of the more desirable anonymity) means that you may not be able to get everything you might be interested in. Dean suggests filtering at the server. This just pushes the same problems with volume onto the server, which does have some benefit. I too would like to see suggestions. One of the basic problems with the model for internet news and mail transport is the presumption that the receiving side will generally accept everything it is handed. Rejections of transmission are treated as exceptions and not as primary elements of the protocols. In addition, the protocols do not provide, in advance of full transmission, a way for a receiver to determine whether to receive based on message size, receiver, or signature. The two protocols I am specifically referring to are NNTP (RFC-977) and SMTP (RFC-821). (For those of you not in the know about RFC's, that's where all the internet standards are. ftp to nic.ddn.mil in directory /rfc.) SMTP says who the sender is, but doesn't tell you the length of the message or anything else about it. NNTP allows you to receive the header and the body separately, an improvement, but the header can still be arbitrarily long. Each of these protocols, at minimum, should allow the receiver to look at the length of the message before it receives to see if it will accept that message. Likewise, sending other characteristics of a message prior to transmission of the whole would be desirable. Short messages might take less time to transmit than to negotiate, so providing length seems to be the first extension. It seems that you could implement length notification and rejection by only changing some of the informational messages, meaning that changes to the basic protocol and the drastic reworkings of software required could be alleviated. Flooding attacks seem important to prevent, and I think that the underlying protocols should enable this to the extent they can. The second-most useful thing to add to the server are those functions which require examination of the entire message body. I am foremost thinking of the hash function on top of which a signature is generated. Signature checking seems like a proper function for a server as a common resource. This is a separate subject. Eric