Gnus development mailing list
 help / color / mirror / Atom feed
From: Ted Zlatanov <tzz@lifelogs.com>
Subject: Re: GroupLens (gnus-gl.el)
Date: Sat, 01 Feb 2003 23:40:14 -0500	[thread overview]
Message-ID: <m31y2r9txt.fsf@heechee.beld.net> (raw)
In-Reply-To: <iluof5vcto1.fsf@latte.josefsson.org> (Simon Josefsson's message of "Sun, 02 Feb 2003 03:17:50 +0100")

On Sun, 02 Feb 2003, jas@extundo.com wrote:
> Ted Zlatanov <tzz@lifelogs.com> writes:

>> So let's build an authorization system, using the standard "put
>> this number in a noisy image and make the user type it back"
>> technique.
> 
> It is simple to break most, if not all, currently used automated
> turing tests...

An image of a word/number with random noise and a random font is
pretty hard to recognize automatically.  But anyhow, this is just to
apply to be a contributor - you have to be voted in next, see below :)

>> You'll have to register through it, and the system could also
>> require a PGP message signature every time you submit a score
> 
> This could work, but only if users trust the signatures out of band,
> which for many computer savvy people is already possible.  Getting
> your key signed by computer savvy people wherever you are is not
> that difficult (think debian).  Abusers could be locked out by
> placing their keys on a blacklist, threshold signed by people that
> think they should be locked out.  Then other users can chose which
> blacklist to use and which threhshold to require (i.e., how many
> signatures of implicitly trusted people required to black list
> someone).
> 
> All this assumes there are more good, and actively interested, users
> than bad users, which I believe is as good as you can get (byzantine
> models etc).

Those who used to frequent BBS systems will remember there used to be
new user voting systems.  New users would have to get a number of
votes from current users to be accepted.  Furthermore, the sysop could
delete the account if he felt like it.

New users had to read the greeting messages carefully, and spend more
than a few minutes answering a detailed questionnaire.  They had to
show some intelligence, some wit, and some awareness of the purpose of
the board.  Thus, their reading and writing skills were a factor
(unless they simply knew a lot of current members).

The equivalent for Gnus moderation would be a user moderation group.
Let's say group Kabal is started by me.  I would tell Gnus users:
point your Gnus to http://kabal.org/gnus-lens.  There, they would find
the current moderator list, and they would set up GnusLens (how about
that name instead of GroupLens?) to consult that web site for article
scores through some HTTP low-bandwidth mechanism.

I would promote a few other people to be Kabal meta-moderators, and
they would also have the authority to give Kabal contributors scores,
to blacklist contributors, etc.  Furthermore, while it may take 20
regular group contributors to approve or reject a new contributor,
meta-moderators could do it on their own.

Picking the Kabal user group would mean you accept me and my friends
as good judges of character, not as good article scorers necessarily.

>> It will be difficult to set up, and that will be a Good Thing IMO.
> 
> If we assume there are more good people than bad people in the
> world, making it easy enough for everyone to use would improve the
> system.  (And if we make the opposite assumption, then the good
> users could simply negate the votes on reading, if they don't tell
> the bad users. :-))

I don't know about good/bad user ratios.  I think making it hard to
sign up (in a read-the-FAQ way, not in a IQ-test way) simply means
that meta-moderators and regular contributors will have less people to
vote for.

This is getting a bit off-track for Gnus, but it's all probably
necessary if we want to create a GnusLens system (GnusLoupe? I don't
know what a good name would be, but I'm pretty sure GroupLens is
trademarked according to their web site).  Writing the code to run
such a web site is definitely a major endeavor, and the site would
generate a lot of CPU load and network traffic.

Ted




  reply	other threads:[~2003-02-02  4:40 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-01-27 18:59 Ted Zlatanov
2003-01-28 22:11 ` three nnmaildir questions: naming, numbering, and splitting David Wuertele
2003-01-28 22:40   ` Paul Jarc
2003-01-28 23:26     ` David Wuertele
2003-01-29  0:31       ` Paul Jarc
2003-01-29  7:29   ` Kai Großjohann
2003-02-01 16:22 ` GroupLens (gnus-gl.el) Lars Magne Ingebrigtsen
2003-02-01 20:59   ` Kai Großjohann
2003-02-01 21:24     ` Lars Magne Ingebrigtsen
2003-02-02 12:20       ` Alex Schroeder
2003-02-02 12:25         ` Lars Magne Ingebrigtsen
2003-02-02 12:19     ` Alex Schroeder
2003-02-02  0:18   ` Raja R Harinath
2003-02-02  0:24     ` Lars Magne Ingebrigtsen
2003-02-02  1:34       ` Ted Zlatanov
2003-02-02  2:17         ` Simon Josefsson
2003-02-02  4:40           ` Ted Zlatanov [this message]
2003-02-02 17:29       ` Raja R Harinath

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=m31y2r9txt.fsf@heechee.beld.net \
    --to=tzz@lifelogs.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).