1994-02-22 - RATINGS: Subject tags

Header Data

From: hughes@ah.com (Eric Hughes)
To: cypherpunks@toad.com
Message Hash: ea12af9f778cc5df03796f6f1096462c689b2e6968fe68a4160f896b4c06dc17
Message ID: <9402222308.AA15623@ah.com>
Reply To: <199402222056.MAA15491@jobe.shell.portal.com>
UTC Datetime: 1994-02-22 23:10:08 UTC
Raw Date: Tue, 22 Feb 94 15:10:08 PST

Raw message

From: hughes@ah.com (Eric Hughes)
Date: Tue, 22 Feb 94 15:10:08 PST
To: cypherpunks@toad.com
Subject: RATINGS: Subject tags
In-Reply-To: <199402222056.MAA15491@jobe.shell.portal.com>
Message-ID: <9402222308.AA15623@ah.com>
MIME-Version: 1.0
Content-Type: text/plain


One of the goals of this arrangement I've proposed is that it can be
used to rate _any_ existing mailing list.  There's no reason the
ratings address has to be on the same machine as the list software.
If someone wants to set up an alternate cypherpunks rating service,
great.  If someone wanted to set up an extropians or libernet (two
lists which I know have high crossover to here) ratings service, you
could do so, without requiring the cooperation of the list
maintainers.

Now, onto Hal's comments, about which the above paragraph are a
response.

>This would imply that subscribers see the source of each rating.

Yes.  I find this desirable.  

>But I think this might consume too much bandwidth.  With possibly
>many raters, each producing a potentially multi-dimensional rating per
>message, this would be a lot of stuff to send along with each message.

The way it's set up now, there are two lists, cypherpunks and
cypherpunks-ratings.  The main list will not change basic operation
merely because there is a ratings list in place.  Subscription in the
ratings list is optional; a separate subscribe message must be sent.

I am unconcerned with the bandwidth right now.  For a mailing list, if
everybody sent ratings to everyone else, you get N^2 growth.  As it
is, very few people are going to have the software to generate or
accept ratings, so for prototyping this just doesn't matter.

As far as the long run, just as one will pay someone, somewhere for
delivery of a mailing list, one will pay for delivery of a ratings
list.  I would expect there to be an equilibrium reached where some
ratings-crunching service gets all the ratings and spits out digested
versions in succinct form.  The digested rating is just another
rating, after all.

>This makes sense, but there must still be two lists: one, the "raw" list,
>which is seen (at least) by raters and contains messages which have not
>yet been rated; and the other, the "rated" list, which has the rated
>messages.  

No, that is not how I'm doing the cypherpunks experiment.  What you
summarize above is similar to what I proposed for Usenet.  I am
proposing something different for this mailing list, something which
is workable given the constraints on configurability and resources at
toad.com.

>My suggestion was that messages which did not receive any
>ratings by anyone would not make it into the rated list.  Obviously an
>alternative would be to send it out tagged to show that no one cared
>enough to rate it.

I am not saying that a rated list shouldn't exist, merely that it
won't be sent from toad.  I'm perfectly happy with derivative
information products based on cypherpunks; anybody who wants to delay
the feed and take into account the ratings should be free to do so.

>subject tags such as
>"flame", "faq", "rant", etc. could be used to give more information than
>just the topic of the message.  

I agree, and an excellent suggestion.  Perhaps a simple syntactic
solution is to have each rating be of the form

	<keyword>/.<digits>

In other words, a key word followed by a fraction from zero to one.
The number of digits is left purposefully unspecified to allow for
finer and finer aggregate distinctions as the number of raters
increases.

This syntax appears to support all the criteria I mentioned in a
previous post.

>Message-ID is probably OK, but it is kind of long.  

So?  Look at the References: field in a typical Usenet posting that's
down in the discussion tree.  Gad.  The Message-Id is guaranteed to be
unique, and if it's longer than it might be, it's certainly easier and
more general to use that than to invent another unique identifier.

>Many mail agents will
>insert an "In-Reply-To" into the header which identifies the message ID,
>but not all will.  It would be a real pain to type one in manually.

One is just not going to be able to rate easily without software, I
anticipate.  Not everyone is going to be able to take advantage of the
ratings immediately, either.

Eric





Thread