Open muety opened 4 years ago
Not to be confused with the recently added webmentionio_webhook
inlet. Webmention.io is a service that may act as a gateway. It receives Webmention requests from people's websites and, if configured so, forwards them to a webhook, which might well be the middleman bot. The service allows to configure a secret
to be included in the webhook request, which can be perfectly used to transmit the recipient token.
In comparison, the purpose of this present feature is to be able to get rid of Webmention.io and have the middleman bot receive Webmention requests directly.
Middleman bot should be able to act as a receiver for Webmentions. That is, it should be able to process an
x-www-form-urlencdoded
POST
request like the following, send out a notification and return202
.Request Example:
The only problem here is that the Webmention request performed by its
sender
will not contain any information about the Telegram recipient, i.e. there is no way to transmit arecipient_token
and therefore no way to route the notification to a registered user.Proposal: Introduce a way to configure the bot using commands, including the ability to set inlet-specific parameters. E.g. a new
/config
command might be introduced that requires two arguments, corresponding to key and value. These key-value pairs are persisted at the server and used for any kind of configuration – in this case for routing Webmention notifications. Specifically, a Middleman user might "subscribe" herself to incoming Webmentions for a certain domain:/config inlet.webmentions.subscription "alice.com"
. This will tell the bot to notify Alice about a new Webmention containing any URL under "alice.com" as atarget
.One problem with the above proposal is that it doesn't feature any type of authorization. If you are Alice, hosting a middleman instance with multiple users, any of those users could practically subscribe to your Webmentions. I'd consider that acceptable for now, but if anyone comes up with a better approach, please let me know!