poooi/poi: a KanColle browser with proxy, cache and plugin hooks

What poi solves for a KanColle player

KanColle runs in a browser and talks to its servers over HTTP. That makes the game traffic visible to anything sitting between the client and the server, and poi exists to be that thing. It is a desktop application built on Electron that acts as the browser you play in, so the proxy, the request cache and the data analysis all live in the same process as the page.

The README lists four capability groups: proxy (HTTP, Socks5 and PAC, the last marked experimental), cache including custom cache, data synthesis and analysis, and notifications. Around those sits a plugin system, with a plugin list maintained on the project wiki. The audience is narrow and specific: KanColle players on Windows, Linux or macOS who want more visibility into their own session than a stock browser gives them, and developers willing to write plugins against the documented API.

If you just want to play the game, poi is heavier than the alternative of opening the site in the browser you already have. The value shows up when you want the traffic layer to be programmable.

How the proxy, cache and plugin layers fit together

The architecture follows from the Electron choice. Electron bundles Chromium and Node in one runtime, so poi can render the game page and run Node-side code in the same application. The README names Electron, React, Blueprint and Redux as the libraries backing it, which matches the repository layout: app.ts and index.js at the top level, with views/, lib/, assets/ and i18n/ directories alongside build tooling (gulpfile.js, electron-builder.config.js) and a jest.config.js for tests.

The proxy is the mechanism that matters. By routing the game's HTTP traffic through poi's own proxy, the application can observe requests and responses, and the cache layer stores them, including a custom cache mode. Data synthesis and analysis then work on what the cache holds rather than on the live page. Notifications are a separate output channel fed by the same data.

The plugin system is the extension point. Plugins are documented separately at dev.poooi.app, and the README links a wiki page listing available plugins. What the README does not describe is the internal plugin loading order, the isolation model between plugins, or how a plugin failure is contained. If you are evaluating poi as a platform, that gap is worth closing by reading the developer docs before committing to it.

Installing poi from a release or from source

The README points first at the GitHub releases page, and second at an npmmirror binary listing for users in mainland China. There are also community-maintained packages that the project lists but does not own: an AUR package for Arch, a Homebrew Cask for macOS, and Chocolatey and Scoop packages for Windows. Nightly builds exist for Windows on Appveyor and for Linux and macOS at nightly.poi.moe, with the README warning that artifacts there could be periodically emptied.

On macOS the documented cask command is:

brew update && brew install --cask poi

On Windows, the Chocolatey route is a single command:

choco install poi

Both of those are community-maintained, so the version you get depends on the maintainer updating the package, not on the poi release cadence.

To run from the repository, the README gives three commands. The engines field in package.json requires Node ^22.18.0 or >=24.11.0, so check your Node version first.

git clone https://github.com/poooi/poi && cd poi
npm install
npm start

npm start runs electron . , which launches the application in development mode. For a packaged build, package.json defines a build script that runs gulp build followed by electron-builder with electron-builder.config.js; there are separate build:x64, build:arm64 and build:all variants, plus build:full for a full target set. The README notes that more detail on running from the repository lives on the wiki.

Where poi is the wrong tool

poi is a standalone Electron application, not an extension for the browser you already use. If your workflow is built around a Firefox sidebar or a mobile client, poi does not fit it, and the related tooling in this space (KC3 kai, its Firefox variant, GotoBrowser, KCCP) occupies exactly those niches. The README itself does not claim to cover them.

The PAC proxy is labelled experimental in the README. Treat that label literally: if your network setup requires PAC, you are on the least settled part of the proxy stack. The other proxy modes, HTTP and Socks5, carry no such caveat.

There is also a maintenance question that the README does not answer. The last push to the repository was on 2026-08-26, the same day v12.0.0 was released, and the repository is not archived, so the project is being worked on. What is not documented is a support policy: the README does not state which older releases receive fixes, and it does not document a rollback path if a new version breaks your setup. Nightly artifacts being periodically emptied means the nightly channel is not an archive either. If you depend on a specific version, keep the installer you downloaded.

How poi differs from KC3 kai and GotoBrowser

The three tools in this space differ mainly in where they run. KC3 kai is a browser extension, which means it lives inside the browser you already use and inherits that browser's update and permission model; the related search terms for a Firefox build suggest users care about which browser it attaches to. GotoBrowser is a separate client for the game. poi is a desktop application that is itself the browser, built on Electron.

That difference has consequences. Because poi owns the browser process, it can offer a proxy with selectable modes (HTTP, Socks5, PAC) and a cache layer with a custom cache option, and it can expose all of that to plugins. An extension is constrained by the host browser's extension APIs, and a native client is constrained by what its authors chose to implement. poi's plugin API is documented in English at dev.poooi.app, which is a real commitment to third-party extension that the README treats as a first-class feature rather than an add-on.

The cost is weight. An Electron application ships a Chromium runtime, and poi's build pipeline reflects that: gulp for the build, electron-builder for packaging, separate x64 and arm64 targets. If you only need request inspection, an extension is the lighter answer. If you want to write code against the traffic layer, poi's plugin surface is the reason to pick it.

Licence, upgrade cost and what the repository does not say

poi is MIT licensed, and the README links the LICENSE file. One carve-out is stated explicitly: the software icon and the SVG icons are not licensed under MIT and could not be used in projects not associated with poi. That matters if you fork the project or reuse its assets, and it is the kind of note that is easy to miss because it sits at the bottom of the README. This is a description of what the licence file says, not legal advice; read the LICENSE and the README note yourself before reusing anything.

Upgrade cost is mostly the cost of Electron major versions. package.json pins the Node range (^22.18.0 or >=24.11.0) and carries an overrides block for babel-plugin-styled-components, which is the sort of pin that exists because a transitive dependency needed constraining. Building from source means running gulp build and electron-builder, and the repository ships lint and typecheck scripts (eslint, stylelint, tsc --noEmit) plus a husky prepare hook, so a contribution path exists with checks attached.

What the README does not document: a release support window, a rollback procedure, or a migration guide between major versions. The jump to v12.0.0 is recent, on 2026-08-26, and the beta series immediately before it (v12.0.0-beta.3 and beta.4) suggests a normal release cycle rather than a rushed one. Still, if you run a plugin, the thing to verify before upgrading is whether that plugin declares support for the new major version.

Editorial conclusion

Adopt poi if you play KanColle on a desktop and want a browser whose proxy, cache and plugin layers you can actually see and extend; the plugin API is documented in English at dev.poooi.app, which is the part most similar tools do not offer. Skip it if you want a Firefox sidebar or a mobile client, since poi is a standalone Electron app and the README points mobile and browser-extension users elsewhere. Before installing, check the release page for the platform you need, confirm your Node version satisfies the engines field (^22.18.0 or >=24.11.0) if you plan to build from source, and read the licence note about the icon assets before reusing any artwork.

Frequently asked questions

Official sources

1. Official documentation
2. Official README
3. Project repository
4. Release notes