[wp-trac] [WordPress Trac] #16838: Excluding Akismet from Future WordPress Releases
WordPress Trac
noreply at wordpress.org
Wed Dec 4 18:35:13 UTC 2013
#16838: Excluding Akismet from Future WordPress Releases
-------------------------+------------------------------
Reporter: sc0ttkclark | Owner:
Type: enhancement | Status: reopened
Priority: normal | Milestone: Awaiting Review
Component: Plugins | Version: 3.1
Severity: normal | Resolution:
Keywords: |
-------------------------+------------------------------
Comment (by MikeSchinkel):
Replying to [comment:29 bpetty]:
> There literally isn't a single other free spam plugin that we could
bundle that would actually be effective unless it also follows the same
model as Akismet with using a 3rd party service to analyze and rank spam
comments.
Well, once [https://github.com/WP-API/WP-API WP-API] gets incorporated
into core a continuously effective peer-to-peer plugin ''could'' be
implemented that would not require such a service. The peer-to-peer
service could have a set of 10+ volunteer central servers like how the 10
root DNS servers work. And such a plugin would also potentially enable
trackbacks to be usable again by allowing site owners to validate
legitimate trackbacks using oAuth and block spammy ones.
Such a plugin could even allow similar site to optimize for spam is
outright blocks. For example, I have a blog about WordPress plugin
development and posters who use the author name ''"Hollister Outlet"'' or
''"Abercrombie"'' should be outright blocked vs. tagged as spam. However
having 'WordPress"'' in the name should not be a concern per se on my
blog. But for a fashion blogger, the reverse is probably true.
A peer-to-peer plugin could even possibly orchestrate a denial-of-service
attack on the spammer!
''(Or not. I can wish. :)''
Maybe this could be a potential [http://make.wordpress.org/core/2013/11/27
/features-as-plugins-register-your-interest/ Feature-as-Plugin]? Having a
viable alternative certainly would remove reason to ignore this ticket.
> Anything else would be defeated terribly within months of releasing it,
and we'd be back at square one anyway. … I don't believe we have any
requirement to provide another bundled replacement.
I respectfully disagree with that. See above.
> I believe history has proven that there needs to be some diversity here,
and with that, WP needs to have a requirement that it doesn't unfairly
favor any single solution (by bundling it by default).
Agree with that. Unless the solution is a core ''(and extensible)''
feature. Then I think a single solution is preferable; remember pre 3.0
vs. custom post types?
-Mike
P.S. BTW, I recently wrote [https://github.com/hardcorewp/spam-blacklist a
Spam Blacklist plugin] because I was getting over ~500 Akismet spam-tagged
comments a day on a very low traffic blog. The plugin mined the 100,000+
spam I had received to create a **block** list by author, IP, email and
URL, and if blocked it throws up a screen offering to whitelist the person
if they contact me.
**It was a blunt force approach to solve ''my'' problem** and has many
issues so it's not a general solution but the core concept was to
**block** ''(vs. just spam-tag)'' what is easily identifiable as spam
''**on my unique blog**'' given the history of spam on my blog and the
topics I write about, and then giving letting the commenter know their
comment was blocked so they can contact me to allow them to be
whitelisted.
So I think having a peer-to-peer spam plugin architected and built for
core that takes into consideration each site's content could go a long way
to finally resolving the ongoing spam problem in addition to satisfying
the concerns raised by this ticket. FWIW.
--
Ticket URL: <http://core.trac.wordpress.org/ticket/16838#comment:30>
WordPress Trac <http://core.trac.wordpress.org/>
WordPress blogging software
More information about the wp-trac
mailing list