RATINGS: an alternative request-based system?

[Seth Morris]

 I have been thinking about the proposed ratings system, and thought
long and hard about what *I* would want in ratings I receive, and
how much I would like to rate articles with ease.
 The model I arrived at was substantively different, and may reduce
overall bandwidth while allowing greater control of my own personal
mbox. 

 What I would see is a list which only sent the traffic to a subscriber
on _request_ instead of at once (perhaps more digest-oriented). I would
send a message to cypherpunks-rated at whatever.domain (which could be an
independant ratings group subscribed to receive and hold the "normal"
'punks list, and perhaps other related lists) with a command to get the 
mail I had not yet received. I would prefer that the list handle a 
database of when I last requested mail, and perhaps had a command to
just tell me how MUCH mail was waiting (in both messages and Kb).
 Then, the messges would arrive, along with any ratings. Perhaps some
services could maintain a ratings profile for me, of the signators I trusted
to rate and the topics/ratings I prefer (one especial benefit for me
would be to raise my filtering level at the transmission end on those days
when the volume had increased, as launchpad has _serious_ disk problems,
and I'm telnetted in at 2400 bps anyway).
 The messages would arrive and I could reply to cypherpunks-rated with
MY ratings/comments (whichI would like to see batched and transmitted to the
author, so comments on saliency/style/flamage would be sent only to her/him and
not clutter up anyone's mailbox) to the server to be added to the list.
 This way, new messages are always sent (although it would be easy to
change that, preferably in my profile) to be rated, and old messges 
have longer accumulated ratings.

 Actually, this runs more like a mail-based archive than a list, but the
end result is similar. Perhaps a couple of days hacking at some archive
manager (like the ones at most listserv's... does majordomo have archiving?)
could set up a running prototype.

 It seems that this meets most of the requirements: multiple ratings,
multiple ratings services, easily alterable filtering profiles, easily
extended to handle keywords (many archivers already o this, of course).

 Specifics are debatable: the source filtering seems controversial (although
I don't know why, unless people are worried about having the list manager
know their preferences, in which case they can get everything and
its ratings and handle them locally), so maybe the server shouldn't
keep persistent profiles, but should receive a request with a profile
for that specific request.

 Perhaps I send a "request on" message, and receive a message containing
information on the queue: how many new messages (in however much time,
so I know), how many Kb, how many rated messages on which common topics
(in any given two-day period, the number of topics stays pretty low), etc,
and I reply with numbers ie:

>Per: your "request on" message of 940401:1935GMT
> Last request 940401:1209GMT
>Messges: 12
>Kbytes: 65
>Remember: ar is "Average Rating" of raters accepted in your
> "request on" message: Raters id's follow:
> exclude: BIFF.DORK at BITNET.SHOUT
> exclude: ld*@lance*
> accept: master.rater at text.analysis.god.com
>
>Keyword: Remailers... 3 messages rated, 1 message unrated, ar:8.2
send all Remailers
>Keyword: Libertarian... 2 messages rated, 0 messages unrated, ar:0.6
send above 2.0
>Keyword: PGPTools... 5 messages rated, 1 message unrated, ar:5.2
send above 7.0
send below 1.0 #for chuckle factor
> Your messages comments:
> msg id: xxxxxx
>  "Excellent, it changed my life" Rating: 1.1 --SomeOne
>  "Rehash of old crap" Rating 7.6 --SomeOne Else
> msg id: yyyyyy
> <no comments>

Hmmm... a bit too wordy, but you get the idea. (Get the lucifer? Get the
skipjack? (Remember: Ounce for ounce...) )

 This would also make receiving multiple lists easier for those of us with
no filters (Where does one get pc-elm???????), as we could receive one list,
process it, and then get another list, allowing us to not get them
mixed up.

 Seth Morris (seth.morris at launchpad.unc.edu)