Standardized webhook processors/interfaces for any service

[0x4007]

It would be interesting to start research on supporting Telegram webhooks and Google Drive webhooks.

I'm not sure if it's possible for us to have separate plugins listen for webhooks, that way we can keep the kernel super lean.

Google Drive

https://developers.google.com/drive/api/guides/push

For Ubiquity DAO, GitHub houses 95% of the r&d teams work, but for contributors outside of product, a lot of their work is on Google Drive.

It would be fantastic to develop more plugins that can offer rewards for contributions in Google Docs, Sheets etc. Perhaps eventually an email plugin as well.

Scope

I want to standardize I/O interfaces for webhook "processors" (not sure what to call them) where we can make unit tests and have open priced tasks for anybody to implement. This way we can scale up integration efforts rapidly (almost like a zapier!) for the bot to listen to events from various platforms. It would also be ideal to have separate codebases/plugins.

Let's post research here and create tasks from those research efforts.

[gentlementlegen]

@0x4007 I think we can start by creating some @ubiquibot/kernel package that would expose the PluginInputs that are send to every plugin. This would be to avoid having each and every plugin redefining the type, as if it changes inside the kernel it will break all the plugins linked to it, and would also avoid duplicating code. There is a first implementation inside the assistive-pricing plugin here that could be reused.

So later on we would just do something like

import { PluginInputs } from "@ubiquibot/kernel"

directly in the plugins.

Likewise, we could define a return type that the kernel understands, the same way.

[0x4007]

It seems like the solution is to create "microkernels" which handle their own services. For example, we have a Telegram microkernel implementation in the works at ubiquity-os-marketplace/ubiquity-os-kernel-telegram#2

This microkernel receives events in a Cloudflare Worker, and routes them to a GitHub Action for longer running processes. This, like our main kernel, routes requests elsewhere based on what type of event it is.

This type of architecture seems to scale for all of our needs across all platforms. We can make a Google Drive microkernel, which some sort of Google Drive "app" would need to relay all webhook events to.