Operational Security (OPSEC)

Building a privacy-first roleplay client is not only a technical exercise. It is also an operational one.

If a product promises strong privacy but behaves casually around repository hygiene, telemetry boundaries, support habits, or infrastructure assumptions, the promise becomes fragile.

That is why Abolitus treats operational discipline as part of the product itself.

Why OPSEC Matters Here

Products in this category face pressure from multiple directions at once:

legal pressure around moderation and liability,
commercial pressure to centralize analytics and support visibility,
technical pressure to make debugging easier by collecting more data,
and external pressure from people who want to identify operators, infrastructure, or weak points.

If you care about privacy, you have to care about how the system is run, not just how it is encrypted.

English-Only Source Policy

One visible operational rule in this project is the English-only policy for source material.

That means source code, comments, variables, and repository-facing technical writing are kept in English rather than mixing languages casually.

Why does that matter?

Because language habits are fingerprinting surface.

Seemingly harmless details such as idioms, mixed-language comments, formatting habits, and region-specific conventions can reveal more than people expect about authorship and operating patterns.

Reducing that surface is an OPSEC choice, not a style preference.

Zero-Trust Toward the Backend

The backend is not treated like a friendly vault that deserves privileged access to your readable content.

It is treated like infrastructure that should receive as little sensitive intelligible information as possible.

That design stance affects product decisions everywhere:

sync storage is shaped around encrypted blob storage rather than readable transcript hosting,
sensitive credentials remain local instead of syncing casually,
support and admin workflows are expected to function without normal access to vault plaintext,
and recovery limits are explained honestly rather than hidden behind vague reassurance.

What OPSEC Does Not Mean

OPSEC is not a magical statement that no plaintext ever leaves your device under any circumstances.

That would be false.

If you choose a cloud inference provider, the prompt content necessarily goes to that provider for inference.

The stronger claim is narrower and more accurate:

Abolitus tries not to place its own backend in the middle of ordinary readable inference traffic.
Sensitive local credentials and vault material are kept on the client side.
The platform tries to avoid building support and storage flows that depend on readable transcripts.

The privacy model is strongest in local mode.

Cloud routes still create a provider-side trust boundary.

Local-First Enforcement Where Possible

Several sensitive behaviors are intentionally pushed toward the client side whenever practical.

That includes the broader design preference for:

local prompt assembly,
local diagnostics and inspection surfaces,
local vault handling,
local provider-key storage,
and local enforcement for the narrow CSAM boundary.

This matters because every feature moved client-side is one less excuse to centralize readable user data.

Why This Helps Users

OPSEC can sound abstract until you connect it to user outcomes.

In practice, good OPSEC means:

fewer incentives to centralize private story data,
less operator knowledge about your actual content,
better resistance to future convenience creep,
and fewer silent regressions where debugging or analytics quietly erode the privacy model.

What Users Should Infer From This

You do not need to memorize internal policies, but you should understand the mindset behind them.

Abolitus is trying to avoid becoming the kind of product that says "privacy-first" on the landing page while quietly depending on:

broad staff transcript access,
permanent readable debug logs,
server-side key custody,
or ordinary recoverable plaintext account flows.

That does not mean every risk disappears.

It means the project is trying to avoid creating unnecessary new ones in its own operations.

If you want the strongest privacy posture, use local inference whenever possible, keep your recovery material safe, and treat cloud routes as a conscious tradeoff rather than as "local privacy but faster."

The product is safest when architecture, daily operations, and your own route choices all point in the same direction.

Read E2EE Architecture for the structural side of the trust model.
Read Desktop Tunnel for the remote-access feature that still tries to preserve the local-hosting mindset.
Read Getting Started with LLM Connections if you want the clearest explanation of local versus cloud provider boundaries.