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> @
9.7 KiB
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.xis 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 payloadBNS1{o:REG, n:'deviant.x', r:records}. The certificate token IS the ownership proof — consensus enforces uniqueness (no registrar, no ICANN)..xis 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 againsttlds.bch— every client picks it up without a software release. SeeSilentMode/Argus/DESIGN-root-tld-cert.md.deviant.xis 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 localbnsdresolver (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 VPS130.12.242.84(seeD:\Dev\SilentMode\VPS\Deviant\vps-access.md).deviant.xis 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:
- The whole point of BNS is nobody hosts the site — using
s3matches that promise.ip/pre-centralises to the DuckDNS VPS, which is fine as a fallback but defeats the value of registeringdeviant.xin the first place. - The wallet is a fully static SPA — no backend, no dynamic pages. It's exactly the shape Sia serves cleanly.
coinspectrum.deviant.bchis already deployed via Sia — same pattern works fordeviant.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. Then:payload key is bare-label for.bchlegacy names and<label>.<tld>for other TLDs perDecentralized.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.jsonis 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 BCHbanner is baked in viabuildInfo.ts). Registeringdeviant.xon 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 protocolD:\Dev\SilentMode\Decentralized.Hosting\SIA-UPLOAD.md— Sia upload stepsD:\Dev\SilentMode\VPS\Deviant\vps-access.md— the existing DuckDNS deploy
7. Decision points for the operator
Before executing anything, decide:
- Chipnet or mainnet BNS? The wallet's chipnet-beta warning banner
applies either way, but if you register
deviant.xon mainnet BNS it implies "this name is here to stay" — mainnet BNS is more expensive to mint and reclaiming/updating is a real cost. s3orp?s3is the honest decentralized answer;pis the pragmatic one that reuses the running VPS. You can start withpand move tos3later viaupdateName.tlsrecord? Without it, the browser will complain — for.xunder Theseus the pin istlsin the records payload. Skip this in a first pass; the gateway (navigate.st) serves a browser-trusted cert.