RFC: CommentBack
Scott Merrill
to that provided by CoComment. Here is one proposal for how we might
accomplish that. I call it CommentBack. Someone please devise a
better, more clever name.
I envision CommentBack acting much like a pingback:
* Alice leaves a comment on Bob's Habari-powered blog
* Upon completion (or, optionally, after Bob approves Alice's
comment), Bob's Habari contacts Alice's site, making an HTTP HEAD
request
* Bob's Habari looks for the presence of an "X-Commentback" header,
which defines the XMLRPC endpoint on Alice's blog for CommentBack
* Bob's Habari loads the URL defined in the X-Commentback header
* Bob's Habari sends an XMLRPC thingie containing the following data:
- Alice's name as provided in her comment
- Alice's email address as provided in her comment
- Alice's comment
- the permalink to Alice's comment
* Alice's blog stores this as a new comment of type CommentBack, with
a status of "unapproved"
* Alice's comment is displayed in some moderation panel -- maybe
alongside regular comments or in a new moderation queue -- until Alice
approves it. Once approved, it is displayed alongside other approved
CommentBacks.
There are several things I can think of to (marginally) help reduce
the incidence of CommentBack spam:
- do a DNS lookup on the host portion of the permalink specified in
the ComnentBack transmission. If the IP address of the connecting
server does not match the IP of the blog to which the comment was
added, drop the connection.
- Use a (semi-)random URL inside the X-Commentback header, ensuring
that would-be spammers need to at least make an HTTP HEAD request.
- Require verification of the incoming comment, such that Alice's blog
would contact Bob's blog (via a special URL). Bob's blog could
respond with the MD5 sum of some specific data from Alice's comment,
which Alice's blog could compare to the data received in the initial
CommentBack connection
- The second-stage verification described above could be complemented
by use of a cronjob, to defer verification to some later time.
- Allow Alice to define a set of names / email addresses she uses when
commenting on blogs. Any incoming CommentBack that contains a name or
email address not on her list is considered bogus and discarded.
Chris Davis' PreApproved plugin could readily be extended to support
preapproval of CommentBack items when the URL and IP address match.
I know diddly-squat about pingbacks and XMLRPC, so it might well be
the case that it's the wrong tool for this job. But I think pingbacks
provide much of the functionality we seek, so it makes sense (to me)
to use it as a starting point, and to build upon the XMLRPC framework
it uses, rather than to completely reinvent the wheel.
Comments?
Geoffrey Sneddon
On 10 Jan 2008, at 01:07, Scott Merrill wrote:
> I envision CommentBack acting much like a pingback:
> * Alice leaves a comment on Bob's Habari-powered blog
> * Upon completion (or, optionally, after Bob approves Alice's
> comment), Bob's Habari contacts Alice's site, making an HTTP HEAD
> request
> * Bob's Habari looks for the presence of an "X-Commentback" header,
> which defines the XMLRPC endpoint on Alice's blog for CommentBack
> * Bob's Habari loads the URL defined in the X-Commentback header
> * Bob's Habari sends an XMLRPC thingie containing the following data:
> - Alice's name as provided in her comment
> - Alice's email address as provided in her comment
> - Alice's comment
> - the permalink to Alice's comment
> * Alice's blog stores this as a new comment of type CommentBack, with
> a status of "unapproved"
> * Alice's comment is displayed in some moderation panel -- maybe
> alongside regular comments or in a new moderation queue -- until Alice
> approves it. Once approved, it is displayed alongside other approved
> CommentBacks.
- Pingback currently falls back to a |link|@rel=pingback, as not
everyone can control HTTP headers. Something like this is probably
needed.
- Why do we need name and email sent to the blog?
- It'd be nice to have proof of who someone commenting is, so we don't
need to approve comments (OpenID?).
- If this is a plugin, surely this shows exactly why a plugin needs to
be able to have its own page?
- I assume we should not lock this down to Habari, but rather provide
plugins for other blogging platforms too?
- Something like this should, almost without question, have a
specification, as to not have anything that wants to implement it have
to reverse engineer Habari.
> There are several things I can think of to (marginally) help reduce
> the incidence of CommentBack spam:
> - do a DNS lookup on the host portion of the permalink specified in
> the ComnentBack transmission. If the IP address of the connecting
> server does not match the IP of the blog to which the comment was
> added, drop the connection.
Load balanced servers, especially those over multiple continents, have
IPs totally unrelated to one-another. Just because the IPs don't match
doesn't mean they aren't the same site.
> - Require verification of the incoming comment, such that Alice's blog
> would contact Bob's blog (via a special URL). Bob's blog could
> respond with the MD5 sum of some specific data from Alice's comment,
> which Alice's blog could compare to the data received in the initial
> CommentBack connection
How does this help? From the face of it all this does is improve
robustness of the protocol, but HTTP already has the Content-MD5
header that does a similar thing.
> I know diddly-squat about pingbacks and XMLRPC, so it might well be
> the case that it's the wrong tool for this job. But I think pingbacks
> provide much of the functionality we seek, so it makes sense (to me)
> to use it as a starting point, and to build upon the XMLRPC framework
> it uses, rather than to completely reinvent the wheel.
<http://www.hixie.ch/specs/pingback/pingback> and <http://www.xmlrpc.com/spec
> define the two.
With regards to using XML-RPC at all, I'd question why we don't use
its successor, SOAP.
--
Geoffrey Sneddon
<http://gsnedders.com/>
Scott Merrill
> - Pingback currently falls back to a |link|@rel=pingback, as not
> everyone can control HTTP headers. Something like this is probably
> needed.
Fair enough, and easy enough to include.
> - Why do we need name and email sent to the blog?
If multiple people blog from the same site, how will the recipient
blog know which author to attribute the incoming CommentBack? Also,
if we support the notion of a list of known names used when
commenting, it would be easy to filter out spam.
> - It'd be nice to have proof of who someone commenting is, so we don't
> need to approve comments (OpenID?).
Yes, Owen suggested on IRC that Bob's Habari could direct Alice back
to her own site upon submitting the comment, where she could directly
approve the CommentBack. I think that's a fine idea.
> - If this is a plugin, surely this shows exactly why a plugin needs to
> be able to have its own page?
I believe you'll have to connect the dots for us. Why does this need
its own page?
> - I assume we should not lock this down to Habari, but rather provide
> plugins for other blogging platforms too?
There is nothing Habari-specific in the idea. I would love to see
plugins for other platforms developed to use this.
> - Something like this should, almost without question, have a
> specification, as to not have anything that wants to implement it have
> to reverse engineer Habari.
That specification is what I tried to begin above. If there's support
for this idea, a formal spec can be drafted.
> > There are several things I can think of to (marginally) help reduce
> > the incidence of CommentBack spam:
> > - do a DNS lookup on the host portion of the permalink specified in
> > the ComnentBack transmission. If the IP address of the connecting
> > server does not match the IP of the blog to which the comment was
> > added, drop the connection.
>
> Load balanced servers, especially those over multiple continents, have
> IPs totally unrelated to one-another. Just because the IPs don't match
> doesn't mean they aren't the same site.
How often do blogs use load balancers on multiple continents? The
overwhelming majority of users of this functionality would be folks
running simple blogs. If you have suggestions for ways to address
your concern while still working to minimize spam, please present
them.
> > - Require verification of the incoming comment, such that Alice's blog
> > would contact Bob's blog (via a special URL). Bob's blog could
> > respond with the MD5 sum of some specific data from Alice's comment,
> > which Alice's blog could compare to the data received in the initial
> > CommentBack connection
>
> How does this help? From the face of it all this does is improve
> robustness of the protocol, but HTTP already has the Content-MD5
> header that does a similar thing.
It helps by ensuring that the CommentBack isn't generated by a
fire-and-forget spam agent. By requiring the CommentBack to be
confirmed, it requires that the spammers invest in servers to respond
to the verification connection with the proper data. No, I don't
think this is the greatest mechanism in the world to prevent abuse,
but I think it's a satisfactory component of an anti-spam plan.
> > I know diddly-squat about pingbacks and XMLRPC, so it might well be
> > the case that it's the wrong tool for this job. But I think pingbacks
> > provide much of the functionality we seek, so it makes sense (to me)
> > to use it as a starting point, and to build upon the XMLRPC framework
> > it uses, rather than to completely reinvent the wheel.
>
> <http://www.hixie.ch/specs/pingback/pingback> and <http://www.xmlrpc.com/spec
> > define the two.
>
> With regards to using XML-RPC at all, I'd question why we don't use
> its successor, SOAP.
To the best of my knowledge, Habari does not have a SOAP library. It
does have aN XMLRPC library.
Considering my comment about my familiarity with XMLRPC, I believe it
is your responsibility to advocate why you think we should use SOAP.
What benefits does it provide? What drawbacks exist, if any?
Owen Winkler
> On 1/11/08, Geoffrey Sneddon <fooli...@googlemail.com> wrote:
>> - If this is a plugin, surely this shows exactly why a plugin needs to
>> be able to have its own page?
>
> I believe you'll have to connect the dots for us. Why does this need
> its own page?
I'm guessing because you'll want a place to approve CommentBacks that
you've created. But there is already a page that does this - the
comment moderation page.
> How often do blogs use load balancers on multiple continents? The
> overwhelming majority of users of this functionality would be folks
> running simple blogs. If you have suggestions for ways to address
> your concern while still working to minimize spam, please present
> them.
Requiring the user who leaves the comment to log in to their own site
(ala OpenID or similar) when making the comment ensures its
authenticity, so verifying by IP or content should not be necessary.
>> With regards to using XML-RPC at all, I'd question why we don't use
>> its successor, SOAP.
Because:
1) We have already implemented a lightweight XML-RPC library, which is
used with other live protocols, like Pingback and the Metaweblog API.
2) SOAP is comparatively not a light protocol, and reimplementing it for
our license if it doesn't already exist would be burdensome.
3) There is no other application that I know of for a SOAP library in
our milieu besides this one thing that we'd be making up, thus requiring
other platforms that might like to implement CommentBack to also include
SOAP, which they're much less likely to do for the same reasons listed here.
4) We can't rely on built-in PHP functions to supply this functionality
because they are not part of a standard install.
5) What does SOAP do in regard to CommentBack that XML-RPC can't?
Nothing, as far as I am aware.
Owen
Geoffrey Sneddon
On 11 Jan 2008, at 19:06, Scott Merrill wrote:
> On 1/11/08, Geoffrey Sneddon <fooli...@googlemail.com> wrote:
>> - Why do we need name and email sent to the blog?
>
> If multiple people blog from the same site, how will the recipient
> blog know which author to attribute the incoming CommentBack? Also,
> if we support the notion of a list of known names used when
> commenting, it would be easy to filter out spam.
Okay, that's obvious enough. However, email's tend to never leave the
server they are posted on (though we would already know that the
server is one specified in the comment URL) — a possible privacy
concern. Also, with plus/minus addressing email addresses may not be
the same, and I may use my name on some blog but use gsnedders on my
blog.
>> - Something like this should, almost without question, have a
>> specification, as to not have anything that wants to implement it
>> have
>> to reverse engineer Habari.
>
> That specification is what I tried to begin above. If there's support
> for this idea, a formal spec can be drafted.
I'll state here (so you can quote me when I act like an asshole) that
I'm willing to edit such a spec.
>>> There are several things I can think of to (marginally) help reduce
>>> the incidence of CommentBack spam:
>>> - do a DNS lookup on the host portion of the permalink specified in
>>> the ComnentBack transmission. If the IP address of the connecting
>>> server does not match the IP of the blog to which the comment was
>>> added, drop the connection.
>>
>> Load balanced servers, especially those over multiple continents,
>> have
>> IPs totally unrelated to one-another. Just because the IPs don't
>> match
>> doesn't mean they aren't the same site.
>
> How often do blogs use load balancers on multiple continents? The
> overwhelming majority of users of this functionality would be folks
> running simple blogs. If you have suggestions for ways to address
> your concern while still working to minimize spam, please present
> them.
Requiring something like OpenID login to Alice's blog would surely get
around this?
>>> - Require verification of the incoming comment, such that Alice's
>>> blog
>>> would contact Bob's blog (via a special URL). Bob's blog could
>>> respond with the MD5 sum of some specific data from Alice's comment,
>>> which Alice's blog could compare to the data received in the initial
>>> CommentBack connection
>>
>> How does this help? From the face of it all this does is improve
>> robustness of the protocol, but HTTP already has the Content-MD5
>> header that does a similar thing.
>
> It helps by ensuring that the CommentBack isn't generated by a
> fire-and-forget spam agent. By requiring the CommentBack to be
> confirmed, it requires that the spammers invest in servers to respond
> to the verification connection with the proper data. No, I don't
> think this is the greatest mechanism in the world to prevent abuse,
> but I think it's a satisfactory component of an anti-spam plan.
That may work on grounds that spammers are lazy (I won't expand on
that comment, apart from saying that how naïvely they often scrap HTML
is ridiculously easy to work around).
>>> I know diddly-squat about pingbacks and XMLRPC, so it might well be
>>> the case that it's the wrong tool for this job. But I think
>>> pingbacks
>>> provide much of the functionality we seek, so it makes sense (to me)
>>> to use it as a starting point, and to build upon the XMLRPC
>>> framework
>>> it uses, rather than to completely reinvent the wheel.
>>
>> <http://www.hixie.ch/specs/pingback/pingback> and <http://www.xmlrpc.com/spec
>>> define the two.
>>
>> With regards to using XML-RPC at all, I'd question why we don't use
>> its successor, SOAP.
>
> To the best of my knowledge, Habari does not have a SOAP library. It
> does have aN XMLRPC library.
>
> Considering my comment about my familiarity with XMLRPC, I believe it
> is your responsibility to advocate why you think we should use SOAP.
> What benefits does it provide? What drawbacks exist, if any?
Having asked various people (including Ian Hickson, co-ed. Pingback
1.0), it appears that SOAP is an even worse written specification than
XML-RPC (which, to say the least, is hard) which inevitably has
consequences for interoperability; so XML-RPC is probably better than
SOAP. Ian did however, notably, say that choosing XML-RPC for Pingback
1.0 was "pretty dumb".[1]
However, what would be a better solution for Pingback definitely
wouldn't map to CommentBack; but disregarding that, I still think that
XML-RPC would probably be overkill for CommentBack too (needless to
say, I can't think of any good alternative while still using HTTP —
I'll try and get someone with more experience designing such protocols
to post here).
On 11 Jan 2008, at 20:47, Owen Winkler wrote:
> Scott Merrill wrote:
>> On 1/11/08, Geoffrey Sneddon <fooli...@googlemail.com> wrote:
>>> - If this is a plugin, surely this shows exactly why a plugin
>>> needs to
>>> be able to have its own page?
>>
>> I believe you'll have to connect the dots for us. Why does this need
>> its own page?
>
> I'm guessing because you'll want a place to approve CommentBacks that
> you've created. But there is already a page that does this - the
> comment moderation page.
I'd hate to have comments I post on another site and comments posted
on my site intermixed. They are two totally different data sets,
completely unrelated to one another, though there may be occasional
intersection of my comments on my blog.
>> How often do blogs use load balancers on multiple continents? The
>> overwhelming majority of users of this functionality would be folks
>> running simple blogs. If you have suggestions for ways to address
>> your concern while still working to minimize spam, please present
>> them.
>
> Requiring the user who leaves the comment to log in to their own site
> (ala OpenID or similar) when making the comment ensures its
> authenticity, so verifying by IP or content should not be necessary.
What other things can we use apart from OpenID? There is already a
Habari OpenID plugin, and anything else, AFAIK, is closed.
--
Geoffrey Sneddon
<http://gsnedders.com/>
[1]: http://krijnhoetmer.nl/irc-logs/whatwg/20080111#l-200 (between
19:38/22:12)
Michael C. Harris
relation to allowing Disqus to write follow-up comments back to your
blog. There are also other commenting services becoming popular, such
as SezWho and Intense Debate. Also FriendFeed which allows comments to
be posted about blog posts on FriendFeed, and some recent discussion
on wp-xmlrpc about a comment API
(http://comox.textdrive.com/pipermail/wp-xmlrpc/2008-April/000187.html).
Is there still the will to work on a CommentBack standard? Do those
who know WP people think they would be willing to participate in a
joint venture? I think the people at Disqus might be willing to be
involved.
--
Michael C. Harris, School of CS&IT, RMIT University
http://twofishcreative.com/michael/blog
Chris J. Davis
the conversation.
Scott Merrill
<michael...@gmail.com> wrote:
> A commenting API has come up recently in discussions elsewhere in
> relation to allowing Disqus to write follow-up comments back to your
> blog. There are also other commenting services becoming popular, such
> as SezWho and Intense Debate. Also FriendFeed which allows comments to
> be posted about blog posts on FriendFeed, and some recent discussion
> on wp-xmlrpc about a comment API
> (http://comox.textdrive.com/pipermail/wp-xmlrpc/2008-April/000187.html).
>
> Is there still the will to work on a CommentBack standard?
Yes.
> Do those
> who know WP people think they would be willing to participate in a
> joint venture? I think the people at Disqus might be willing to be
> involved.
The earlier we engage other participants, the more likely we can work
together to build a truly cross-platform solution. To that end, we
should probably try to engage Six Apart, Drupal, and some other
players to help us in our work.
I'm happy to be involved in the discussion. Perhaps a "call for
participation" announcement on the hp.o website would be a good first
step?
Cheers,
Scott
Michael C. Harris
It might be more effective if we garner support behind the scenes
before making an announcement, but we should be coordinated about who
we approach from different groups.
Peter Westwood
Hash: SHA1
Michael C. Harris wrote:
| On Wed, Apr 16, 2008 at 08:39:40AM -0400, Scott Merrill wrote:
|> On Tue, Apr 15, 2008 at 8:03 PM, Michael C. Harris
|> <michael...@gmail.com> wrote:
|>> Do those
|>> who know WP people think they would be willing to participate in a
|>> joint venture? I think the people at Disqus might be willing to be
|>> involved.
As a WordPress developer I would say that any work towards implementing
common standards for XMLRPC comment api would be welcome.
Is there somewhere I can read a summary of what CommentBack is trying to
achieve?
|> The earlier we engage other participants, the more likely we can work
|> together to build a truly cross-platform solution. To that end, we
|> should probably try to engage Six Apart, Drupal, and some other
|> players to help us in our work.
|>
|> I'm happy to be involved in the discussion. Perhaps a "call for
|> participation" announcement on the hp.o website would be a good first
|> step?
|
| It might be more effective if we garner support behind the scenes
| before making an announcement, but we should be coordinated about who
| we approach from different groups.
|
Within the WordPress arean Joseph Scott [1] is most heavily involved in
the XML-RPC side of things so it would be worth contacting him.
[1] http://joseph.randomnetworks.com/
Cheers
westi
- --
Peter Westwood
http://blog.ftwr.co.uk | http://westi.wordpress.com
~ C53C F8FC 8796 8508 88D6 C950 54F4 5DCD A834 01C5
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFIB5MfVPRdzag0AcURAujaAJ44gGuwDbbdtf+9r61TL0pbCA3opQCfTOrs
zRuYXgKZXGi3OprwHsi/zV4=
=Psg8
-----END PGP SIGNATURE-----
Scott Merrill
<peter.w...@ftwr.co.uk> wrote:
> As a WordPress developer I would say that any work towards implementing
> common standards for XMLRPC comment api would be welcome.
>
> Is there somewhere I can read a summary of what CommentBack is trying to
> achieve?
http://wiki.habariproject.org/en/Summer_of_Code#Comment_Tracking
http://groups.google.com/group/habari-dev/msg/6b72a9e2a5d6f334
Additional discussion, of which your reply is a part:
http://groups.google.com/group/habari-dev/browse_frm/thread/5a5fabe48110df2b
> | It might be more effective if we garner support behind the scenes
> | before making an announcement, but we should be coordinated about who
> | we approach from different groups.
> |
>
> Within the WordPress arean Joseph Scott [1] is most heavily involved in
> the XML-RPC side of things so it would be worth contacting him.
>
> [1] http://joseph.randomnetworks.com/
Thanks for the link, Peter. We'll wrangle amongst ourselves who
should approach Joseph.
Cheers,
Scott