RATINGS: Subject tags
From: hughes@ah.com (Eric Hughes)
If the disrupter is really motivated, he could have multiple identities and give positive ratings to his messages, so they would get through.
No one says you have to believe a particular rating.
This would imply that subscribers see the source of each rating. You would have to know that in order to judge whether to believe one or not. 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. My suggestion would be to just present the union of all the subject tags produced by the raters. This is a moderate amount of information, and to the extent that raters agree on subject tags it could in many cases be a very succinct presentation. We don't want to make this too unwieldy.
Unless someone else vouches for a message, it would not appear for a subscriber to the filtered list.
The system I want to experiment with for cypherpunks is not filtration at the mailing list server but rather filtration at the user's end. The "filtered list" is whatever passes through one's own filter. I am not talking about making toad into an extropians-style list with lots of server operations.
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. 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.
My suggestion is that the ratings be based on subject tags.
I suggest that one kind of rating be based on subject tags, or primary topic, or keywords, or something similar. I also suggest that other kinds of ratings exist.
Hal's suggestion is to make a rating based on salience to topic. This is fine, it allows a sheaf of related topics and concerns to be unbundled according to a particular reader's viewpoint.
This could also be used for negative ratings: subject tags such as "flame", "faq", "rant", etc. could be used to give more information than just the topic of the message. People could set up their own systems to filter the message to exclude messages with certain of these tags.
a rating message would include some message identifier
There is already the right message identifier. It appears in each piece of mail in the header field Message-Id.
Message-ID is probably OK, but it is kind of long. 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. Another advantage of numbering messages sent on the "raw" list would be that people would be able to tell when they have missed messages (but that is irrelevant to the ratings issue, I admit). Hal
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
participants (2)
-
Hal -
hughes＠ah.com