nekr0z/static-webmentions

a tool to send webmentions from a static website

static-webmentions's Issues

Fails Webmention.Rocks Discovery Test #15

Webmention.Rocks Discovery Test #15 is failed due to an upstream library bug. It has been fixed upstream, so it's only the matter of updating the dependency now.

Webmentions are not sent to the old targets when they disappear

Per spec:

If the source URL was updated, the sender SHOULD re-send any previously sent Webmentions, (including re-sending a Webmention to a URL that may have been removed from the document), and SHOULD send Webmentions for any new links that appear at the URL.

We do process the updated pages, and we do send webmentions for new links and re-send them for existing links, but we only look for the old links when processing pages with http-equiv set as 410 (denoting that the whole page has been deleted).

We need to always process the old version of the page and account for the removed links.

Finer-grained inclusion/exclusion when gathering webmentions

Problem

Loving static-webmentions so far, but better exclusion mechanisms would be helpful:

• I add Webmentions to my website at build-time, and label their links with rel=nofollow. If I send webmentions to these webmentions, we could end up with a feedback loop.
• My <footer> has links that are included in every page. Currently, I manually add the links in my footers to the exclude list in config.toml, but I might eventually add links that change (like a link to the latest git commit displayed by my preferred git forge).

Proposed solutions

Two possible solutions that are not mutually exclusive:

Solution 1: exclusions

• Exclude links with rel="nofollow" or rel="ucg".
• Exclude children of certain tags (e.g., <footer> or <section class="webmentions">

Solution 2: finer-grained inclusions

Currently, static-webmentions extracts the content of .h-entry. If it only extracts .e-content when it's present, then it will only gather pending webmentions from links in the article text.

If you have a preferred solution, I could implement it this weekend.

Multi-threading is not used

Obvious areas that could benefit from multi-threading would be:

• simultaneous processing of several files (with a setting to specify a number, defaulting to 1, perhaps);
• simultaneous sending of several webmentions (with a setting to specify a number per domain or, even better, per endpoint, defaulting to 1, perhaps).

Fails Webmention.Rocks Discovery Test #23

Webmention.Rocks Discovery Test #23 gets failed due to an upstream library bug.