On 1/24/07, Ligulem <ligulem(a)pobox.com> wrote: They already choose whether to spam-blacklist particular links.

But local sysops can override again that blacklist by including that domain on the local whitelist.

And it seems that there will also come a local blacklist active; http://bugzilla.wikimedia.org/show_bug.cgi?id=8492

On 24/01/07, Gregory Maxwell <gmaxwell(a)gmail.com> wrote: We'd have no users, for a start.

On 24/01/07, Gregory Maxwell <gmaxwell(a)gmail.com> wrote: On en:, the problem is finding a Meta admin in less than geological time. - d.

On 25/01/07, Gerard Meijssen <gerard.meijssen(a)gmail.com> wrote: If you don't mind having the en:wp spamfighters messaging you lots, then good :-) - d.

On 1/24/07, Andrew Cates <andrew(a)catesfamily.org.uk> wrote: There are well over 8 million external links in enwiki alone, including well over a half million distinct domains via HTTP. A greenlist is not a remotely sane solution because of this... Sane solutions are, however, possible. I would suggest that any proposed feature interact with whatever version flagging system we end up implementing. I don't believe that will likely be sufficient since the the proposal most likely to be implemented just provides us with a not-vandalized flag... which doesn't do much to indicate that any member of the editing community has actually reviewed the link (and pure time limits are even worse in that regard). Just keep in mind that anything proposed must scale, and it must be robust against editing (special text that only admins can insert is not robust against editing... for example, a non admin couldn't revert page blanking on a page that had special text links).

maintaining an adequate list for example DMOZ is a wikipedia partner project and we could take all the links from non-commercial pages of

Well it says so on every page below home at dmoz "*Visit our sister sites* mozilla.org <http://www.mozilla.org/> | ChefMoz <http://chefmoz.org/> | MusicMoz <http://musicmoz.org/> | Open-Site <http://open-site.org/> | Wikipedia" <http://en.wikipedia.org/> Unrequited love perhaps? ==================== Rob Church wrote: _______________________________________________ Wikitech-l mailing list Wikitech-l(a)lists.wikimedia.org http://lists.wikimedia.org/mailman/listinfo/wikitech-l

Well it says so on every page below home at dmoz "*Visit our sister sites* mozilla.org <http://www.mozilla.org/> | ChefMoz <http://chefmoz.org/> | MusicMoz <http://musicmoz.org/> | Open-Site <http://open-site.org/> | Wikipedia" <http://en.wikipedia.org/>

On 1/24/07, Andrew Cates &lt;andrew(a)catesfamily.org.uk&gt; wrote: [snip] [snip] Anyone else find it deeply ironic that DMOZ would somehow be mentioned as a solution to our spamming problems? For more background on the current state of DMOZ: http://www.skrenta.com/2006/12/dmoz_had_9_lives_used_up_yet.html

On 1/24/07, Andrew Cates &lt;andrew(a)catesfamily.org.uk&gt; wrote: What, you didn't sell your dmoz account to SEO's during the big rush? Sucker. :) Oh, our goal is to help spammers track their progress? I must be confused, because I thought we were trying to make quality articles. .. Remember those article things? The blocks of text that hopefully someone with knowledge about the subject cares about? The sort of folks who might actually have a clue about a link being useful or a worthless advertisement? So... We can handle writing an encyclopedia on a word by word basis.. but suddenly approving links is too hard? Do you actually think that it's reasonable to ask admins to continually edit a page which is hundreds of megabytes, and somehow keep up with the thousands of totally valid links added across millions of pages by thousands of non-admins every week? Certainly you can't expect them to use bots to do this, because on enwiki at least it seems that running a bot as with sysop flag is a crime worse than murder. What are you talking about? I don't follow you at all here. Some form of article validation/stabilization feature one of the higher technical priority for the Foundation which directly impacts the quality of our product (unlike passing out pagerank to third party sites). Once implemented it would be utterly trivial to make the links in the approved versions non-nofollow and it wouldn't require overloading adminship with another inappropriate role which the admins can't scale up to perform.

On 1/24/07, Andrew Cates &lt;andrew(a)catesfamily.org.uk&gt; wrote: Yes, as I said in my initial post.. I do not believe that simply overloading the not-vandalized flag by itself is sufficient, mostly because people don't bother looking at the externals.. and often people feel uncomfortable removing them. The same mechanism, however, could be easily applied to collect data on link reviews as they are performed... Even without that it would still give us a point of attack (i.e. when you validate a page, be sure to check new links), today we don't have such a hook. [snip] We saw an almost complete end of User: pages created by otherwise inactive users which were filled with nothing but external links after turning on nofollow for user: namespace a few months back. I'd comment more, but this is going offtopic into the land of local wiki politics. Perhaps this discussion should be continued once someone has actually coded something?

A Bloom Filter could hold the entire 8 million urls in about 1 megabyte with a false positive probability of 1% or 1.5megabytes with a 0.1% probability. Whilst loading in and out of PHP wouldn't be nice, a separate service is certainly feasible.

There are well over 8 million external links in enwiki alone, including well over a half million distinct domains via HTTP. A greenlist is not a remotely sane solution because of this... Sane solutions are, however, possible.