Offline Protocol packages for Windows
Offline Protocol has Windows x86_64 builds for every desktop and server binding, and none for the phone bindings. As of 0.31.0 (October 2026), the Windows pieces are:
| Package | Windows build | How you get it |
|---|---|---|
Python, offline-protocol-sdk (beta) | win_amd64 wheel with the native library inside | PyPI |
Java, com.offlineprotocol:offline-protocol-java | The jar, plus offline_protocol_uniffi.dll from the release zip | Maven Central and the GitHub release |
| C, and languages that call C | offline_protocol.h, offline_protocol_uniffi.dll and its import library | The GitHub release zip |
Ruby, offline_protocol | The gem, over the same DLL | RubyGems and the GitHub release |
The offline CLI | @offline-protocol/cli-win32-x64 native binary | npm |
| React Native, Swift, Android, Flutter | None; these build iOS and Android apps |
The release for 0.31.0 attaches offline-protocol-0.31.0-windows-x86_64.zip beside the Linux and macOS archives, along with the Python wheels. If you are still choosing a language, which Offline Protocol SDK should I use? compares them, and what platforms does Offline Protocol support? covers the rest of the matrix.
Python SDK on Windows
The Python package is the most complete Offline Protocol integration on Windows, because it ships the transport bridges as well as the engine. The Rust core does no I/O of its own, and the Python binding supplies the internet, Bluetooth LE, LAN peer-stream and gateway-client bridges, so a Windows program gets a working peer from one install:
pip install offline-protocol-sdk
The wheel is for Python 3.10 or later and carries the native library, so nothing compiles on the machine. The import name is offline_protocol_sdk, and every install puts three commands on the path: offline-protocol-service, offline-protocol-http-front and offline-protocol-verify.
On Windows the MLS key material goes into Windows Credential Locker through the keyring library. A Windows server with no usable credential store can pass a store key instead, and the SDK then seals every key record on disk in its built-in file stores. One Windows detail: the SDK refuses an MLS directory and a state directory that are the same, and on a volume that folds case it treats keys and Keys as the same directory.
The Python guide covers configuration and the event loop.
Bluetooth LE and other transports on Windows
Every Python transport runs on Windows, with Bluetooth LE in the central role. The Python README’s transport table puts it this way:
- Internet relay over WebSocket. All platforms. It is the primary transport for desktop hosts.
- Bluetooth LE central. All platforms, through
bleak. The host scans for and connects to devices that advertise. - Bluetooth LE peripheral. macOS and Linux. It runs through
bless, which the package installs on those platforms; on Windows the host uses the central role. - Peer streams (the
wifi_directslot). All platforms. TCP streams over an existing IP network, with DNS-SD discovery through the optionallanextra. It does not create a Wi-Fi Direct group. - Gateway client (the
reticulumslot). All platforms. It connects over TCP to a gateway daemon you deploy separately.
For phones, plan the path to the host. A phone finds a host over Bluetooth LE through the host’s advertisement, so a Windows host meets phones over peer streams on a shared Wi-Fi network or over a relay, and a Mac or Linux host covers the Bluetooth LE path. What is a BLE central and a BLE peripheral? explains the two roles.
The local API service follows the same rule: it starts the Bluetooth LE peripheral only where the platform has a backend, which the docs name as macOS and Linux through BlueZ.
Java, C and Ruby on Windows
Java, C and Ruby on Windows all load offline_protocol_uniffi.dll from the release’s Windows zip. Each is an engine without transports: your process owns the radios and sockets, drains each transport’s outbound queue and reports the result.
- Java. The jar on Maven Central holds generated Java and no native code. Run on JDK 22 or later with
--enable-native-access=ALL-UNNAMED, and pointjava.library.pathat the directory that holds the DLL. See how to use Offline Protocol from Java. - C, C++, Go, C# and Zig. The zip carries
offline_protocol.h, the DLL and its import libraryoffline_protocol_uniffi.dll.lib. C# reaches it through P/Invoke and Go through cgo. See how to call Offline Protocol from C, C++, Go or C#. - Ruby. RubyInstaller reads
RUBY_DLL_PATH, notPATH, to find the DLL:
$env:RUBY_DLL_PATH = "C:\path\to\dir"; ruby -Ilib your_script.rb
Use a jar or a Ruby binding from the same release as the DLL. The Ruby binding warns that nothing outside the SDK repository checks that the two match.
Offline Protocol CLI on Windows
The offline CLI runs on Windows x64. Its npm package is a small Node.js launcher, and npm installs only the native binary for your machine from the matching optional dependency, @offline-protocol/cli-win32-x64 on Windows. Do not install with --omit=optional, or the binary is left out.
npm install -g @offline-protocol/cli
offline --version
The CLI needs Node.js 18 or later. Its local MCP server, offline mcp serve, needs no login and runs the same on Windows as elsewhere; what is the Offline Protocol MCP server? covers what it does.
Windows platform scope
A few Offline Protocol pieces are built for other platforms, and these are the ones to plan around on Windows:
- Bluetooth LE peripheral on macOS and Linux. When phones must find the host over Bluetooth LE, run the host on a Mac or on Linux with BlueZ, where both roles run.
- x86_64 builds. The wheel, the release zip and the CLI binary are built for Windows x86_64. For a host without a published package, the SDK’s build-from-source instructions produce the native
.dll,.soor.dylibfor the machine they run on. - Phone SDKs build phone apps. React Native, Swift, the Android library and Flutter build iOS and Android apps.
- Containers deploy to a Linux host. The SDK’s container setup uses host networking, which on Docker Desktop for Windows is the namespace of Docker’s Linux virtual machine, so the HTTP front is not on the Windows machine’s loopback and multicast DNS does not reach its LAN. The SDK’s demos run on Docker Desktop, and a deployment goes on a Linux host. See can I run Offline Protocol on a server or in Docker?
Whatever the platform, qualify the radio and the permissions on the hardware you will deploy, as the platforms page asks.