I need to work on integrating Webmentions with my website more. Mainly to see who's replying to me (I have to check manually—which is okay because it prevents the “notification jitters”) but to also help with contextualization of content.

Spent the morning after a bit of reading to hash out the new idea I had for Webmention storage. In an attempt to stick to using the filesystem as a form of truth, I'll be writing out to a index.txt that'll have the URL and relationship type of the Webmention as it stands. That way, if I ever need to, I can use that list to refresh all the relationship from a backup if the database was missing. I'm thinking about adding another field to represent the relative path on disk to a serialized representation of the Webmention, but for now, it'll be (hopefully) expanded when it's added to the MF2 property.

I'm excited for all of these changes to work across the temporary destination storage approach—people would be able to get this full Micropub experience with little commitment or sync it to Dropbox or the ilk to have file backups and edit things in real time. I think allowing for two-way sync (editing a file triggers an update in the database) would be a nice thing to have in the future and would allow for scripting (generating a bunch of files for entries that are backfed from an archive that can then be imported into the database). To be honest, if I continue to treat the database as mainly a caching and indexing layer over the filesystem, then it doesn't seem odd to have a “duplicate” write of everything (to SQLite and the filesystem). I just don't want it to result in duplication of storage.

Few quick thoughts from first read, will try to give more detailed feedback later.


Header


X-Webmention-Status



Obligatory reference to RFC6648


status codes


How does 401 happen? 201 wouldn't appear in a callback, would it (since it basically says "nothing happened yet to send you callback about")?


rel-values


Using rel="status webmention-status" in my headers and HTML to allow for the discovery of the Webmention status page



Where would you place those? Not entirely clear to me. I.e. in the response to which request?


↑ bysknebel • posted • archived copy • current

The headers would appear in the response to an outgoing Webmention and in the HTML status page of a Webmention (so tools can use that for programmatically obtaining the status if callbacks aren't supported or it hasn't been called back after a period of time).

Few quick thoughts from first read, will try to give more detailed feedback later.


Header


X-Webmention-Status



Obligatory reference to RFC6648


status codes


How does 401 happen? 201 wouldn't appear in a callback, would it (since it basically says "nothing happened yet to send you callback about")?


rel-values


Using rel="status webmention-status" in my headers and HTML to allow for the discovery of the Webmention status page



Where would you place those? Not entirely clear to me. I.e. in the response to which request?


↑ bysknebel • posted • archived copy • current

TIL about RFC6648!

A 401 would happen if someone attempted to receive a private Webmention, but the credentials they've received were incorrect (like the code expiring too soon). I would show a 201 in a callback response only if we'd detected an asynchronous Webmention endpoint from the provided parameters, and this would signal that they haven't called us back yet. They could never call us back—which, for me, is okay, and I can treat that as a 200 after a period of time.

Defining the Base Parameters for a Webmention Callback Payload

I'm looking for the minimal viable set of fields that should be expected when receiving a Webmention callback. This is specifically when a callback has been sent during an outgoing Webmention request. The fields I've seen used so far were source, target and status using the values from the HTTP status code.

What I think about doing is the following:

  • Using `X-Webmention-Status` to highlight the current status of the Webmention.
  • Using rel="status webmention-status" in my headers and HTML to allow for the discovery of the Webmention status page
  • Providing a link relation for the Webmention status page that's rendered in JSON and uses the same fields expected when informing a callback URL of the status of a Webmention to allow for pulling of that information.
  • Using the fields as the body for a JSON form of the status page

The body would look like:

POST /webmention/callback
Host: lighthouse.example

{
   "source": "http://source.example",
   "target": "http://target.example",
   "vouch": ["http://v1.com"],
   "status": 200
}

200 OK

Thinking about using the following status codes:

  • 200: Completely processed and capable of being presented. This SHOULD not take into account things like visibility, moderation, and audience controlling.
  • 201: Validating and potentially in a queue to be processed.
  • 400: Invalid request.
  • 401: Needs authentication.
  • 429: The parameters were good, but the request couldn't complete (invalid vouch, URL not allowed to take in Webmentions, no target found in source, etc.)

References

I've been spending about an hour a day or so working on my side projects. Right now, I got some great logic going for Lighthouse to take in and send Webmentions. But I just need an interface for it. I'm also working on serializing the tests described at webmention.rocks into the Rust library for IndieWeb, so I can be assured that anything using is compliant. I've also added some 'extension'-like logic, so it can support private Webmentions and Vouch (to a degree, I want to add some logic for handling Vouch resolution). With Lighthouse, I want to make it as simple as providing your RSS or Atom feed to Lighthouse and going from there - Webmentions should be automatically sent. Receiving them would be just adding a line of HTML to your site. I'm thinking about sneaking in a link that represents the endpoint but, when rendered as HTML on request, provide a form to submit Webmentions. And a tool to detect if a site supports Webmentions.

I think that what quote tweeting definitely missed was a concept of consent. Like, there isn't a way to opt out (or let alone say that you've consented to this mention in a remote document). I think that there is a way to have this be done using Webmentions and without having a need for a thundering herd. This would slightly expand a Webmention service to validate if a Webmention exists for a provided pair and if it's been consented to. Having this be available from the public side could allow clients a more pull-based checking approach that can be disassociated from one's site and be determined quickly. That way, you can specifically opt out from being mentioned or at least hint that you've chosen not to.