implementing positive reputation systems

[Eric Hughes <hughes@soda.berkeley.edu>]

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