abookify

Privacy Policy

Last updated: 2026-10-06 · Operating entity: PJ3 Labs Inc., Ontario, Canada

Short version

Abookify keeps your library on your own hardware. Your audiobooks, ebooks, reading positions, bookmarks, and any API keys you enter stay on your device and on the server you run. We — PJ3 Labs Inc. — store none of your library content, run no analytics or advertising, show no ads, and collect no personal data. One thing you should know up front: the optional relay that carries your traffic when you are away from home, NullBore, is operated by a company under the same parent as Abookify. That makes it ours, not a stranger's, and the section below says plainly what it can and cannot see on each path — because from your point of view our corporate structure is not a privacy property; what the relay can read is. There are no accounts to create. The only times data leaves your device are ones you set up yourself, and they are listed below.

What we never collect

What leaves your device, and when

The server you run

When you pair the app with an Abookify server you run, the app exchanges your library, playback positions, streamed audio and text, and a device name and platform (used for sync) with that server — your own hardware, over your local network or a relay you use to reach it from outside your home. The server software is open source and stores your library in a database on your machine; no part of it is sent to PJ3 Labs Inc. The server URL and any pairing/authentication token are held in your device's secure storage (iOS Keychain / Android Keystore) and are never transmitted to us.

Reaching your server from outside your home (optional relay)

There are three ways the app can reach your server, and they are not equally private. We state each one as it actually is; we verified the first two ourselves on 2026-10-06 rather than taking anyone's word for it.

1. End-to-end relay (hostnames ending in e2e.nullbore.com) — nobody can read it, including us. Your device's encrypted connection goes through the relay untouched: the relay forwards ciphertext and holds no key for the hostname. The only key is one your own server generates and keeps. What that gives you differs by platform, and we will not blur it: on Android the app pins your server's key when it pairs, so a connection that completes is one that reached your server and nothing in between; on iPhone the platform offers no such pin, so the guarantee there is weaker — your server's certificate is issued by a public certificate authority (your server obtains it itself; the relay only publishes a one-time DNS challenge and never holds the key), and we monitor Certificate Transparency for any certificate for our names that one of our servers did not obtain. "CA-trusted and CT-monitored" is an honest description of iOS; "pinned" is honest for Android; they are not the same. We confirmed the path on our own server: the certificate presented at the public hostname is the server's own, and a request pinned to that key succeeds. This path is not yet the default — current apps cannot pin a key, so a phone paired today still uses path 2. This paragraph will say "default" when that changes, not before.

2. Proxied relay (hostnames ending in abookify.nullbore.com) — the current default; two parties can technically read it in transit. Your device's HTTPS connection ends at the edge of the relay, which is fronted by Cloudflare, an unrelated third party that terminates TLS there (its policy). The relay itself, NullBore, operated by our parent company, then handles your request in plaintext and forwards it to your server inside its own encrypted tunnel. Because the relay is ours we can state what it does rather than quote a policy. The relay has a request-inspection feature, there so a developer can debug their own tunnel's traffic (it records a request's method, path, headers and the first 4 KB of body); it is off by default and off on our tunnels — we read this from the running service on 2026-10-06, not from the code: zero inspection rows after 175 relayed requests. What the relay does keep is per-tunnel byte counts, request counts and timestamps. Two details we are confirming in writing and will state here when we have them: whether the relay's own operational log (method, path, status, size per request) is retained and for how long, and the controls on the operator-side switch that could enable inspection for a tunnel (if it were ever used, that tunnel's inspection rows would be kept for seven days). Relayed connections are long-lived on our tunnels; a short lifetime is the relay's default for other uses, not a limit on yours. What this path can carry: the audio and text being streamed, your reading positions and bookmarks, and any questions you ask about a book.

3. Your local network — no relay, and no encryption. On your own Wi-Fi the app talks to your server over plain HTTP unless you put your own HTTPS in front of it. Nothing leaves your network.

If path 2 is not acceptable to you today, use path 3, or reach your server through a tunnel you control end to end such as Tailscale or WireGuard — the app accepts any server address.

Cover art

When you look up or search for a book cover, the search runs on your server (which may query a public catalogue such as Open Library, sending the book's title and author). The preview thumbnail images shown in the app's cover picker are then loaded directly by your device from the cover source's servers — an ordinary image request, with no account, key, or other personal data attached. The cover source is a third party; the image it serves is subject to its terms, not ours.

AI recaps and questions

These are optional and off until you set them up. They can run two ways:

Typed questions — exactly what the app sends, and to whom. When you use the on-device option with your own key, then at the moment you ask a typed question the app sends your question and the passages of the book text needed to answer it directly to the LLM provider you selected — Anthropic (api.anthropic.com) or OpenAI (api.openai.com) — authenticated with your key. When instead you use the through-your-server option with a cloud provider you configured on your own server, that request goes from your server to whichever provider you set up there.

Spoken questions (voice). Talking to a book is optional and off until you open it. When you do, the app opens a direct, real-time audio link from your device to the voice provider your server is set up for — OpenAI (api.openai.com) or Google Gemini Live (generativelanguage.googleapis.com) — using a short-lived token your server mints (your provider key stays on the server and is never sent to your device). Over that link, your spoken audio, the spoken reply, and the reading-position-bounded book passages needed to answer travel directly between your device and that provider. If the live link can't connect and you have added a Deepgram key, the app offers you — as a named choice you make, never automatically — a device-local voice loop instead: it sends the audio of your question to Deepgram (api.deepgram.com) to transcribe, and the text of the answer back to Deepgram to speak it. If you never open a voice feature, no audio leaves your device.

These are independent third-party services with their own terms. Once your content reaches a provider, that provider's privacy terms govern it, not ours. Review the policy of any provider before you enable it — Anthropic, OpenAI, Google, Deepgram, or whichever you configured on your server. Using a local model on your own server sends nothing to an AI provider. (Your traffic between the app and your server still travels whichever path you chose above.)

Diagnostics and crash logs

Abookify includes no analytics SDK and no crash-reporting SDK. The app keeps a short local log of recent errors so you can report a bug; it stays on your device and is only ever shown to you in the app's Settings. If you have turned on your own device's “share diagnostics with developers” setting, the operating system may share crash logs with Apple or Google — a platform feature we neither operate nor control.

Permissions the apps request

Children's privacy

Abookify is not directed at children under 13. It has no accounts and does not knowingly collect information from anyone, including children.

Your rights

Because we hold no personal information about you, there is nothing on our side to provide, correct, or delete. The data in your Abookify library is under your direct control on hardware you own; removing the app removes the on-device library, keys, and logs.

If you have used a third-party service alongside Abookify (an LLM or voice provider you enabled) and wish to exercise rights over data held by that service, contact them directly.

Compliance

This policy is intended to comply with Canada's PIPEDA, the European Union's GDPR, and California's CCPA insofar as those laws apply to a product that does not collect personal information from its users.

Changes to this policy

If we ever change what leaves your device, we will update this page and its date. Material changes that affect existing users will be communicated through the app and the Abookify website.

Contact

Questions about this policy: [email protected]

PJ3 Labs Inc.
Ontario, Canada