ubiquity-os / ubiquity-os-kernel

1 stars 13 forks source link

Standardized webhook processors/interfaces for any service #37

Open 0x4007 opened 5 months ago

0x4007 commented 5 months ago

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 commented 4 months ago

@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.