Self dispatched workflow functions

[Keyrxng]

Now that the kernel' APP_ID and APP_PRIVATE_KEY have been exposed as org secrets I think I should go back to my original implementation where the worker for this plugin controlled the dispatching of it's own workflows for MTProto API (workrooms, etc...) features.

• with two config entries ubiquity-os kernel is dispatching tons of workflows for no reason which can be avoided
• self-dispatched means we can validate no-op payloads first
• it's cleaner and more efficient from a plugin standpoint
• removes the need for two entries in the config
• optimizes the github rate limit consumed by this plugin
• it's no longer considered "unsafe" to do so or the secrets wouldn't be exposed

[ubiquity-os-beta]

Note

The following contributors may be suitable for this task:

Keyrxng

76% Match ubiquity-os-marketplace/ubiquity-os-kernel-telegram#13

[0x4007]

This will need a time estimate as well.

[Keyrxng]

I cant assign labels

Probs about a day to rewrite and test everything is working again

[Keyrxng]

@0x4007 I'm not free today to carry out work but will be over the next day or two as a heads up

Thanks for labeling for me.

[whilefoo]

A plugin should ideally not dispatch workflows on the behalf of the kernel as that is the job of the kernel. Can't we move everything to the workflow?

[Keyrxng]

Not as far as I'm aware @whilefoo no.

We need to set a delivery url for our BotFather bot updates and so we use our CF worker domain. What would we set it to if using actions? Afaik that's not possible but I'm no expert.

---

I see recent discussion regarding "hybrids" and plugins being able to self-dispatch in another task.

I don't feel the kernel needs to gatekeep the ability to dispatch workflows as it has other important jobs too but actually it's an improvement if plugins can self-dispatch for many reasons:

1. Worker as P.O.E means we can detect no-op payloads and optimize our rate limit usage which seems to have been a problem as of recent.
2. We have both instant and long-running capabilities for plugins.
3. With Tail Workers we could setup a decent redundancy system for all worker/hybrid plugins.

So if the kernel handles handshakes properly and the plugins are reviewed that self-dispatch and/or leverage APP_ID and APP_PRIVATE_KEY then it's safe, no?