netrunner-landing/scripts/docs-content.en.mjs

// English counterpart of docs-content.ru.mjs — see that file for sourcing notes.
export const DOCS_EN = [
  // ───────────────────────────── CORE ─────────────────────────────
  {
    title: "Getting started",
    category: "Core",
    status: "Public",
    content: `NETRUNNER // FIRST BOOT

No e-mail or phone signup — account access is designed to link as little data to you as possible.

METHOD 1 — TELEGRAM
Open @ntrnr_vpn_bot and tap "Dashboard". Sign-in is confirmed via the official Telegram Login Widget — the server verifies Telegram's cryptographic signature; your Telegram password never reaches the VPN server.

METHOD 2 — GHOST PROTOCOL (fully anonymous)
If you don't want to link an account even to Telegram, generate a seed phrase right in the dashboard. The seed is the only key to the account: it lives nowhere but with you, and isn't tied to a phone number, e-mail, or Telegram ID.
IMPORTANT: the seed cannot be recovered. Lose it and you lose the account and everything on it. Download the .txt with the seed phrase and store it offline (password manager, paper — anything but a screenshot in shared cloud storage).

NEXT STEPS
1. Download the client for your platform on /download (Windows, Linux, and Android are available now; macOS and iOS are in development).
2. Activate a plan in the dashboard — there's a free trial for accounts linked to Telegram (anti-abuse: Ghost accounts don't get a trial, otherwise it would be farmed by scripts).
3. Connection is configured automatically — nothing to set up by hand.

EOF`,
  },
  {
    title: "Pricing, payments & billing",
    category: "Core",
    status: "Public",
    content: `PAYMENT // TON

Payment is accepted only in TON cryptocurrency — no bank cards, no payment processors that require ID documents.

HOW IT WORKS
1. Pick a plan — the server issues an invoice for the exact TON amount at the current exchange rate.
2. Transfer that amount to the master wallet address with the comment (memo) shown on the invoice — that's exactly how the payment gets matched.
3. The server verifies the transaction directly on the TON blockchain: amount (not less than invoiced), destination address, and memo. The same tx hash can never be credited twice.
4. Status flips to "paid" automatically, no manual review.

WHY TON ONLY
Transparency and verifiability: a payment is confirmed mathematically from blockchain data, not by trusting a processor. The trade-off — blockchain transfers are irreversible, see "Refund Policy" under Legal.

REFERRAL PROGRAM
Your invite link lives in the dashboard. Self-referral (same person as both referrer and referee) is blocked server-side, not just by policy.

EOF`,
  },

  // ─────────────────────────── SECURITY ───────────────────────────
  {
    title: "Threat model and encryption",
    category: "Security",
    status: "Encrypted",
    content: `THREAT_MODEL.LOG

WHAT NETRUNNER PROTECTS AGAINST
- Passive traffic interception on the path ISP → destination (café Wi-Fi, carrier, transit networks).
- DPI classification and protocol-based blocking (see "Traffic Obfuscation and DPI Evasion").
- Linking activity to your identity through classic signup channels (e-mail/phone) — via Ghost Protocol.

WHAT NO VPN CAN PROTECT AGAINST
- Compromise of the device itself (malware, keyloggers, physical access).
- De-anonymization by the destination services themselves, if you log into them under your real identity.
- Legal liability for what travels through the tunnel — encrypting the channel doesn't make illegal content legal.

TUNNEL CRYPTOGRAPHY
Every data frame inside the tunnel is protected by ChaCha20-Poly1305 AEAD encryption — simultaneously encryption and integrity checking (auth tag): tampering with even one bit in transit is detected and the frame is dropped.

Key exchange uses X25519 (elliptic-curve Diffie-Hellman); a fresh session key is generated for every tunnel establishment (ephemeral). This gives forward secrecy: even if one session's key ever leaked, it wouldn't decrypt past or future sessions — each has its own one-time key. Final encryption keys are derived from the exchange result via HKDF, never used directly.

Every frame carries an HMAC tag built on a TOTP-like principle (a time component) — replay protection: a captured and resent frame fails verification.

Control frames are padded with random bytes, which complicates traffic analysis by packet length.

EOF`,
  },
  {
    title: "Traffic obfuscation and DPI evasion",
    category: "Security",
    status: "Encrypted",
    content: `STEALTH_LAYER.LOG

DPI (Deep Packet Inspection) is how ISPs and censoring systems tell "regular HTTPS" apart from VPN/proxy traffic and block the latter. Most VPN protocols have a recognizable fingerprint at exactly this layer, not in the encryption itself.

WHAT WE DO
The tunnel's first packet looks like a real TLS handshake (ClientHello/ServerHello) — not approximately, but byte-for-byte matching the order and content of a real browser's cipher suites, TLS extensions, and GREASE values (a JA3/JA4 profile). To a DPI system classifying traffic by handshake fingerprint, our traffic is indistinguishable from an ordinary browser visiting an https site.

The real key exchange (X25519) is physically hidden inside fields of the fake TLS handshake — for example, in the KeyShare extension and in the session_id field, which per spec looks like random bytes but actually carries part of the authentication tag.

BEING HONEST ABOUT THE LIMITS
This is not real TLS: there's no certificate chain, no server authenticity check in the ordinary HTTPS sense, because the goal isn't to secure a web page — it's to hide the very fact of tunneling from traffic-classification systems. Actual data protection is provided by a separate layer (see "Threat Model and Encryption"), not by this obfuscation layer.

If a connection isn't recognized by the server as a legitimate client for some reason (say, someone port-scanning to figure out what's listening), the server quietly "reflects" that attempt onto unrelated content (stealth fallback) — from the outside it looks like an ordinary web server, not a node that answers specifically to VPN requests and can therefore be fingerprinted by scanning.

EOF`,
  },
  {
    title: "Authentication and session storage",
    category: "Security",
    status: "Encrypted",
    content: `SESSION.LOG

NO TOKEN IN LOCALSTORAGE
The dashboard and site session lives exclusively in an HttpOnly cookie — a cookie that browser JavaScript simply cannot read (neither your own script nor an injected XSS script). The token is never in localStorage/sessionStorage: if it were, any script that managed to run on the page could steal it.

A short-lived access token (15 minutes) is issued alongside a rotating refresh token (30 days). When the access token has expired, the session refreshes automatically in the background — no re-login. The database stores not the refresh token itself but only its SHA-256 hash — even a database leak can't be reversed back into a usable token.

If the server ever sees an attempt to reuse an already-revoked (rotated) refresh token, that's an unambiguous compromise signal, and every session on the account is revoked in response, not just that one.

CSRF PROTECTION
For state-changing requests riding on a cookie session (payments, settings changes, etc.), the server additionally checks the Origin/Referer headers against an allow-list of domains — a third-party site can't silently fire requests on your behalf even if your cookie is valid.

TELEGRAM LOGIN
The Telegram Login Widget's signature is verified via HMAC-SHA256 using a constant-time comparison (not a byte-by-byte comparison that leaks via timing) — ruling out both widget-data forgery and timing attacks against the server.

EOF`,
  },
  {
    title: "What we store and what we don't",
    category: "Security",
    status: "Public",
    content: `DATA_RETENTION.LOG

Short version: we store exactly what's needed to run the account and billing, and we don't keep a log of your internet activity.

WHAT'S STORED ON THE SERVER
- Account identifier: Telegram ID (if you signed in via Telegram) OR nothing personal at all (if you signed in via Ghost Protocol — no email, phone, or name).
- Subscription status and payment history (amount, TON blockchain tx hash, date) — needed for billing and payment disputes.
- A hash (not the token itself) of the active session and its creation time — needed to protect against session theft and to support signing out of all devices on request.
- Referral links between accounts (who invited whom) — solely for bonus crediting.

WHAT ISN'T
- A log of sites visited through the VPN, destination IPs, or traffic content — at the tunnel protocol level (NRXP) there's no code that writes anything like that to a database.
- A history of "who connected to which node when" beyond what's needed for an instant health check (is the server alive right now) — that's infrastructure monitoring, not a user activity log.

WHAT'S FAIR TO SAY HONESTLY
Server processes, like any service's, do write operational logs in the moment — errors, connection start/stop — for infrastructure debugging. That's not a structured database of your activity and isn't tied to your identity, but it would be dishonest to claim that literally no process anywhere ever writes a single log line. If this matters for your threat model, use Ghost Protocol and avoid posting data elsewhere that could be linked back to your account.

EOF`,
  },
  {
    title: "Responsible disclosure",
    category: "Security",
    status: "Public",
    content: `BUG_BOUNTY.LOG // RESPONSIBLE DISCLOSURE

Found a vulnerability — in the tunnel, the dashboard, the bot, or billing? Tell us before anyone else finds out.

RULES
1. Don't exploit the finding beyond what's needed for proof-of-concept — no bulk data dumps of other users, no DoS, no attempts to move other people's funds.
2. Give us a reasonable amount of time to fix it before disclosing details publicly.
3. Don't touch other people's accounts or data without their explicit consent.

HOW TO REPORT
Message support via the @ntrnr_vpn_bot Telegram bot with SECURITY in the first message — the fastest way to reach someone who can actually fix the issue.
[A dedicated security-report e-mail and public PGP key will be added here once the operating entity is registered — see also the Legal section.]

We don't currently promise monetary bounties, but we do promise: priority triage, public credit if you want it, and that your report won't be ignored.

EOF`,
  },

  // ─────────────────────────── NETWORK ───────────────────────────
  {
    title: "Tunnel architecture",
    category: "Network",
    status: "Internal",
    content: `ARCH.MAP // INTERNALS

Three layers, bottom to top:

1. RAWCAST — the local layer on the client device. Real TCP/UDP connections from apps (browser, messenger, etc.) are described as a compact frame with protocol type, event type, local socket_id, and destination address/port. This frame is a purely internal format — it never travels over the network as-is.

2. NRXP (Netrunner eXchange Protocol) — the application protocol inside the tunnel. A RawCast frame is wrapped into an NRXP frame: a 25-byte header (auth tag, stream id, type, payload length, padding length) plus the payload itself. Many independent streams (say, a dozen simultaneous browser connections) are multiplexed over one tunnel — no need to open a separate connection for each; the NRXP stream id is what tells them apart.

3. TRANSPORT — every NRXP frame is encrypted (ChaCha20-Poly1305) and wrapped as a single TLS ApplicationData record inside the disguised TLS handshake (see "Traffic Obfuscation and DPI Evasion"). From the outside, indistinguishable from a browser's HTTPS session.

ON THE DEVICE
The client intercepts traffic via a TUN interface and its own userspace stack (smoltcp) — it operates at the IP packet level rather than relying on OS proxy settings, which not every app respects.

ON THE SERVER
A node accepts an incoming connection, checks whether it's a legitimate NRXP client (as opposed to a port scanner or a random HTTPS request), and either establishes the tunnel or quietly "reflects" the connection as an ordinary web server (stealth fallback) — never revealing that the port knows anything about VPN traffic.

NODE SELECTION
The list of available servers and routing parameters are handed to an authorized client by the API using a short-lived one-time token — nothing to configure by hand, and access to the node list itself requires an active subscription.

EOF`,
  },
  {
    title: "Clients and platforms",
    category: "Network",
    status: "Public",
    content: `PLATFORMS.LOG

The tunnel engine is written in Rust and reused wholesale across platforms — the same crypto and protocol everywhere, not rewritten separately per OS with its own bugs.

AVAILABLE NOW
- Linux — native client, TUN interface, requires cap_net_admin/cap_net_raw (or root).
- Windows — native desktop client.
- Android — Kotlin app on top of the Rust core, built via UniFFI/JNI for arm64/armv7/x86/x86_64.

IN DEVELOPMENT
- macOS — desktop client in progress.
- iOS — beta testing underway.

Current versions and download links live on /download; it also shows which platform is already "active" versus still in development — status isn't dressed up.

EOF`,
  },

  // ──────────────────────────── LEGAL ────────────────────────────
  {
    title: "Privacy Policy",
    category: "Legal",
    status: "Public",
    content: `PRIVACY POLICY

Last updated: [fill in at publication]

1. WHO WE ARE
Netrunner VPN service operator: [legal entity or individual name — to be filled in here once registration is complete; until then this document is informational, not a final legal instrument].

2. WHAT DATA WE COLLECT
- Telegram sign-in: your Telegram ID and whatever data the Telegram Login Widget itself passes on authentication (name, username, photo — where applicable).
- Ghost Protocol sign-in: no personal data is collected — the seed phrase is generated client-side and isn't tied to your identity.
- Payment data: amount, TON blockchain transaction id, date — TON payments are public on the blockchain itself, independent of us.
See "What We Store and What We Don't" under Security for the technical detail.

3. WHY WE USE THE DATA
Solely to provide the service: authentication, granting VPN node access per an active subscription, payment processing, referral crediting, support responses.

4. THIRD-PARTY SHARING
Data isn't sold or shared with third parties for marketing. The only technically necessary sharing happens through the Telegram network itself (for Telegram sign-in) and the public TON blockchain (for payments) — both operate under their own rules, outside our control.

5. YOUR RIGHTS
You can request account deletion and removal of associated data via bot support. Note: a TON blockchain payment record cannot physically be deleted — the blockchain is immutable by design.

6. CONTACT
Support: the @ntrnr_vpn_bot Telegram bot.
A dedicated legal address and e-mail for official inquiries will be published here once the service operator is registered.

EOF`,
  },
  {
    title: "Terms of Use",
    category: "Legal",
    status: "Public",
    content: `TERMS OF USE

Last updated: [fill in at publication]

1. ACCEPTANCE
By using the Netrunner VPN service (site, bot, client apps), you agree to these terms. If you don't agree, don't use the service.

2. ACCEPTABLE USE
The service is provided for lawful use in the jurisdiction you're accessing it from. You may not use it for: attacks against third-party infrastructure (DDoS, brute-forcing, unauthorized scanning), spam, malware distribution, material prohibited under applicable law, or evading sanctions where doing so is explicitly illegal.
We do not technically read your traffic's content (see "What We Store and What We Don't"), but that doesn't relieve you of responsibility for what you do — encrypting the channel doesn't make an illegal act inside it legal.

3. ACCOUNT
You're responsible for safeguarding your credentials — most importantly a Ghost Protocol seed phrase: it can't be recovered, and losing it is equivalent to losing the account. Transferring an account to a third party is discouraged and done at your own risk.

4. SUBSCRIPTION AND PAYMENT
Payment is accepted in TON per the current pricing. Refund rules are covered in a separate "Refund Policy" document.
A free trial period (where available) is granted once per Telegram-linked account; technical measures prevent re-claiming a trial by creating new anonymous accounts.

5. SERVICE AVAILABILITY
We work to keep nodes running continuously but don't guarantee 100% uptime — the network is made of individual servers, and any one node may temporarily go offline; the rest of the network remains available.

6. LIMITATION OF LIABILITY
The service is provided "as is." We aren't liable for consequences of using the service in violation of Section 2, nor for the actions of third parties (ISPs, the TON blockchain network, Telegram) outside our control.

7. CHANGES TO THESE TERMS
We may update these terms; continued use after a new version is published means you accept it.

8. OPERATOR AND JURISDICTION
[The operator's name and applicable jurisdiction will be listed here once legal entity/sole-proprietor registration is complete. Until then this document is informational.]

EOF`,
  },
  {
    title: "Refund Policy",
    category: "Legal",
    status: "Public",
    content: `REFUND POLICY

Payment is accepted in TON cryptocurrency. Because of how blockchains work, confirmed transactions are technically irreversible — neither we nor you can "undo" a transfer once it's confirmed on-chain.

WHEN A REFUND IS POSSIBLE
- Accidental overpayment (you sent more than the invoiced amount) — the excess is refunded manually after contacting support.
- A technical failure on our side that prevented an activated plan from being usable, where re-granting access isn't possible.
In these cases the refund is issued manually to a TON address you provide; the network fee is covered by [party to be finalized in the final version of this policy].

WHEN A REFUND ISN'T AVAILABLE
- You changed your mind after activating a plan and partially using the period.
- The account was banned for violating the Terms of Use.
- You lost access to your account because you lost a Ghost Protocol seed phrase — that's not a service malfunction but an inherent property of the anonymous sign-in model, which is disclosed when the seed is generated.

HOW TO REQUEST A REFUND
Contact support via the @ntrnr_vpn_bot Telegram bot with the transaction's tx hash and a description of the issue. Non-standard cases are resolved at the service operator's discretion.

EOF`,
  },
];