We've discussed several times the notion of a native function similar 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.
> 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.
On 1/11/08, Geoffrey Sneddon <foolist...@googlemail.com> wrote:
> - 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.
> 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?
Scott Merrill wrote: > On 1/11/08, Geoffrey Sneddon <foolist...@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.
> On 1/11/08, Geoffrey Sneddon <foolist...@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.
>> 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 <foolist...@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.
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? 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.
> 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? 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.
On Tue, Apr 15, 2008 at 8:03 PM, Michael C. Harris
<michael.twof...@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?
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.twof...@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?
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.
|>> 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.
<peter.westw...@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?
> | 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.
