[Rubygems-developers] Wiki Spam

Curt Hibbs curt at hibbs.com
Thu Sep 9 07:59:13 EDT 2004

Thanks for the detailed response Austin, I really appreciate your all of
your efforts (I wish I could make it to RubyConf so that we could meet!).

Just for the record, the reason I cc you and Tom on these things is *not*
because I want to exert excessive pressure, but because I want us all to
stay aware of the level of the problem and maintain an appropriate sense of

Thanks again,

Austin Ziegler wrote:
> 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
> --
> Austin Ziegler * halostatue at gmail.com
>                * Alternate: austin at halostatue.ca
> : as of this email, I have [ 3 ] Gmail invitations
> _______________________________________________
> Rubygems-developers mailing list
> Rubygems-developers at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rubygems-developers
> ---
> Incoming mail is certified Virus Free.
> Checked by AVG anti-virus system (http://www.grisoft.com).
> Version: 6.0.717 / Virus Database: 473 - Release Date: 7/8/2004

More information about the Rubygems-developers mailing list