Send a Webmention when a reply lands on a post that links home - #23
Open
courtneyr-dev wants to merge 1 commit into
Open
Send a Webmention when a reply lands on a post that links home#23courtneyr-dev wants to merge 1 commit into
courtneyr-dev wants to merge 1 commit into
Conversation
Posts that start life outside rss.chat -- a WordPress permalink, say -- can now carry that page in the item's link field: /newpost and /updatepost accept link (absolute http/https only), storing it in the column the feeds already emit. Only the write path was dropping it. When a reply arrives for an item whose link points at an external page, the server tells that page with a Webmention: discover the endpoint (Link header first, then a rel scan of the page, capped at 512K), then POST source and target. Update re-sends, which is how Webmention spells "edited"; delete re-sends too, and the source now answers 410, which is how receivers learn the reply is gone. The source is a new server-rendered page, /item?id=N: the item as a real HTML h-entry -- author, date, content, canonical guid, and for replies a u-in-reply-to link to the parent's page. That's the page a receiver fetches to verify the mention, and it doubles as the item for readers without the client app. Deleted items answer 410 there. Item links are written by whoever posts the item, so the sender refuses targets on localhost and private ranges. Two config switches, neither required: flWebmentionNotify (on by default) turns sending off; flWebmentionAllowPrivateTargets exists for single-machine test rigs and should stay off anywhere real. Verified end to end against a WordPress running the Webmention plugin: reply created a verified webmention comment, re-sending updated it in place, and a source with no target link was rejected at verification. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
This closes a loop for posts that start life on a blog. My WordPress site pushes posts into rss.chat through pfefferle's plugin; people reply here; today the blog only finds out by polling. With this change the server tells the post's home page directly, using Webmention, the W3C protocol WordPress, Micro.blog, and the IndieWeb already speak.
Three pieces, all additive:
/newpostand/updatepostacceptlink— the post's canonical page somewhere else, a WordPress permalink say. Theitemstable, the item record, and the feeds already carrylink; only the write path was dropping it. Absolute http/https only, anything else quietly ignored./item?id=N: the item as real HTML marked up as an h-entry — author, date, content, canonical guid, and for replies a link to the parent's page. It's the page a Webmention receiver fetches to verify the mention, and it doubles as the item for readers without the app. Deleted items answer 410 there. The existing?id=Nclient page is untouched.linkpoints at an external page, the server discovers that page's webmention endpoint (Link header first, then a rel scan) and POSTs source and target. Edit re-sends, which is how Webmention spells "updated"; delete re-sends too, and the 410 tells the receiver the reply is gone.Because item links are written by whoever posts, the sender refuses targets on localhost and private address ranges. Two config switches, neither required:
flWebmentionNotify(on by default) turns sending off;flWebmentionAllowPrivateTargetsexists for single-machine test rigs. Docs updated in api.md and config.md.Verified end to end on a local SQLite server against a WordPress running the Webmention plugin: a reply produced a verified webmention comment on the original post, re-sending updated it in place, and a source with no target link was rejected at verification, which is the protocol working as designed.
Happy to split or reshape this however you'd prefer.
🤖 Generated with Claude Code