Why "just cache the last result" doesn't actually work
The obvious fix is to remember the last successful check in a local file or the registry, and skip the network call next time. It solves the offline problem, but it doesn't check anything — it's a string sitting on disk that any user with a text editor can flip from false to true. It also doesn't expire cleanly (a copied file works forever on a second machine), and it can't tell you when it was actually last validated. You've traded "no offline support" for "offline support that isn't actually a check" — the file is trusted, not verified.
Why hand-rolling real offline verification is harder than caching a flag
Real offline verification means the app must be able to prove a license is valid without asking a server, using only data that could have come from that server and nothing else. That needs a private/public keypair (the server signs, the app only ever holds the public half), a compact signed payload with the license key, the machine ID, and an expiry the app can check against the clock, a way to make tampering detectable — flip one byte and the signature must fail — and a decision on how long a stale-but-signed result stays trusted before the app is forced to phone home again. None of this is exotic cryptography, but wiring it correctly — verifying the signature before you even parse the payload, checking every claim inside it, choosing a sane expiry window — is exactly the kind of thing that's easy to get subtly wrong once and never notice.
Signed leases: the server signs it, the app only ever verifies it
This is what SublimeKeys' offline verification does. Every activate/verify call returns a lease — a small Ed25519-signed token containing the license key, machine ID, product ID, and an expiry, valid for 7 days. Your app caches it locally and checks the signature against a public key that ships inside your own binary — the private key never leaves our server, so there's nothing on the user's disk that can be edited into a valid lease. A tampered lease fails signature verification immediately, before its contents are even parsed. Once the 7-day window lapses, the next check quietly goes online, gets a fresh lease, and the cycle repeats — so a fully offline machine stays verifiably licensed for up to a week at a time, and a revoked license is caught the next time it reconnects.
How to add it — 3 steps with the official SDKs
What this actually buys you
Your app verifies a license in microseconds with zero network calls on a normal day, keeps working correctly through a week of flight mode or a locked-down corporate network, and still catches a revoked or refunded license within 7 days of the machine reconnecting — without you writing a single line of cryptography yourself, hosting a key management system, or inventing your own token format that someone eventually finds a way to edit.
Who actually needs this
Traveling users
Consultants, field engineers, anyone whose laptop spends real time offline between flights and client sites.
Locked-down corporate networks
Machines behind firewalls that block outbound API calls to anything not explicitly whitelisted.
Python desktop tools
pip install sublimekeys — offline verification built into the official SDK.
Electron apps
npm install sublimekeys — same signed-lease verification, zero native dependencies.
Air-gapped / regulated environments
Machines that are never meant to reach the internet at all, only synced occasionally.
About
Patrick Chen — indie developer behind Sublimearts.io. Built offline verification into SublimeKeys after realizing every desktop app selling to traveling or enterprise users hits the same "no internet" wall eventually.