I was very annoyed the last time I looked at this.
Webmentions are like trackbacks, but trackbacks that do not contain the information needed to show them, instead relying on the receiving party to fetch that information from a microformat (that part seems to be missing from the spec).
What annoyed me so much that I opted to not implement it in any of those blog engines I'm involved in is that it is a useless re-invention of trackbacks. There is no point in webmentions, not one feature that could not be done with trackbacks as well. They have a wikipage arguing against trackbacks on https://indiewebcamp.com/Trackback, and all points on that page are wrong when looking at how blog engines actually implement trackbacks. Just take the first, fragile discovery: The critic is that the RDF comment needed for Trackbacks is is complex and get stripped. But frankly, it is not complex to grep for it and if you can't control your own page HTML to preserve comments, you have different problems (and one that could hit your microformat equally). More important: Trackbacks actually can be found via a rel-tag in the site head exactly like pingbacks (and I guess webmentions), rel=trackback.
And of course blog engines verify that the origin really has a link to the receiving page, the spam problem is solved there exactly like with webmentions.
What should be done is to take trackbacks and formalize the current solutions and extensions into a formal protocol. There is no need to willfully cut out the existing independent web, as in blogs, for a hipster indieweb movement.
I use trackbacks, since my chosen blog engine (serendipity) supports them. I know a number of other bloggers and they all use trackbacks. My last non-spam trackback came in on Nov 9 2015, 08:02, ignoring the ones I sent to myself (I was not very active in the meantime).
Trackbacks are alive as well. But yes, they should be revisited and repackaged, I agree that they could need a popularity boost. But that is possible without breaking compatibility for no reason.
Being on top of pingbacks makes no sense, xml-rpc is dead and a bad idea in a first place, also a lot harder to implement than just reacting to a ping + pretty much incompatible with the pull concept. If they started there, they probably did not know trackbacks existed.
Webmentions are no simpler than trackbacks, and to have them diverge for no reason makes everything more complicated for the engine. It is no straight-forward simplification at all, thus no good thing.
Thanks for the link, I appreciate the idea. Sadly, this seems useless for me. I'd need a service that I can point to in the head that converts the webmention to a trackback (and not a pingback, though that would work as well if absolutely necessary, but by default pingbacks have no description which could collide in some themes; also a harder codepath) and then sends the trackback to the blog. Fetching that later with JS is no option, it has to end up in the database.
I hope I did not just miss that (now again and when I saw it the last time), but this does not seem to capable of that.
Hi there, I made webmention.io. I haven't updated the readme or home page yet, but I recently added a "web hook" feature which is similar to what you're talking about with Trackbacks. The service will receive and verify the webmention, parse the page, and then send a post request with the contents of the comment. The format it sends looks like this http://indiewebcamp.com/jf2#Example
So, it's not quite trackback, but hopefully it's more useful!
Nice, yes, that is similar. It would be a lot more useful for me to get a trackback though – to make the blog engine receive webmentions by just converting a webmention to a trackback by your or another service would be the easiest way possible.
And something I would push into our html markup and debug (the service in the middle might make some origin checks fail), despite my concerns with webmentions as a spec and concept.
The main reason Webmention is less susceptible to spam than Trackback is, is because with Trackback, there is no requirement that the comment text have its own URL. At least with Webmention, a spammer has to create a URL for the spam comment.
The webmention.io service sends a secret token in the payload so you can verify the request came from there.
That is what I kind of tackled above, I think: In practice, all blog engines will confirm that the URL the trackback points to actually contains a link to the site receiving the trackback. I see no practical difference there between the two protocols. But your use of comments and comment urls makes me think I might miss your point?
Thanks for opening the issue, I will add a comment and subscribe.
> The critic is that the RDF comment needed for Trackbacks is is complex and get stripped.
That is super valid and the main reason why I back then in 2004 didn't implement trackback in my bloging engine but only pingback. Semantics matter.
It is virtually never parsed as RDF. RDF-in-HTML-comments is a horrible antipattern that has no use in the RDF community outside of the weird legacy use case of Trackback.
It is hidden metadata (which can and does break) and violates the DRY principle.
It is as much hidden metadata as is any other of such attempts, like schema.org and what else exists. It is a not so beautiful repetition of stuff that is already in the html, true, but it stems from another way of thinking about metadata. Maybe the RDF community does not like it anymore, but it was a thing.
Note that I'm not fan of this, rel=trackback is what should be used. But it is not complicated to add those tags into a page, which was my point.
The DRY principle in its original form does not apply here: The information in those tags will change when the information in the database changes. They are not hardcoded.
Schema.org RDFa isn't hidden. JSON-LD in a script tag is but that's equivalently goofy.
"stems from another way of thinking about metadata"? Nope. It was a clumsy hack because they actually just wanted to put the <rdf:RDF> tags in the HTML but people would complain about HTML validation so they put it in a comment tag.
At least back then I found it mega complicated, I would have needed to screen the content of the page and find the comments most probably with a RegEx I guess? Then I would need to feed the comment strings I get into a XML parser which would understand namespaces. Then I would go through the DOM of every of those comments to get out the data.
Apart from that I do not think you should compare pingback/webmention with trackback. The ones are to inform about some mention/comment, the other is transporting the content of it. If you want to compare than I would compare microformats/open-graph with trackback.
You probably would not use an XML parser. All the information needed to send a trackback is the ping-location, that is one ugly regexpression, but only one. I also am no fan of that, rel=trackback is nicer. But the (pragmatic approach to) parsing is simpler than you describe.
I'm actually not okay about the distinction. Trackbacks inform and transport the content, and webmentions inform and are coupled with an unspecified convention to get the content. They end up having the same purpose.
I remember I read something similar in Walter Isaacson's "The Innovators" book. When the internet was just starting, Tim Berners-Lee was faced with the decision of made linking "public" or "private". So basically they considered for a while that an <a> tag should be somehow "authorized" in order to exist. Of course this didn't roll out (thankfully).
Sorry if something is not 100% right, it's what I remember.
There's a useful summary on the wikipedia page for 'Linkback' [1] describing how Webmention differs from other similar schemes.
Things like Pingback and Trackback seemed to be all the rage for a few months, back in the day. They then seemed to cease being talked about - either discussion has bypassed me, or they just carry on being used, seamlessly, or they've failed. It would be great to see something like this really take off, though, especially since many bloggers started turning off comments.
I really wish this sort of thing were still usable on our modern web. This will be hijacked by spammers and it will become impossible to see legitimate mentions through the sea of spam, but it sure is a nice interface for building up a network of backlinks.
Just like Google Analytics has become useless for low traffic sites. My blog gets hundreds of page views, all from referral spam. I don't even bother trying to see if at least some real people are looking at it.
> but it sure is a nice interface for building up a network of backlinks.
The web isn't static, backlinks tend to disappear. So a one-time effort isn't useful, especially if it further complicates already bloated browsers and enables DDoS techniques.
A useful way of collecting backlinks at any point in time would be through search engines that snapshot all the visible web regularly with timestamps. It's too bad they don't offer such services anymore.
Referrer spamming is significantly else effort than this, and the validation of the target link in the source does provide a higher barrier. Parsing for microformats from the source also gives more structure to validate heuristically. Eventually a whitelist model will make more sense; the 'vouch' extension gives a way to construct one which puts more burden on the spammer than the receiver.
On the technical side, this seems nicer than pingbacks (which uses XML-RPC).
On the user side: dunno. I never found value in pingbacks listed at the bottom of a blog post, and I doubt that a different technique in the background will change that profoundly.
If the other page uses microformats I'm displaying their content under my post, like for example: https://jeena.net/photos/201
I also show the reposts, likes, etc. there, I even aggregate those from facebook, instagram, twitter, flickr, etc. with help of https://brid.gy/ which translates fb, tw, etc. to microformats and sends a webmention. And I'm getting more and more native webmentions, but that is most probably because I'm active in that community.
Just thinking out loud here, but... suppose that many/most nodes on the WWW implement Webmention and publish their knowledge of who links to them. In other words, the link graph can be navigated in both directions. Does that not simplify the implementation of pagerank-like algorithms somehow? Could deployment of such a linking standard make it cheaper to index the web?
This is not only susceptible to referrer spamming, but it's also a far more efficient way to do it. Ultimately it's a inbound channel where all submissions are nearly guaranteed to be reviewed by the recipient, simply because that's what it is for.
This is irrelevant to the case of referrer spamming.
Vouching may help preventing spam from percolating to public-facing pages through automated mention processing, but it does absolutely nothing to stop or to discourage referrer spam, which is aimed at the actual owners of the resource rather than their visitors.
What is referrer spamming? You mean people who look at the apache logs or something? Just don't look there, I don't see the connection between webmention and referrer.
It isn't in the HTML specification. It is a W3C Working Draft.
W3C isn't just HTML: they also publish the specifications for CSS, ARIA, XML, XSLT, XQuery, XProc, RDF, SVG, WOFF and so on. Some of which (like the XML-related stuff) have no real bearing on the browser or front-end tech.
I agree. I feel more and more sorry for browser architects every day. It seems now more than ever that modern browsers are just kitchen sinks for spec writers. I'm fully aware some of these spec authors are browser architects themselves, but cut the fat please.
We'll be stuck with these redundant proposals for decades. Webmentions could be a fantastic library on its own, though as previously mentioned, we already have trackbacks. Does it need to be an additional few files in the codebases of Chromium, Firefox, et al.? No.
Where does this spec have anything that requires code in a browser? It's purely a server-to-server protocol, to be implemented by blog engines, CMS or third party services like disqus, ... (And has nothing to do with "the HTML specification" either)
You're missing the point of standardization - it's not a legislative process that requires implementation, it's a documentation process to show what has already been implemented and how you can interoperate with it.
Webmention already has multiple libraries and services implementing it.
And in cases like this, standardization is just about the only way to ensure the feature's success. If every blog/publishing engine developed their own proprietary service for tracking linkbacks/mentions, it would likely never get off the ground at all.
Webmentions are like trackbacks, but trackbacks that do not contain the information needed to show them, instead relying on the receiving party to fetch that information from a microformat (that part seems to be missing from the spec).
What annoyed me so much that I opted to not implement it in any of those blog engines I'm involved in is that it is a useless re-invention of trackbacks. There is no point in webmentions, not one feature that could not be done with trackbacks as well. They have a wikipage arguing against trackbacks on https://indiewebcamp.com/Trackback, and all points on that page are wrong when looking at how blog engines actually implement trackbacks. Just take the first, fragile discovery: The critic is that the RDF comment needed for Trackbacks is is complex and get stripped. But frankly, it is not complex to grep for it and if you can't control your own page HTML to preserve comments, you have different problems (and one that could hit your microformat equally). More important: Trackbacks actually can be found via a rel-tag in the site head exactly like pingbacks (and I guess webmentions), rel=trackback.
And of course blog engines verify that the origin really has a link to the receiving page, the spam problem is solved there exactly like with webmentions.
What should be done is to take trackbacks and formalize the current solutions and extensions into a formal protocol. There is no need to willfully cut out the existing independent web, as in blogs, for a hipster indieweb movement.
I guess I'm still annoyed.