15+ years later, we will try to standardize something that's barely used anymore
> This is a similar "Linkback" mechanism to the ones of Refback, Trackback, and Pingback. It uses a different protocol, though, and thus should be discoverable through its own link relation type.
Pingbacks, during the WordPress glory era, where killed by spam. Everything that is unauthenticated or weakly authenticated messaging without centralised censors will turn to a spam channel. How do new protocols avoid this?
At minimum Webmention requires the originating site to be hosting content that actually references the mentioned page.
Spammers would then have to host the location where the spam is located, and then you can block them.
But, frankly, this isn't actually a solved problem yet. I'd imagine building a spam blocking engine on top of a service like webmention.io is an obvious next step if/when this becomes an issue.
When I heard about indieweb I implemented h-entry stuff for my blog but half-way through doing webmentions I realized it sucked.
Webmentions requires receiving x-www-form-urlencoded data. Why they chose this convoluted and complexity increasing way is beyond me. Embedding (or encoding) it in the URL string itself would've been infinitely easier for everyone with no downsides. But no, with x-www-form-urlencoded variables you need to actually be doing some dynamic scripting to handle it. If not actually some script listening for that location/endpoint then at least a series of complex nginx directives and modules to get x-www-form-urlencoded logged with all the rest of the request. This additional complexity makes running a static website that supports indieweb standards like a tail wagging the dog in terms of the webmentions receiver's relation to the static http site.
microformats2 h-entry markup is cool though. Just using class names for html elements to make some info parsing "standardized".
The kind of people that care about indieweb are exactly the kind of people running self hosted static websites with blogs. Few on blogspot or wordpress are going to care.
Anyway, how did you manage to receive webmentions and set up an enpoint? Are you passing it off to some dynamic scripting language to handle?
If that's true then the whole exercise is pointless (which, I guess, is a valid claim).
WordPress dominates the blogging world. Jekyll, Hugo, etc, are drops in the bucket by comparison. Winning that market over is absolutely required if Webmention is gonna gain any level of adoption.
Sorry, I updated my post with a bit of implementation detail.
http://webmention.io, which is a standard web service running separately from the blog itself, receives webmentions for me (it's a hosted service, though you can also self-host).
A Jekyll plugin pulls them down on site build, which I run periodically on a schedule.
Ah, thanks. But that kind of proves my point re: webmentions. The whole indieweb thing is suppose to be independent. Webmention's implementation complexity pushes people back to third party centralized services, or, vastly increased attack surface and maintenance on their own setup.
It's not so much not running a service as not running any more services that are receiving connections of any kind from the 'net. I trust nginx. I don't trust some webmentions specific script or program.
I implemented my website's (see profile) comment system based on a tiny perl script that tails the logs from my webserver. It's completely separate and no internet user is connecting to it. Any URL, followed by the string "/@say/" like, "http://what.ever/something.html/@say/Neat something" is added to the comment page.
What you've done is made the webserver a blanket endpoint, where the "API" and the "database" are your web server log files.
Practically speaking, what you have is a CGI script with a non-standard interface to the server. It's still subject to any bugs in your perl script, since you're still processing input from an untrusted location.
One of the promoted examples on the indieweb site for webmentions is sending webmentions manually with curl. But since it's form encoded you'll never know what the values were when you look in the logs. If it was just a URL string then you could do the entire thing manually with cURL. You'd have to agree this would be a distinction with a difference.
Receiving a simple post request is something you can run any any PaaS free tier, on any webspace with PHP or other scripting, ... You can run that on completely independent hosting from your main website if you wish (which is why the services suggested are even possible)
If it were URL parameters you'd have them in your webserver log, but you'd still need dynamic code parsing that log for anything more advanced than "have a record of the mention somewhere".
Using a hosted service like webmention.herokuapp.com webmention.io or mention.tech is an option for a static site, or running your own instance of one of these (they're all open source).
You point the rel=webmention at the service, and then show the webmentions client side with js.
Webmention.herokuapp.com example at kevinmarks.com
Mention.tech example at tumblelog.xyz
23 comments
[ 2.8 ms ] story [ 57.1 ms ] threadhttp://microformats.org/
And micropub:
https://indieweb.org/Micropub
Webmention + microformats + micropub = distributed social comments, likes, reshares, etc, with blogs.
> This is a similar "Linkback" mechanism to the ones of Refback, Trackback, and Pingback. It uses a different protocol, though, and thus should be discoverable through its own link relation type.
Spammers would then have to host the location where the spam is located, and then you can block them.
But, frankly, this isn't actually a solved problem yet. I'd imagine building a spam blocking engine on top of a service like webmention.io is an obvious next step if/when this becomes an issue.
Webmentions requires receiving x-www-form-urlencoded data. Why they chose this convoluted and complexity increasing way is beyond me. Embedding (or encoding) it in the URL string itself would've been infinitely easier for everyone with no downsides. But no, with x-www-form-urlencoded variables you need to actually be doing some dynamic scripting to handle it. If not actually some script listening for that location/endpoint then at least a series of complex nginx directives and modules to get x-www-form-urlencoded logged with all the rest of the request. This additional complexity makes running a static website that supports indieweb standards like a tail wagging the dog in terms of the webmentions receiver's relation to the static http site.
microformats2 h-entry markup is cool though. Just using class names for html elements to make some info parsing "standardized".
Yeah, it's a bit annoying having to integrate with a web service, but it's not that big of a deal.
And bluntly: most people running blogs aren't using a static site generator, anyway, so it really doesn't matter that much.
Anyway, how did you manage to receive webmentions and set up an enpoint? Are you passing it off to some dynamic scripting language to handle?
WordPress dominates the blogging world. Jekyll, Hugo, etc, are drops in the bucket by comparison. Winning that market over is absolutely required if Webmention is gonna gain any level of adoption.
http://webmention.io, which is a standard web service running separately from the blog itself, receives webmentions for me (it's a hosted service, though you can also self-host).
A Jekyll plugin pulls them down on site build, which I run periodically on a schedule.
I'm just too lazy to bother.
This is gonna be the case no matter how the content is passed in the request (I.e. url vs form encoding).
It's dynamic content.
What is your proposed solution for supporting dynamic content on a static site that doesn't involve running some kind of service on the side?
I implemented my website's (see profile) comment system based on a tiny perl script that tails the logs from my webserver. It's completely separate and no internet user is connecting to it. Any URL, followed by the string "/@say/" like, "http://what.ever/something.html/@say/Neat something" is added to the comment page.
What you've done is made the webserver a blanket endpoint, where the "API" and the "database" are your web server log files.
Practically speaking, what you have is a CGI script with a non-standard interface to the server. It's still subject to any bugs in your perl script, since you're still processing input from an untrusted location.
It's certainly clever, though!
If it were URL parameters you'd have them in your webserver log, but you'd still need dynamic code parsing that log for anything more advanced than "have a record of the mention somewhere".
How would you receive webmentions on one of these? It's two variables submitted as a POST as x-www-form-urlencoded data.