deviant/Parameters/Hosting-DeviantX.md
Local Dev ced2eda48d @
chore: checkpoint in-flight work across domains

Sweep of accumulated uncommitted work on design/dex-p2p-architecture into
one checkpoint (multiple sessions share this tree). Main areas:

- anthemus: covenant-wiring follow-ups (engine, ExchangePanel), AgoraScreen seam
- spv: ServerPool + p2p header transport (pool.ts, core/spv/*), wallet.ts wiring
- walletconnect: responder/useConnect updates + connect-responder-compat test
- wallet: send-tier-a rework + swap.ts, plus send-tier-a unit tests
- asm: chipnet throughput/stress harness (scripts/chipnet-asm-*) + ASM_Native docs
- app UI: screens/* and shell.css touch-ups; sat -> bits copy migration
- docs: new snapshots (INDEX regenerated), Parameters (WalletConnect/SSH/ASM),
  KnowledgeBase, WALLET-COORDINATION changelog

Checkpoint only; not a release. Secrets (Keys/, .chipnet-keys*, .env) remain
gitignored and were verified absent from the staged set.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
@
2026-08-14 02:00:43 +02:00

9.7 KiB
Raw Blame History

Hosting the Deviant wallet at deviant.x

Purpose: Reference for anyone who wants to serve the Deviant wallet build at a BCNR (Bitcoin Cash Name Resolution) name — a decentralized .x domain registered on the BCH chain — instead of (or alongside) the current DuckDNS URL.

Status: Not executed yet. This doc captures what it takes and how; the actual on-chain registration + hosting steps require the operator's wallet + funds and are not something Claude sessions can automate.

Sources: D:\Dev\SilentMode — the sibling repo that owns the entire BNS stack. Cross-referenced: SilentMode/README.md, SilentMode/START-HERE.md, SilentMode/Decentralized.DNS/README.md, SilentMode/Decentralized.DNS/PROTOCOL.md, SilentMode/Decentralized.Hosting/README.md, SilentMode/Decentralized.Hosting/SIA-UPLOAD.md, SilentMode/VPS/Deviant/vps-access.md (companion — the existing DuckDNS deploy).


1. What deviant.x is (and isn't)

  • deviant.x is a name in the multi-TLD BNS system on Bitcoin Cash. BNS ("BCNR") mints a name as a CashToken name certificate with an OP_RETURN payload BNS1{o:REG, n:'deviant.x', r:records}. The certificate token IS the ownership proof — consensus enforces uniqueness (no registrar, no ICANN).
  • .x is one of the live TLDs. Multi-TLD went live 2026-07-25. The registry accepts any <label>.<tld>; verified TLDs currently include .bch, .p2p, .deviant, .bit, .de, .nav, .x, .silentmode. Adding a TLD is a single on-chain UPDATE against tlds.bch — every client picks it up without a software release. See SilentMode/Argus/DESIGN-root-tld-cert.md.
  • deviant.x is NOT ICANN. It's a chain-native name. To resolve it in a normal browser you need one of: Theseus Navigator (Electron browser with built-in resolver — dl.silentmode.st), the local bnsd resolver (D:\Dev\NameCoin\setup\install.ps1, Windows NRPT-based), or a public gateway (https://navigate.st/bns/deviant.x/).
  • Not the same as the current wallet URL. Today the wallet lives at https://testchipnet.duckdns.org/ on the shared VPS 130.12.242.84 (see D:\Dev\SilentMode\VPS\Deviant\vps-access.md). deviant.x is a second handle over the same or different content — the two coexist.

2. What "hosting" means on BNS — pick a storage backend

A BNS name's records tell a resolver where the bytes actually live. For deviant.x serving the wallet, the choices are:

Record Backend Fit for a wallet-sized SPA (~10 MB dist/)
h On-chain HTML — bytes IN the OP_RETURN payload / linked chain data. Bad. Only makes sense for tiny sites (a few KB, e.g. hello.bch). BCH data fees would be prohibitive for a wallet bundle.
s3 Sia decentralized storage via the local s3d gateway (S3-compatible). Best fit. Truly serverless; content addressed by bucket/prefix; already used by siatest.bch, coinspectrum.deviant.bch.
ip A specific IP the resolver fetches from over TLS. Simple but re-centralises to that box. Works today with 130.12.242.84.
p Reverse-proxy an upstream URL under the .x name. Simplest possible — point at https://testchipnet.duckdns.org/. Same centralisation caveat as ip.

Recommended path for the beta: s3 (Sia). Rationale:

  1. The whole point of BNS is nobody hosts the site — using s3 matches that promise. ip/p re-centralises to the DuckDNS VPS, which is fine as a fallback but defeats the value of registering deviant.x in the first place.
  2. The wallet is a fully static SPA — no backend, no dynamic pages. It's exactly the shape Sia serves cleanly.
  3. coinspectrum.deviant.bch is already deployed via Sia — same pattern works for deviant.x.

Fallback / interim: register deviant.x with an ip record pointing at 130.12.242.84 (or a p record proxying https://testchipnet.duckdns.org/) so the name resolves the moment it's minted. Add s3 later.

3. The three concrete tasks (operator-executed)

None of these can be executed from a Claude session — they need the operator's wallet, keys, or credentials. Each block is the exact commands to paste.

Task A — check availability + register deviant.x

Availability first:

node D:/Dev/SilentMode/Argus/src/resolve.js deviant.x
# expected on unregistered: "not found" / no such name

Register (requires the SilentMode wallet with ~ few thousand chipnet bits for the mint + fee):

# The wallet the mint spends from must hold funds; see
# D:/Dev/SilentMode/Argus/tools/README.md for wallet setup.
node D:/Dev/SilentMode/Argus/src/register.js \
  --name deviant.x \
  --records '{"p":"https://testchipnet.duckdns.org/"}'

The registrar mints the CashToken name certificate and writes the BNS1 REG payload. Confirmation on chipnet takes one block (~2–3 min in normal flow).

The exact register CLI flags may vary; consult D:\Dev\SilentMode\Argus\src\register.js (or run with --help) before use. The n: payload key is bare-label for .bch legacy names and <label>.<tld> for other TLDs per Decentralized.DNS/REGISTRATION-WALLET-PROMPT.md:38-39.

Task B — upload the wallet build to Sia (if choosing s3)

The wallet's static output is shells/app/dist/. Build it, then push to Sia via the local s3d bridge:

# 1. Build a fresh production bundle
cd D:/Dev/Deviant/shells/app
npm run build
# → dist/  (self-contained SPA + .htaccess + _headers + _redirects)

# 2. Ensure s3d is running with creds in sia-s3.json (see SIA-UPLOAD.md §0).
#    On the operator machine this is the "BNS Sia Bridge" scheduled task.

# 3. Upload the whole dist/ under bns/deviant/wallet/ (or similar prefix)
node D:/Dev/SilentMode/Argus/src/lib/sia-upload.js \
  D:/Dev/Deviant/shells/app/dist \
  bns/deviant/wallet

Notes:

  • sia-s3.json is a secret. Never commit / never publish. It's on the SilentMode never-ship list (SECURITY.md).
  • Sia uploads pack in the background; small files land in seconds, the full ~10 MB wallet bundle typically ready in under a minute.

Task C — point the name at the content

If registered with p (Task A) and later moving to s3, or if registered without records and setting them now:

node -e "import('./src/lib/bns.js').then(async m => {
  const { loadWallet } = await import('./src/lib/wallet.js');
  const w = await loadWallet();
  console.log(await m.updateName(w, 'deviant.x', { s3: 'bns/deviant/wallet/' }));
})"

s3 record with trailing slash → served as a site: deviant.x → bns/deviant/wallet/index.html, subpaths appended.

Task D — verify

Without installing anything:

# Public gateway — reads the resolver + the `s3` / `p` / `ip` record + serves it
curl -sI https://navigate.st/bns/deviant.x/
# expect: HTTP/2 200

Or in Theseus Navigator (dl.silentmode.st): open https://deviant.x directly — green padlock if tls record is set, plain-text if not.

4. What Claude sessions CANNOT do (and why)

  • Register the name — an on-chain BCH transaction spending real (chipnet or mainnet) funds. Per project safety rules, financial transactions require operator execution. The user, not Claude, runs Argus/src/register.js.
  • Read or use sia-s3.json — that file holds Sia access keys and is a secret. Claude does not touch it.
  • Set BNS records — same rationale as registration.
  • Assume a mainnet build — the wallet is currently chipnet-beta (⚠ test coins only — never fund with real BCH banner is baked in via buildInfo.ts). Registering deviant.x on mainnet BNS points at a chipnet wallet build — real users would connect with real funds and hit the wrong network. Discuss the network story before mainnet-pointing anything.

5. Coexistence with the existing DuckDNS deploy

SilentMode/VPS/Deviant/vps-access.md documents the current live wallet at https://testchipnet.duckdns.org/ (VPS 130.12.242.84, nginx bind-mount at /opt/checkers/nginx/html/deviant/). That deployment does not need to move. Two independent handles is fine:

  • Direct: https://testchipnet.duckdns.org/ — served by the VPS nginx, ICANN DNS
  • BNS: https://deviant.x — served via Sia (or proxied to the same VPS)

Both point to the same static build; whichever you deploy first stays. The BNS handle is the one that carries the "the wallet is namespaced on-chain" story.

6. Naming convention

The doc lives here (Deviant repo) because the Deviant wallet is what's being hosted. All the machinery lives in SilentMode. Read this side for why + user steps; read the SilentMode side for how the tooling works (protocol, resolver, Sia bridge, gateway):

  • Parameters/Hosting-DeviantX.md — this doc (Deviant-side reference)
  • D:\Dev\SilentMode\Decentralized.DNS\PROTOCOL.md — BNS1 protocol
  • D:\Dev\SilentMode\Decentralized.Hosting\SIA-UPLOAD.md — Sia upload steps
  • D:\Dev\SilentMode\VPS\Deviant\vps-access.md — the existing DuckDNS deploy

7. Decision points for the operator

Before executing anything, decide:

  1. Chipnet or mainnet BNS? The wallet's chipnet-beta warning banner applies either way, but if you register deviant.x on mainnet BNS it implies "this name is here to stay" — mainnet BNS is more expensive to mint and reclaiming/updating is a real cost.
  2. s3 or p? s3 is the honest decentralized answer; p is the pragmatic one that reuses the running VPS. You can start with p and move to s3 later via updateName.
  3. tls record? Without it, the browser will complain — for .x under Theseus the pin is tls in the records payload. Skip this in a first pass; the gateway (navigate.st) serves a browser-trusted cert.