[Rubygems-developers] Wiki Spam

Austin Ziegler halostatue at gmail.com
Thu Sep 9 00:00:32 EDT 2004

On Wed, 8 Sep 2004 23:17:53 -0400 (EDT), Gavin Sinclair
<gsinclair at soyabean.com.au> wrote:
>> Gavin Sinclair wrote:
>>> A) Who's "we"?
>>> B) What's the solution?
>>> C) Why doesn't anyone appear to listen to my suggestion for
>>> preventing wiki spam? (Which is: disallow edits containing more
>>> than N -- e.g. N = 2 -- external links.)
>> Austin Z[ie]gler is adding authentication to Ruwiki and Tom
>> Copeland is marrying that to the RubyForge login. This means that
>> only users who have logged in to RubyForge will be able to edit
>> wiki pages. Ruwiki will then become the standard wiki for
>> RubyForge. This work is very nearly completed.
>> Existing RubyForge wikis can continue to use their existing wiki
>> and convert their content at their leisure (both wikis can run
>> side-by-side on each such project), but obviously those of us who
>> have been spammed often have an incentive to convert soon.
> Thanks. And (C)? :)

I'll deal with (c) momentarily, Gavin, but I want to make certain
things clear :) This will also help me put together some
documentation for use at RubyForge regarding the use of Ruwiki.

There are going to be some problems and missing features with Ruwiki
when it's implemented -- I wasn't planning on having it turned on at
RubyForge until 0.9.0 or even 0.10.0, and although I had planned on
having 0.9.0 out in seven days (to give me two weeks to work on a
presentation for RubyConf), I haven't even started work on the
"real" work behind 0.9.0 because the work that I had planned for
0.8.1 turned out to be much larger than I thought, plus it presented
Archive::Tar::Minitar 0.5.0 as an opportunity.

Then this request came along... Not that I'm complaining. The work
is essentially done for this -- I haven't figured out some parts of
it, but that's in part because I want to do some more testing with
the bits from RubyForge and I need some information from Tom -- and
he's been busy, too. I *have* to spend a bit more time on this than
I'm sure Curt wants me to spend, because I don't want to have to
rewrite this portion of the code five times before a 1.0 release :)

At any rate, there are going to be features that are missing:

1. Versioning. Ruwiki *does* keep version history. It just doesn't
   have any way to display it. It probably won't until the Actions
   code is complete, because I *must* streamline the core handling;
   it's a real pain in the ass to add new functionality right now.
   This will likely be true even if someone volunteers some code for
   me -- the Actions code is imperative.

2. An enhanced search using Dave Thomas's vector search code from
   RubLog. If someone completes this port to use the Page format,
   I'll use it. (Yes, that's a blatant hit to someone on this list
   :) This is mostly handled in the backend, so it isn't related to
   the Actions code.

3. Anti-spam features. Right now, I don't see that I'm going to have
   time to put blacklisting, external URL redirection, or robot
   exclusion. Parts of this, I think, are related to Actions code.

4. RSS. I can't figure out Kou's RSS module, and while I can
   definitely use the existing templating library for this, I have
   other issues that need consideration for this (our RecentChanges
   format isn't conducive to RSS syndication).

There are a couple of other features that I don't have problems
shifting, but these are big ones that were going to be moved forward
or or focussed upon following the Actions code work.

Also, before this can happen, I *have* to finish the 0.8.1 release
or whatever I end up calling it), because this is the release that
will make deployment of Ruwiki *easy* on the folks at RubyForge.
They will be able to have a single installation of Ruwiki's core
libraries and everything else will Just Work. (Much of it would
before, but this has been a focus for making deployment easy.) I'm
working on that -- but it's not easy, because I'm having to learn
rake now (I have to go through some gyrations to get everything in
place, now).

Finally, about your point (C). I don't see that it's practically
feasible. Even within Ruwiki's default pages, I have pages that have
multiple external links. Is your proposal for the addition of more
than two external links at an editing session? Or more than two
period? It's not so easy, though, because Ruwiki supports some
standard Ruby conventions: [ruby-talk:12345] points to the sample
message :) Well, sort of, since ruby-talk.org is under maintenance
and has been for a while :)

By time Ruwiki is rendering a page, it doesn't know anything about
the previous version of the page. When it's saving a page, it
doesn't know anything about the actual contents of the page (I'm not
kidding!). There are other things that I will be doing to prevent
spam or the benefits of spam in Ruwiki environments (banlists, URI
redirection, robot exclusion on edit pages), etc.

The first site that gets the treatment from the authenticating
Ruwiki will be one of Curt's sites -- either wxRuby or One-Click.
But only one -- I want a bit of time of shake out so that any bugs
can be fixed before inflicting it on everyone else. My hope is that
by time RubyConf comes around, Ruwiki can be one of the two Wikis
available for RubyForge, and by the New Year, it is the wiki of
choice for RubyForge.

Austin Ziegler * halostatue at gmail.com
               * Alternate: austin at halostatue.ca
: as of this email, I have [ 3 ] Gmail invitations

More information about the Rubygems-developers mailing list