Anyone wants a Zoraxy Plugin System?

[tobychui]

Hi everyone, I am currently designing a plugin system but has been stuck here for weeks. I need some inputs on how should I design a plugin system for Zoraxy. Currently I have these two ideas in mind.

Design 1

Plugin itself is a HTTP server which expose a set of specified endpoint for Zoraxy to forward requests to.

Pros

• Easy development, plugin developer can just use the native golang net/http server or even any language they want to develop the plugin, as soon as the RESTFUL API endpoints are correct, it is all good
• High speed, as it is all HTTP and do not require restructuring / reformatting of the request
• Lower level of vendor lock-in, if the plugin developer decided that he want to split it off from Zoraxy, he can easily do that by changing a few lines of code that interface with the http server
• Commercial friendly, as it is a separated part of the system that do not cover by the Zoraxy AGPL

Cons

• Platform dependent binary, just like the Zoraxy binary, each platform will require their own release version or depends on some runtime like python / npm
• Potentially dangerous, as Zoraxy need to be run as root, if the plugin is not open source, there might be potential danger in executing a third party prepackaged binary
• Harder to distribute, as you will need to ship the whole binary / wrapped in some kind of binary runtime environment like py2exe that would use up quite a lot of space

Design 2

Plugin execute within Zoraxy as a virtual machine, something like greesemonkey (the browser plugin that execute JavaScript), and Zoraxy provide a basic HTTP agent and sandbox file system for requesting external resources from the VM

Pros

• Safe, as everything run in a VM / sandbox environment
• Easy to install and distribute, just copy the script and paste in Zoraxy
• Less messy standards, as everyone will only use one intereted language (JavaScript / Lua / something else?)

Cons

• Slow, as it is run inside a VM and require real-time interpretation
• Non-standard interfaces, plugin devs will need to learn new functions and how to interact with Zoraxy instead of just following standard RESTFUL API specifications
• Not that commercial friendly, as according to AGPL, if your work require another pieces of AGPL code to work, it will be included as part of a AGPL project

Side Notes

Yes, I do know there are other implementations like the native Go plugin system (which only support linux and not quite well maintained) and similar implementations in gRPC. But since most users (and developers using Zoraxy, probably) are beginners in networking / programming, I want to make it as simple as possible to develop and use a plugin in Zoraxy. Looking forward to read all your comments and ideas :)

[fow0ryl]

I'm a home user only. So my thoughts are not from a developers perspective and may be confusing for you ...
Most of my services at home are running in dedicated Containers (LXC) on Proxmox. I.e. CUPS Printserver, Homegear, FreiFunk Offloader, Wireguard, EVCC, Nextcloud, Signal MessageBot, Linux Box with XRDP Server, .... Some other like win10, homeassistant are running as VM's on same Proxmox environment.
Zoraxy is running as a LXC container too. I'm using zoraxy http-proxy functions only. So I need very little ressources only (1 CPU / 1GB RAM).

Basically, I think ​​implementing a plugin system is a good idea.
For example, notifications could be sent via webhook plugin, SMTP plugin or whatever, depending on the user's wishes.

Reading Design-2 makes me sit up and take notice. Really? A new VM inside a container?
I don't think that's a good idea. Regardless of whether you use Proxmox, Docker or whatever.

Because of the safety concerns in Design-1
I'm running zoraxy as non root user (since today) and did not have any problems until now.. Maybe it is ok for me because I'm using http-proxy only. But maybe its a good idea to make zoraxy run as non root in general....

And why not run the "plugin http server" completely independent? As non root?
Maybe even in a separate Container?

[tobychui]

Well seems you are the only one suggesting an implementation, I will just use your preferred design :D

[fow0ryl]

Not that you misunderstand me.
Currently I just searching for a way to send Zoraxy messages via webhook instead of email.
However, using a plugin system is only one possible solution.
There are also many other, perhaps more important, requests for improvement.
It's up to you to decide what you like to implement and in what order.

[LeonardoIz]

For the plugin system, I was thinking of something more extensive, allowing for more advanced management of other TCP- or UDP-based protocols, not just HTTP.

I understand that making plugin development easy is important, as most users are beginners. A possible solution could be to develop a more extensive plugin system and, based on that, create a plugin that includes a scripting language specifically for HTTP.

Regarding Design 1, exposing an endpoint that can control proxy traffic seems somewhat risky. Additionally, if users want to install a plugin, I assume it would need to be executed as a separate binary.

Design 2 seems more viable and, above all, more secure. It might also be more efficient to use compiled plugins instead of a scripting language. A possible approach could be implementing a priority queue system, where the first plugin inspects the traffic; if no modifications are needed, it passes it to the next one; otherwise, it modifies it before forwarding it further.

[tobychui]

Thanks for the idea but it is a bit too late as the design 1 is already chosen and being work in progress. Though, design 2 can be easily implemented with an additional plugin that provide such feature. The only thing I can do now is try to make the plugin instillation procedures as easy as possible.

[LeonardoIz]

How do I install a plugin?

I'm trying to install the example debugger plugin on my proxy with docker, I've already built it but I don't know how to install it, I've tried transferring the binary to the plugins folder and rebooting but it doesn't work.

Thanks in advance.

[tobychui]

After you build the plugin it generates a binary like debugger.exe. Then you place it under the plugins/debugger/debugger.exe, where the binary name must match the folder name. Start script support (start.sh / start.bat ) is currently wip