Support Webmentions

[dshanske]

Webmention is now a W3C Recommendation as of January 12, 2017. ​https://www.w3.org/TR/webmention/ . Previous linkback protocols(trackback and pingback) did not achieve this status.

The Webmention is a simplified evolution of the Pingback. It drops XML-RPC in favor of simple form encoding. The recommendation calls for asynchronous processing to prevent DoS attacks.

There is already a webmention plugin for WordPress in the repository. ​https://wordpress.org/plugins/webmention/ and this could be used as a basis for a feature plugin to merge into core.

Trackbacks and Pingbacks both have their unique problems. The idea of linkbacks in general remains a good one, spoiled by less robust implementations. To go to the logical extreme, suggesting that adoption of webmentions be concurrent with the disabling by default of the earlier and less secure protocols.

Finally, no feature should be adopted in WordPress unless it has users...the pingback implementation in WordPress displays pingbacks in a way that does not convey useful meaning.

Current implementations of Webmention parse the HTML to generate a comment or other richer forms of response that are more useful to a site than what is currently available. The proof of concept for this is in the Semantic Linkbacks plugin ​https://wordpress.org/plugins/semantic-linkbacks .

[dshanske]

Part of the big problem with implementing per the spec is the asynchronous processing by the receiver, however without it, you lose some of the advantages. This needs to be very carefully thought out to avoid it becoming a liability.

This is what I have so far trying to break the specification down. A webmention is sent to the endpoint...

1. The receiver checks if they are valid URLs and that the target is something accepting webmentions.
2. A comment is created with a new status(let's call it queued or pending, names don't matter) and comment type webmention. This status does not trigger the traditional spam checks. It would return notice of the queue to the sender with a URL to check status.
3. A wp-cron job processes the pending webmentions. The job would then...
4. Check for previous webmentions with the same source and target. If multiple webmentions, that is probably indicative of a flood.
5. If there is an existing webmention with same source and target, call a function to update the existing webmention. Otherwise, create a new webmention.
6. Regardless, retrieve the source document, imposing a maximum size and timeout limitation to prevent exploits, verify the source document links to the target URL.
7. If there isn't a match, the update function would delete the existing webmention. If there is no existing webmention, it should be classified as spam so it could be used appropriately.
8. If there is a match, the webmention would be parsed(separate issue), a complete webmention would be run through the traditional spam checks and plugin hooks, and posted or not as the case may be.

There are opportunities to break this into pieces to make it more manageable. But there is no specific urgency for a webmention to be displayed immediately upon its receipt. The queue could process it 2 seconds later, or 5 minutes later.

[johnbillion]

#40031 was marked as a duplicate.