## My webmention endpoint wish list

While it has some rough edges, the Webmention protocol has a lot going for it. One of the nice things about it is that it’s easy to add support via a third-party endpoint, such as webmention.io, which is what I (and many others) use.

There’s a few things I wish were better, though, and I think these can all be addressed by the endpoint itself, while remaining within the specification as it’s written today. I would be tempted to write an endpoint that works this way, if I weren’t already overwhelmed with other projects.

1. Definitely support the webmention.io API. There’s a lot of folks already using that to retrieve mentions to display them on their site, and I see no reason for that to change.

2. Having some form of moderation would be nice. Mentions at their core should be kept perpetually but with a disposition of accept/reject/pending, and domains should also have a default disposition (which defaults to pending). When a new webmention comes in, it should get the domain’s default disposition (along with an unmoderated flag), and then when moderating them, the user should be able to change the default disposition for the domain.

3. Mentions should be periodically refreshed to see if they’re still valid. The refresh interval can be some form of slow exponential growth, like the Fibonacci sequence or something. Whenever the status of the mention changes, that should reset the refresh interval. Mentions which have disappeared should not be rendered while they’re invalid, and the moderation queue should also show a section for “approved but disappeared” mentions.

4. When a mention is sent or refreshed, it should also get a source and destination pointer; track the mention in terms of the original URLs provided, but they should be displayed and fetched based on what their current URL is, after chasing redirections or the like.

5. Relatedly, multiple incoming mentions should be consolidated based on what their source and destination URLs resolve to. For example, if Alice pings Bob from http://alice.example.com/1/first-entryhttps://bob.example.org/blog/hello.html, and then Alice’s URL updates to https://alice.example.com/blog/1/First-Entry, if Alice’s site re-sends backfill pings, the endpoint should only report a single ping that comes from https://alice.example.com/blog/1/First-Entry. Likewise, if Bob’s URL changes to https://bob.example.org/weblog/hello, when Bob’s site retrieves mentions for the new URL it should also include mentions that went to the old URL.

Obviously for this case there will be a period of time between a site’s URLs changing and the original pings being refreshed, but maybe a new mention to an older target can also trigger a refresh of existing mentions to see if they’re subject to consolidation.

Also the consolidation should only happen at the retrieval level; the original source/destination URLs should always be preserved, since it’s always possible for an old URL to become unique again.

6. There should also be some automatic consolidation of pings that have the same URL aside from the scheme; webmention.js handles this on the rendering end but it’d be nice if the endpoint could do this automatically. For example, if a ping comes in from both http://example.com/12345 and https://example.com/12345, they should be consolidated to both have come from the https: version, probably. It would also probably make sense to do some sort of intelligent auto-consolidation based on domain aliases, like www.example.com vs. example.com. (8/28/2019 update: Or use <link rel="canonical">.)

7. Support for private webmention.

8. Support for Vouch, both from a validation perspective and providing UX to make it easier for folks to present their whitelist (like maybe when a domain is whitelisted it can also be added to a vouch list).

9. Also maybe some form of conversation threading would be nice? I’m not sure how that could be reasonably implemented (aside from supporting Salmention and hoping others come along with that) but it’d do a lot to address the UX problems with Webmention as a conversational platform.

## Some WebSub-Atom observations

As part of testing my WebSub changes for FoF, I decided to switch to a WebSub hub for myself that provides some subscriber analytics and so on. One neat thing about how WebSub works is that the “hub” layer is completely modular and it really doesn’t matter at all which one you use, and if the one you use has problems you can switch to another one just by changing the URL in your feed and all subscribers will eventually seamlessly migrate (at their next normal polling interval); if anyone even notices a problem it will just be that they don’t receive a push update during that polling interval. (Which, let’s be honest, is incredibly unlikely for most RSS feeds.)

Anyway, because of these new analytics, as well as information I gathered from my new WebSub-supporting reader, I now know a bit more about the state of WebSub.