Send webmention

[j23n]

Hello,

I'm looking for a way to send webmentions from a django project and would be happy to contribute such a feature to django-webmention.

Are there any thoughts/ideas that have gone into this already that you'd like me to take up / take into account?

Thanks!

[daneah]

Thanks for your interest @j23n!

Whereas receipt of webmentions felt very contained such that this project could be opinionated about handling that, sending webmentions feels much more open-ended by comparison.

I think the way this project could support sends is through a general purpose utility that, given a source URL, target URL, Reason enum, and optional timeout int would:

1. Discover the webmention endpoint by fetching the target (3.1.2)
2. Send an appropriate request type (POST for creating or updating and DELETE for removals) with the source and target, polling the status for up to timeout (milli?)seconds if specified until success/failure (3.1.3)
3. Return False (but True otherwise) upon:

• an error response from fetching target
• an error response from the request to the discovered webmention endpoint
• a confirmed failure to process the received webmention, if timeout specified
• an unconfirmed failure to process the received webmention within timeout, if specified

Alternate to the bool return value, the project could also provide a suite of exception classes corresponding to these outlined failure modes for the consumer to catch and handle how they deem fit.

This feels like it provides an integration into sending without prescribing or claiming to know how the triggers for sending might arise in any system. Some consumers may wish to manually send webmentions through the admin somehow, whereas some may integrate it into their blog publishing workflow in an automated fashion, etc. and opinionation there feels like it should be avoided.

[daneah]

Whoops, yep you're right about deletes! I think that obviates the need for Reason.

Will need to wrap my head around the suggestions about management commands and whatnot—I'm not opposed, just want to give sound guidance.

[daneah]

Ok so I think I agree that management commands and a signal handler are good pieces of the puzzle here. I'm trying to understand from your example whether discover_targets is something you're considering adding, and if that's just something that discovers URLs in a string? That seems fine, too, I think, but wanted to double check there.

[j23n]

That's correct, discover_targets just extracts links from a string - it's just there for completeness.

Thinking about this feature some more, one question I don't have a good answer to is where to put the network requests for endpoint discovery and webmention sending / status polling. Given a reasonable timeout for requests and a large number of targets to check, this could be quite time consuming.

Outside of introducing something like celery, I see two options where to put these:

• an admin action that is invoked by the user (the UX is going to be bad as this will just hang until completion with no easy way to show progress)
• a management command that is invoked by the user (requires the user to drop to the CLI)

The system could look like this:

1. SentWebMentions are created with state PENDING when (for example) a new Post is created / updated to avoid network requests in save() or post_save
2. the user can then filter PENDING webmentions and trigger discovery / sending in the admin
3. the user can poll the status / resend webmentions in the admin
4. a management command could expose that same parse / send / poll / resend functionality and have much better feedback for the user.

What do you think?

[daneah]

That's a good DX/UX assessment and I think I agree that, without introducing a worker management solution, it necessitates pushing it to an explicit initiated activity like those you mention. I think I like the system you describe, for that.

[j23n]

great! I'll stew on this some more and then put together a PR :-)