- 1 FAQ
- 1.1 Are Webmentions like Pingbacks
- 1.2 Do webmentions work only when both sites use webmentions?
- 1.3 How do you know if a website uses webmentions?
- 1.4 If I write an article that links to another article and both websites support webmentions, does it notify the other website automatically?
- 1.5 I am not a programmer, so if I want to set up webmention on a website is something like webmention.io the best way to set it up?
- 1.6 How do webmentions work with social media sites like Twitter?
- 2 Developer Questions
- 2.1 What is the canonical URL for the Webmention spec
- 2.2 Why webmention instead of pingback
- 2.3 Why webmention instead of Trackback
- 2.4 Which links should webmentions be sent to
- 2.5 Should webmentions be sent for links to static assets
- 2.6 Should webmentions be sent for embeds
- 2.7 Should webmentions be sent for removals
- 2.8 How does this solve the spam problem
- 2.9 POSSE or Send Webmentions First
- 2.10 Why is the target URL a required parameter
- 2.11 How does Webmention scale
- 2.12 What if multiple webmention endpoints are discovered
- 3 See Also
Are Webmentions like Pingbacks
Longer: No, Webmentions power existing user-centric features like comments, likes, notifications etc. across websites, while Pingback (perhaps unintentionally) created a new (and ugly) user-feature "Pingback" which was more confusing than helpful. Under the covers, Webmention is a much simpler, cleaner, and more secure protocol than Pingback despite having some structural similarities.
Do webmentions work only when both sites use webmentions?
Webmentions start working as soon as a site supports receiving webmentions (and, optionally, displaying them), and someone (anyone) sends them a webmention from another site that links to the receiving site.
Webmentions work better when the sending site both supports microformats2 and automatically sends webmentions. That is, when site A (the sender) publishes a post that links to site B (the receiver) which can receive webmentions, site A should automatically send a webmention to site B. This immediately notifies site B, which can then parse site A’s post for key information from its microformats (such as comment content, author name and icon. The receiver (site B) can then decide whether to display a comment (or other response) and how to present it.
Webmentions work best when both sites support microformats2 and also sending and receiving webmentions. With this in place, both sites can comment back and forth in real time, similar to social networks like Twitter.
Here are the minimum requirements for a webmention to work well:
- The sending website should mark up its response posts with microformats2
- The sending website should include a link to the receiving website.
- The receiving website should have a webmention endpoint (either its own endpoint or delegated to a hosted webmention receiving service like webmention.io).
- The sending website should automatically detect that endpoint and send the webmention.
How do you know if a website uses webmentions?
You can't know if a website sends webmentions, but you can find out if a website receives webmentions. This is done by looking for rel="webmention" attached to either an HTTP Link Header, an HTML link in the document head or on a hyperlink on the page. If any of those three items are found with a rel="webmention" attribute then the site has declared that it has an endpoint for receiving webmentions.
Webmention software does this automatically. As a quick practical check, in most browsers you can right click and choose
view source for the particular web page and then search for "webmention" to find something along the lines of <link rel="webmention" href="https://example.com/webmention" />. Some websites may also explicitly indicate they have webmention support with a badge or button, though actually searching for the endpoint as described above is more certain.
Idea: anor button to indicate this.
It depends on the webmention support in your (sending) website. Some sending websites have automatic webmention sending and others use services like Telegraph to send webmentions manually.
If your site supports automatic webmention sending, then there is nothing else you need to do. Unless you are using your own custom code, sites on micro.blog or Known and WordPress sites that use the Wordpress Webmention Plugin will automatically send webmentions.
It has become somewhat common for sites that accept incoming webmentions to have a URL box in their comments section to allow people whose own sites do send webmentions to manually input the URL of their response. The receiving site then checks the input to ensure that the page was indeed mentioned before accepting the webmention.
Keep in mind that many sites that do accept mentions do not necessarily display them, while others may moderate comments and webmentions before displaying them.
I am not a programmer, so if I want to set up webmention on a website is something like webmention.io the best way to set it up?
There are many ways in which this could potentially be done. It depends primarily on the CMS or system on which your website runs. Some projects have webmention sending and/or receiving built into them (eg: micro.blog and Known). Others, like WordPress, Perch, and Drupal, may have plugins or modules that make it quite easy to set up to send and receive webmentions.
Your best bet is to check the details and examples at Webmention or take a look at the page(s) related to your particular CMS. A list of supported publishing software is on the wiki. Some platforms will be easier or more difficult to set up depending on the software currently available. Some platforms may be better than others for using third party services like webmention.io.
If your particular platform doesn't support webmention technology, you could contact the developers and request support for it.
Most popular social media sites, like Twitter, don't support webmentions. To deal with the lack of webmention support, many people use the backfeed approach. Services like bridgy watch social media posts using their proprietary APIs. If you have syndicated a post from your site to Twitter (POSSE) and someone responds there, brid.gy will send a webmention from the silo back to your original post.
What is the canonical URL for the Webmention spec
Webmention is a W3C spec and lives at https://www.w3.org/TR/webmention/
Why webmention instead of pingback
Webmention is simpler & more reliable than Pingback, more thoroughly specified (e.g. explicit support for updates & deletes), and designed specifically to support rich social web interactions such as cross-site comments, likes, reposts, RSVPs, and more.
- Simpler. By dropping XML-RPC, webmention is simpler than Pingback. This means:
- Less work to implement
- Easier to test
- Both of which combine to enable more reliable, interoperable implementations, sooner.
- Re-using only HTTP enables easier testing and UI. By using only HTTP, it's possible to construct simple HTML forms that exercise the protocol, which is a good design principle for web protocols in general. This enables simpler/easier testing (with just a static HTML file), and the ability to provide simple (no JS needed) webmention submit forms on blog posts for others to paste URLs to their replies (some IndieWeb participants are already doing this, e.g. http://adactio.com/ and http://aaronparecki.com/ posts).
Why webmention instead of Trackback
- Trackback, lacking link verification, is more easily and heavily spammed
- Plus all the reasons why webmention instead of pingback
Which links in a post should webmentions be sent to?
Webmentions should be sent to all URLs a post can be considered to mention — this includes
What do existing implementations do?
- Telegraph - attempts to send webmentions to every URL in the parsed Microformats h-entry, including in-reply-to, photo URLs, as well as URLs in the HTML of the post content
- Waterpigs.co.uk - I send pingbacks (webmentions coming soon) to the in-reply-to URL if set, and all URLs in the post content field. --Waterpigs.co.uk 09:14, 10 April 2013 (PDT)
Should webmentions be sent for links to static asset URLs e.g. images, audio?
What do existing implementations do?
- Taproot sends webmentions to all URLs in a post without discriminating by type of link --Barnaby Walters 09:01, 26 November 2013 (PST)
- stapibas sends linkbacks to all URLs, independent of their type -- User:Cweiske.de
Should webmentions be sent for embeds
Should webmentions be sent for resources embedded in a post like the URLs in "src" and "data" attributes?
- <audio src>
- <embed src>
- <iframe src>
- <img src>
- <object data>
- <source src>
- <video src>
- ... others?
And what about "srcset"? Is anyone on the indieweb even bothering to publish with srcset?
What would the receiver of a webmention for an embed do with that notification?
Should webmentions be sent for removals
- If the source post is edited to remove a link to the target, should a webmention be sent to the target to inform them of the removal of the mention?
- [kartikprabhu.com] sends webmentions to links that are removed while editing an article.
- Do any implementations for receiving webmentions do anything with such a webmention POST?
- [kartikprabhu.com] deletes the existing mention-response from database, if it receives a mention where the source no longer links to target.
How does this solve the spam problem
How does this solve the spam problem that plagued Trackback and Pingback?
Pingback improved on this by making the "ping" only contain the URL of the comment, so that the link could be verified.
Webmention is a simplification of Pingback, so by itself does not provide any new anti-spam measures.
In practice, Webmention receivers look for specific h-entry markup to render comments, likes, reposts, and other responses, which all add a minor barrier (for now) for spammers above and beyond Pingback.
We expect that as Webmention grows in popularity, implementers will need to implement:
- The Vouch extension to Webmention
POSSE or Send Webmentions First
Should an indieweb publisher POSSE first, or send webmentions first?
It is better to POSSE a post first, and then send webmentions for all links in a post, for two reasons:
- Easier de-duplication at the receiver. By sending webmentions after POSSEing and adding
u-syndicationlinks on your post to the POSSE copies, the webmention receiver(s) will see those
u-syndicationlinks and be able to use them immediately to de-duplicate any proxy webmentions it may have received due to your POSSE copies. The opposite order is harder to de-dupe since it requires original-post-discovery which is more work than simply getting u-syndication links from parsing the h-entry.
- POSSE reply threading. When indie A replies to indie B and sends B a webmention, when B goes to reply back to A, if B's copy of A's post already knows the Ap POSSE copy, then B can immediately reply back both to A, and POSSE reply thread their Bp POSSE copy to Ap.
Reference: 2015-05-28 IRC discussion/background
Why is the target URL a required parameter
Technically, the "target" parameter does not add any semantics to the webmention request. Without the target parameter, the webmention request means essentially the same thing, which is indicating the source URL may be of interest to the webmention endpoint.
By including the "target" parameter in the webmention request, it makes verifying the webmention easier for the recipient, since they have an exact string to look for on the source page. With the target parameter, the receiver searches for an exact match. Without the target parameter, the receiver doesn't know exactly what to look for, and would have to look for any link matching the receiver's domain, adding complexity to the verification code.
Additionally, since the receiver also must follow redirects on the target URL, expecting the receiver to follow redirects for all URLs on a page is unreasonable. Having a single URL to follow is much simpler.
Since it's no extra burden on the sender to include the target parameter, and makes verification easier for the receiver, including the target parameter is required in the spec.
Also, a webmention endpoint may handle multiple possible target sites, as webmention.herokuapp.com does, for example, so can't make an a priori choice about which domain to check the source for links to.
Issue: "Possible" handling of multiple target sites is at best a feature of a Webmention endpoint. It is not documented or even expected in the current Webmention recommendation. -- 07:42, 26 July 2015 (PDT) Sarven Capadisli
- Similar to the reason we have a webmention endpoint in the first place (rather than having the URL handle webmentions itself), we prefer to design protocols that don't limit the implementation details. Having the ability for an endpoint to handle multiple domains is a good thing, and we should not design the protocol where that is impossible. Aaron Parecki 08:01, 26 July 2015 (PDT)
How does Webmention scale
Because it is peer-to-peer, Webmention scales naturally with the web, in contrast to centralized update methods such as pinging a central ping server which quickly gets overloaded, or having to consume a firehose of all updates (e.g. the twitter firehose) which becomes too big a burden.
What if multiple webmention endpoints are discovered
(or, what if I want people to send me webmentions to multiple endpoints)
Senders are expected to only send the webmention to the first endpoint they discover. This is to avoid a situation where a web page can advertise a large number of endpoints and require the sender make an unreasonable number of requests to deliver the webmentions.
If a receiver wants to use multiple webmention endpoints (for example, if one endpoint exists to send notifications, and another exists to archive the source documents, and another exists to collect a backup copy of comments), it should set up a single endpoint and forward a copy of incoming mentions to the other endpoints. In the real world, the only way a receiver can guarantee its multiple endpoints will receive mentions is if it sends them itself, since even if the spec says senders should send to all advertised endpoints, there is no way to guarantee the sender will actually do so.