Add url property to manifest.json

[rndquu]

We need to know an exact plugin URL (in case it works as a cloudflare worker) in order to set it in the partner onboarding UI.

What should be done:

1. Add a new optional url property to manifest.json
2. Update the worker-deploy.yml workflow to set the url property in manifest.json on each deployment of the development branch. I think it's enough for now to use the development plugin instances + https://github.com/ubiquity-os/ubiquity-os-plugin-installer will simply have to fetch a default plugin's github branch in order to get a plugin URL.
3. Make sure all plugins from https://github.com/ubiquity-os-marketplace have the url property set in the manifest.json file and updated worker-deploy.yml workflow

Original comment

[rndquu]

@gentlementlegen Pls check the description

[gentlementlegen]

How do we deal with plugins that offers both Actions and Workers like the telegram chatroom?

[rndquu]

How do we deal with plugins that offers both Actions and Workers like the telegram chatroom?

I don't have much context on the telegram kernel but it seems the plugin architecture must be optimized if it requires both github action and a worker.

[Keyrxng]

How do we deal with plugins that offers both Actions and Workers like the telegram chatroom?

We could do: manifest.urls.action: ...

I don't have much context on the telegram kernel but it seems the plugin architecture must be optimized if it requires both github action and a worker.

It's split into worker/action because we needed a node env to run MTProto API to implement the chatroom feature.

It should be converted to a single worker plugin like it was originally now that 0x4007 decided to export the KERNEL_PRIVATE_KEY as an org secret,, so it can be simplified in the sense of it requiring only one config entry.

[rndquu]

@gentlementlegen I need you blessing on this task.

I think plugins that work both as a worker and a github action are outliers and it's safe to introduce the url property in the manifest.json file.

[gentlementlegen]

Sure, we only have one edge case so far. Maybe we can think of an option later like "install as Worker" and "install as Action". We can safely introduce the url property in the meantime.

[whilefoo]

We need to know an exact plugin URL (in case it works as a cloudflare worker) in order to set it in the partner onboarding UI.

How will the onboarding UI know if the plugin is a worker or action?
We could have https:// if it's a worker and github://ubiquity-os/marketplace@main if it's an action

We could also have urls property that would have 2 urls for hybrid plugins but that would also require changes in the kernel.

It's split into worker/action because we needed a node env to run MTProto API to implement the chatroom feature.

It should be converted to a single worker plugin like it was originally now that 0x4007 decided to export the KERNEL_PRIVATE_KEY as an org secret,, so it can be simplified in the sense of it requiring only one config entry.

Don't we still need node runtime for MTPRroto, so how can we convert to single worker plugin?

[rndquu]

How will the onboarding UI know if the plugin is a worker or action?

If the url property is present in the manifest.json file then it's a worker

Don't we still need node runtime for MTPRroto, so how can we convert to single worker plugin?

@Keyrxng knows better

[0x4007]

We need to know an exact plugin URL (in case it works as a cloudflare worker) in order to set it in the partner onboarding UI.

This is no longer the case so perhaps this can be closed as unplanned.

[rndquu]

We need to know an exact plugin URL (in case it works as a cloudflare worker) in order to set it in the partner onboarding UI.

This is no longer the case so perhaps this can be closed as unplanned.

How to get a plugin URL for a 3rd party plugin created by some other developer?

[0x4007]

I don't have full context on this repository but specifically in the plugin installer UI I fixed this problem.

[gentlementlegen]

The problem is that the plugin installer cannot guess the URL to put it in the configuration which is the problem. It only knows the GitHub repository. One workaround would be if we had deployment urls linked within the github repo we could use these.