Why We Rewrote Our Plugin API

When we first started building the plugin system for Pumpkin, our goal was simple: provide developers with the fastest, most powerful way to extend the server. Since Pumpkin itself is written in Rust, the most obvious choice was to build a native Rust plugin API.

In the early days, this worked. Plugins were incredibly fast, and developers had full, unrestricted access to the server's internals. However, as the project grew and more people started experimenting with custom code, the cracks in the native approach began to show.

We eventually realized that if Pumpkin was going to have a thriving, sustainable ecosystem, we needed to make a radical change. We decided to rewrite the entire plugin system using WebAssembly (WASM).

Here is the story of why we made that difficult choice, and the problems we left behind.

The Problems with Native Rust Plugins

Native plugins sound great on paper, but in a production server environment, they introduce severe technical and logistical hurdles.

The Unstable ABI

Rust does not have a stable Application Binary Interface (ABI). This means that the way Rust code is compiled into machine code can change between different versions of the compiler, and even between different compiler flags.

For plugin developers, this was a nightmare. If a server administrator updated Pumpkin, or if they were running a version compiled with a slightly different Rust toolchain, native plugins would simply refuse to load or worse, cause catastrophic memory corruption. Plugin developers would have to constantly recompile and release new binaries for every single minor Pumpkin update or Rust version bump. It was a maintenance burden that stifled innovation.

Crashing the Entire Server

Native plugins share the exact same memory space and execution context as the core server. While Rust is famous for its memory safety, it cannot prevent logical panics.

If a native plugin encountered an unexpected state and called .unwrap() on a None value, it wouldn't just stop the plugin—it would crash the entire Pumpkin server, disconnecting all players immediately. In a multiplayer environment where uptime is critical, allowing third-party code to take down the main thread is an unacceptable risk. We needed a way to isolate plugins from the core server loop.

The Marketplace Distribution Nightmare

We have long-term plans to build a decentralized marketplace where server administrators can easily browse, download, and install plugins. With native plugins, distribution is incredibly complex.

Because native code is tied to specific operating systems and CPU architectures, a plugin developer would have to compile and upload separate binaries for Windows, Linux, macOS, x86, and ARM.

Security Risks

Furthermore, downloading arbitrary native binaries from the internet and executing them on a host server is a massive security risk. Native plugins have unrestricted access to the host system, meaning a malicious plugin could read files, access the network, or compromise the entire server. We needed a format that was universally portable and inherently secure by design.

The WebAssembly Solution

WebAssembly solved every single one of these problems. By moving our Plugin API to WASM (utilizing the WebAssembly Interface Type, or WIT), we completely changed the landscape of Pumpkin development.

A Stable, Cross-Language Interface: WASM and WIT provide a stable contract between the server and the plugin. A plugin compiled today will continue to work on future versions of Pumpkin. Even better, because WASM is language-agnostic, you are no longer forced to write plugins in Rust. You can now use C/C++, Go, Python, or C#.

Safe Sandboxing: WASM executes inside a secure, isolated sandbox. If a WASM plugin encounters a fatal error or panics, the sandbox simply terminates the plugin. The core Pumpkin server continues running flawlessly, and players remain connected.

Universal Distribution: A WASM module is a single .wasm file. It runs identically on Windows, Linux, ARM, or any other architecture the server runs on. This makes the dream of a frictionless plugin marketplace a reality. Server admins can download a plugin, knowing it will run safely and exactly as intended on their specific hardware.

Custom Plugin Permission System: To further enhance security, we added a custom plugin permission system alongside WASM. This system allows server administrators to review the specific capabilities a plugin is requesting, giving owners the ability to explicitly accept or decline initial permissions before the plugin is allowed to run.

Moving to WASM was a massive undertaking, but looking at the stability and flexibility of the API today, it was undoubtedly the right choice. The future of Pumpkin plugins is safe, portable, and built on WebAssembly.