Use CloudEvents for enabling event-driven notifications including cross-posting.
clemensv opened this issue · comments
The skeleton of the old Pingpack/Trackback/Crosspost logic is all still there, but that the workers are gone or have been commented out. Given that this is all old-style stuff, that's very reasonable.
I propose we replace all of that by a set of CloudEvents that are raised when the post collection or posts change state, and an API that allows pulling the post details and especially the full content as JSON or XML. We might put that underneath the RSS feed so that you can drill straight into the RSS items. We'd label all RSS with an id="{guid}" attribute to make the relation obvious.
- Post Added Event - Raised when a post had been added
type:dasblog.post.addedsource:https://example.com[/path]/feed/rsssubject:https://example.com[/{path]/feed/rss/b45fc16c-2e72-4d7e-a0c1-394e0875b556data: JSON containing all metadata but not the actual content due to size.- 'tags' (extension): the full list of tags/categories associated with the post
- Post Changed Event - Raised when a post has been changed
type:dasblog.post.changedsource:https://example.com[/path]/feed/rsssubject:https://example.com[/{path]/feed/rss/b45fc16c-2e72-4d7e-a0c1-394e0875b556data: JSON containing all metadata but not the actual content due to size.- 'tags' (extension): the full list of tags/categories associated with the post
- Post Deleted Event - Raised when a post has been deleted
type:dasblog.post.deletedsource:https://example.com[/path]/feed/rsssubject:https://example.com[/{path]/feed/rss/b45fc16c-2e72-4d7e-a0c1-394e0875b556data: JSON containing all metadata but not the actual content due to size.- 'tags' (extension): the full list of tags/categories associated with the post, including extras (see #670) not embedded in the content.
id, time are required on all events.
The ..../rss/{guid} endpoint will return the full content even if that might be enormously long and if the RSS feed itself may thus choose to truncate it.
The CloudEvents are posted to a configurable HTTP endpoint using CloudEvents JSON structured format leveraging the CloudEvents WebHook convention.
For authorization, the site security config should include configuring an API key or API token either as a header-name/value pair or a query-parameter/value pair. While the webhook spec mandates some mechanisms, it's safer to assume that some targets may use different headers/parameters for passing keys and tokens.
The tags attribute is an extension that allows subscribers to filter events by the presence of certain tags. An event subscriber that forwards posts to mastodon might look for a particular tag like #social or even #mastodon and only be interested in posts that contain it.
All cross-posting and integration with foreign APIs could then be externalized to a service that knows how to handle them. That CloudEvent handler and dispatcher might quite well be co-hosted with dasBlog and does not need to be some cloud service.
Personally, I will hook that up to Azure Event Grid and then write a few Azure Functions that know how to talk to Twitter and Mastodon and maybe some other sites and probably host those in the same plan as the site.