arRPC reimplements Discord's local RPC server for clients that lack one

Discord's local RPC server is half documented and absent on the web

Rich Presence is the name for how some apps can talk to Discord desktop on your PC via localhost servers to display detailed info about the app's state. This usually works via parts of Discord desktop natively doing things plus parts of Discord web interpreting that and setting it as your status.

The whole point of arRPC is that those parts are not available everywhere. It is an open source implementation of the local RPC servers on your PC, allowing apps to talk to it thinking it was just normal Discord. It can then send that info to apps which usually don't get RPC, like Discord Web and ArmCord, which can then set that as your status. The README says this would otherwise not be possible, as web apps and browsers cannot just use Discord's already existing code and version.

The project description puts it as an open Discord RPC server for atypical setups, and the tagline calls it an open implementation of Discord's local RPC servers, allowing RPC where it was otherwise impossible, like Discord Web and custom clients. The whole thing is written in NodeJS.

The mechanism is a three part chain, and the README draws it as a list. An app with Discord RPC talks to what would normally be Discord Desktop's native server, which arRPC replaces, and the result is picked up by Discord Web's setting, which a mod or plugin provides. So arRPC sits in the middle of an existing chain rather than inventing a new protocol, and the mod on the other end is what turns an incoming frame into a status.

The project is explicit about its own maturity. The README says arRPC is experimental and a work in progress, so expect bugs. That sentence matters for anyone planning to run it on a machine they depend on.

The WebSocket bridge passes Discord frames straight through

The server side of arRPC opens a simple bridge WebSocket server which messages the JSON of exactly what to dispatch with in the client with no extra processing needed, allowing small and simple mods or plugins.

That sentence describes the design in one line, and it is the reason the project is small. The server does not translate, validate or enrich the frames. It reads what an application sends, and it dispatches the JSON exactly as it is to whatever is on the other end of the WebSocket. The receiving mod then hands that JSON to Discord's own client code as if it had come from the native server.

The consequence is that the work of understanding Discord's IPC protocol is pushed to the mod side, which is why the repository ships a bridge mod at examples/bridge_mod.js, along with an examples/README.md and an examples/electron/ directory. A mod author writes the small part that connects the WebSocket to the Discord client, and does not have to deal with a framework.

The package structure is minimal and matches that. The package is arrpc, version 3.7.0, MIT licensed, published as an ES module with the main entry at src/server.js and the binary at src/index.js mapped to the command arrpc. The start script is node src. There is exactly one runtime dependency, ws, at version 8.18.3, which is the WebSocket implementation, plus an update_db.js at the root of the repository.

One thing to be aware of when reading the tree: the repository is small, and the top level is .github, src, examples, a changelog, the package files and that update script. A reader expecting a framework will find something much smaller, and that is consistent with the stated goal of a bridge that needs no extra processing.

One command starts the server, and Node 18 is the floor

Running the server is a single command in a terminal, and the requirement is a modern, at least version 18, Node.js installation:

npx arrpc

npx fetches and runs the package without a permanent install, which is the right way to try it. The package also declares a binary named arrpc, so once it is installed the same thing is available as a command, and the repository's own start script runs the server entry point directly:

node src

There is no configuration file in the README and no documented port setting, so the defaults are what you get. The only other instruction in the usage section is a warning about what comes after, and the client side is where the choices are.

The three documented paths differ in how much work they ask of you.

The first is the plain web path with no mods beyond the bridge script. You run the arRPC server, then with Discord open you run the content of examples/bridge_mod.js in the console, which the README identifies as Ctrl+Shift+I. So the flow is: the app sends a rich presence frame to the local server, the server relays it over the WebSocket, and the injected script pushes it into the Discord web client.

The second is the Vencord path, which is the least work. You run the server and enable the WebRichPresence (arRPC) Vencord plugin, and that is the entire procedure. A user plugin in Vencord can make the same websocket connection the manual script makes, with the added benefit of surviving a page reload.

The third path needs no server at all. The README states that ArmCord and Vesktop have arRPC specially integrated, so you just enable the option in the client settings, and the server is not required. That is the cleanest arrangement of the three, since the client ships the equivalent of the mod itself.

The support matrix is a checklist, not a promise

The README ends with a supported section that is worth reading carefully, because the unchecked boxes are as informative as the checked ones.

