Electron 应用程序通常使用预加载脚本（preload scripts）来授予渲染进程对特权 Electron API 的访问权限。然而，Notifio 的主窗口摒弃了这一做法，禁用了 Node 集成和上下文隔离。相反，渲染进程被视为一个由主进程中运行的本地 HTTP 服务器提供的标准网页。该服务器暴露了 28 个路由，构成了用户界面与应用监控逻辑之间的完整接口。这一架构选择由多个因素驱动。首先，渲染进程确实作为一个 Web 应用程序运行，采用标准 Web 技术构建，且对 Electron 一无所知。其次，使用 HTTP 为 API 交互提供了结构化且现成的词汇表，例如 CRUD 操作，从而避免了为自定义 IPC 通道持续投入设计精力。第三，主窗口的可丢弃特性——其渲染进程频繁重新加载——受益于 HTTP API，该 API 允许用户界面在每次加载时轻松重建其状态。实时更新通过轮询这些 HTTP 路由来实现，而非推送机制。服务器位于主进程内，通过消除序列化边界和对独立进程管理的需求，简化了其运行。对该本地 HTTP API 的认证通过将其绑定到回环接口（loopback interface）来强制执行，从而阻止外部网络访问。虽然 HTTP 服务器提供了清晰的分离，但某些特定的 Electron 功能（例如为用户登录打开新的浏览器窗口）通过一个小型的进程内桥接器进行管理。该桥接器允许路由处理器委托依赖 Electron 的任务，而无需服务器模块本身导入 Electron。这一以 HTTP 为中心设计的唯一例外是录制器窗口，它使用预加载脚本和 IPC。这是必要的，因为它加载第三方网站并需要观察页面交互，而这一任务在沙箱环境中的预加载脚本内更为合适。两者的区别在于：当渲染进程查询应用程序时使用 HTTP，而当观察外部页面时使用预加载脚本/IPC。