GSoC 2026 Idea: Extension API & IPC Optimization

[divyarathodgit]

Hey everyone, I'm Divya. I've been diving into the codebase lately and got a few PRs merged (really enjoying working with the C++ core!). I'm putting together my GSoC 2026 proposal, and instead of adding new OS-level APIs, I want to pitch an idea focused on framework stability—specifically around the Extension IPC and the Node.js wrapper.
What I Noticed
Extensions are super powerful, but I noticed a few friction points with the current WebSocket implementation:

1. Zombie extensions: If an extension crashes, the WebSocket connection doesn't always close cleanly.
2. Payload validation: The C++ core seems to lack strict, lightweight validation for incoming JSON payloads, which can sometimes cause silent failures.
3. Synchronous bottlenecks: Passing large data (like image buffers or large files) between the Node backend and C++ core can block the main thread because the parsing is mostly synchronous.

My Idea:
I'd love to spend the summer fixing these issues while strictly sticking to Neutralinojs's minimal-binary philosophy. My rough plan looks like this:
• 1. Lifecycle & Heartbeat: Add a native ping/pong mechanism in the C++ WebSocket handler to detect disconnected extensions and clean them up safely.
• 2. Payload Standardization: Build a lightweight, header-only JSON validation layer so malformed requests throw proper errors instead of failing silently.
• 3. Async Chunking: Refactor the C++ message parser to use an asynchronous, chunked reading approach so heavy data transfers don't block the main thread.
• 4. Node.js SDK Revamp: Rewrite the developer-facing Node wrapper using standard event-driven patterns (EventEmitters for lifecycle events, Promises for standard IPC calls) to make writing backend extensions much cleaner.

Questions:
Before I write up the full 12-week timeline, I'd really appreciate some feedback to make sure I'm approaching this the right way:

1. To keep the binary size down, do you have a preferred approach for JSON validation in the native core, or should I just write strict wrappers around the existing parser?
2. For the Node.js SDK revamp, should I prioritize strict backward compatibility with the current extension API, or is a clean v2 break acceptable??

Let me know what you think!
GitHub: https://github.com/divyarathodgit
Discord:divya013283