On transports, the WebSocket Server is supported with JSON, while Erlpack is listed but not checked. The HTTP Server is not checked. IPC is supported, and so is Process Scanning. That combination explains the design. Discord desktop normally exposes its local RPC over IPC between processes, and arRPC re-creates that side, while the WebSocket and JSON path is the bridge to the browser or alternative client where the mod lives.

The unsupported Erlpack encoding is worth noting because it is the wire format the native Discord client uses in some paths, and its absence is the reason the bridge is described as passing JSON of exactly what to dispatch with.

On commands, the list is DISPATCH, SET_ACTIVITY, INVITE_BROWSER, GUILD_TEMPLATE_BROWSER, DEEP_LINK and CONNECTIONS_CALLBACK, and every one of them is checked. SET_ACTIVITY is the one that matters for the common case, since it is how an application sets the presence line. INVITE_BROWSER, GUILD_TEMPLATE_BROWSER and DEEP_LINK are the ones that turn into UI actions rather than status text, and CONNECTIONS_CALLBACK is the mechanism behind the connect button some applications show.

The honest reading is that the common path, set a presence, is covered, and the HTTP transport and Erlpack encoding are the gaps a project would have to work around. Anyone building on top of arRPC should check the list against the specific commands their application uses, because the supported section is the only place the README states what is complete.

Discord desktop already has this, which is the comparison that matters

The alternative to arRPC is not another third party project, it is the server that ships inside Discord itself. The README's chain lists Discord Desktop's native server with a strikethrough and arRPC in its place, and the earlier paragraph explains that rich presence usually works via parts of Discord desktop natively doing things.

So the difference in approach is this. Discord's own implementation lives inside the desktop client, is closed, is bound to that client, and speaks the native transport including Erlpack. arRPC is a separate Node.js process that reimplements the same role, exposes a WebSocket with JSON frames, and lets a small mod or plugin push those frames into a client that has no local RPC of its own.

That is a real difference in what each one can do. The native server cannot serve Discord Web, because the web client has no way to reach a localhost server inside the desktop application. arRPC can, because the bridge terminates at a WebSocket that a page script can reach. It also means arRPC can serve custom clients such as ArmCord and Vesktop, which is why those clients can integrate it directly.

The cost is the other half of the trade. The native server is maintained alongside the client and matches its protocol version. arRPC is an independent reimplementation of a half-documented protocol, and it carries the risk that Discord changes the client in a way the reimplementation does not follow. The README's own warning about being experimental and a work in progress is the honest statement of that risk.

MIT licensed, released 3.7.0 in March 2026, last push in April 2026

The project sits under the OpenAsar organisation, the homepage is arrpc.openasar.dev, and the licence is MIT with the LICENSE file at the root of the repository and a badge in the README. The package.json agrees, listing MIT as the licence and OpenAsar as the author. For a tool that runs as a local process and a small injected script, that is the simplest possible licensing story.

On versions, the recent releases are 3.4.0 on 2024-04-28, 3.5.0 on 2024-08-30 and 3.7.0 on 2026-03-30, and the package.json in the tree is at 3.7.0, matching the newest tag. The gap between 3.5.0 and 3.7.0 is long, which is a hint that the project moves in bursts rather than continuously.

The repository is not archived, but the last push was on 2026-04-08, which is more than six months before now, so treat arRPC as a project that is not currently receiving regular updates rather than as an actively developed one. The changelog at the root of the repository is the file to read for what changed between the versions you care about, and the repository also carries a .github directory for issue and workflow handling.

Two practical notes for anyone running it. The Webcord path asks you to disable the Use built-in Content Security Policy option in the Advanced settings before running the bridge script in the DevTools console, which is a change to how that client loads content and is worth understanding before you make it. And the server is a local process that apps connect to over localhost, so the environment it runs in is one you already trust with the applications that talk to Discord.

Editorial conclusion

arRPC suits someone running Discord Web, Webcord or another custom client who wants the same rich presence behaviour that Discord desktop provides, and it is cheap to try since the whole server is one npm command. It is the wrong tool if you run the official Discord desktop client, since that already ships its own local RPC server, and the README states plainly that arRPC is experimental and a work in progress, so expect bugs. Before you rely on it, check the supported transports and commands list for the features you need, note that HTTP transport and Erlpack encoding are still unchecked, and remember that the last push was on 2026-04-08 with release 3.7.0 published on 2026-03-30.

Frequently asked questions

Official sources

1. License: MIT
2. OpenAsar/arrpc on GitHub
3. Project website
4. README
5. Releases