blackbeard/qapi
1
0
Fork 0
Code Issues 4 Pull Requests Actions Packages Projects Releases Wiki Activity

Point the console at Quantus chains, and decide whether to deploy it #3

New Issue
Open
opened 2026-09-10 10:38:26 +00:00 by grenade · 1 comment
grenade commented 2026-09-10 10:38:26 +00:00
Owner
Copy Link

Depends on #1. Context: quantus/extension#1.

Chain config

The console needs Quantus in its chain list — a WS endpoint, SS58 prefix 189, token symbol and decimals. Both a local dev node and wss://a1-planck.quantus.cat (the endpoint quantus-apps generates its polkadart bindings from) should be selectable, because the two answer different questions: the local node is where you can fund an account and break things, the public one is where you find out whether the real runtime agrees.

Record the spec version of whatever you point it at. The signing context switches at spec 148 (quantus/common#5), so "which spec is this node" is the first question to ask when a signature is rejected.

Deploy or run locally?

Local pnpm dev is the right default while implementing — the whole point of choosing this over polkadot-js/apps is a fast rebuild, and a deployed instance adds a push-and-wait to every iteration.

Deploy when it becomes worth sharing — when someone other than the person writing the extension needs to reproduce a signing failure. House conventions for that are in ~/git/architecture: deployment-gitea-actions.md, port-allocations.md, reverse-proxies.md and external-tls.md/internal-tls.md.

One thing to get right if it is deployed: a page served over HTTPS cannot open a plain ws:// connection, so a deployed console can only reach a node with wss://. That rules out talking to a local dev node from a deployed instance, which is another reason the dev loop stays local.

Licence

Upstream is AGPL-3.0, and the AGPL's network clause means a publicly reachable modified instance must offer its source to users. This fork is public, which satisfies it — but if a deployment ever goes behind auth or the fork is made private, that obligation needs revisiting deliberately rather than by accident. Keep the upstream LICENSE intact and note the fork's origin in the README.

Also keep a git remote for polkadot-api/papi-console. Our change is a pnpm patch plus config (#1), so pulling upstream should stay cheap — and papi moves quickly enough that it is worth actually doing.

Depends on #1. Context: quantus/extension#1. ## Chain config The console needs Quantus in its chain list — a WS endpoint, SS58 prefix 189, token symbol and decimals. Both a local dev node and `wss://a1-planck.quantus.cat` (the endpoint `quantus-apps` generates its polkadart bindings from) should be selectable, because the two answer different questions: the local node is where you can fund an account and break things, the public one is where you find out whether the real runtime agrees. Record the spec version of whatever you point it at. The signing context switches at spec 148 (quantus/common#5), so "which spec is this node" is the first question to ask when a signature is rejected. ## Deploy or run locally? Local `pnpm dev` is the right default while implementing — the whole point of choosing this over polkadot-js/apps is a fast rebuild, and a deployed instance adds a push-and-wait to every iteration. Deploy when it becomes worth *sharing* — when someone other than the person writing the extension needs to reproduce a signing failure. House conventions for that are in `~/git/architecture`: `deployment-gitea-actions.md`, `port-allocations.md`, `reverse-proxies.md` and `external-tls.md`/`internal-tls.md`. One thing to get right if it is deployed: a page served over HTTPS cannot open a plain `ws://` connection, so a deployed console can only reach a node with `wss://`. That rules out talking to a local dev node from a deployed instance, which is another reason the dev loop stays local. ## Licence Upstream is **AGPL-3.0**, and the AGPL's network clause means a publicly reachable modified instance must offer its source to users. This fork is public, which satisfies it — but if a deployment ever goes behind auth or the fork is made private, that obligation needs revisiting deliberately rather than by accident. Keep the upstream `LICENSE` intact and note the fork's origin in the README. Also keep a `git remote` for `polkadot-api/papi-console`. Our change is a pnpm patch plus config (#1), so pulling upstream should stay cheap — and papi moves quickly enough that it is worth actually doing.
grenade commented 2026-09-16 17:51:52 +00:00
Author
Owner
Copy Link

Checked against main and the live site. The chains and the deployment are done; three small items remain.

Met:

  • Chains configured: Quantus mainnet, Heisenberg and Planck (both endpoints each, with symbol and 12 decimals, in networks/quantus.json), plus Localhost for a dev node. Prefix 189 comes from the runtime.
  • Deploy decision taken and done: 99483d9 (deploy.yaml, infra-setup.sh). https://qapi.blackbeard.observer serves the current build.
  • Upstream licence intact: AGPL-3.0, and the README links the upstream.

Remaining:

  1. Record each endpoint's spec version, in the README or the chain config. At the time of writing: mainnet 152, Heisenberg 148, Planck 148.
  2. Add a polkadot-api/papi-console upstream remote. Also fix the local origin, which still points at the old quantus/papi-console path rather than blackbeard/qapi.
  3. Optional: a README line on the AGPL obligation (source must be offered to users of the deployed console), to revisit if it ever goes behind auth or private.

The issue's point about wss-only from a deployed page was never written down, and may not hold: browsers generally allow ws://127.0.0.1 from an https page, so a deployed console may reach a local node.

Checked against `main` and the live site. The chains and the deployment are done; three small items remain. **Met:** - **Chains configured:** Quantus mainnet, Heisenberg and Planck (both endpoints each, with symbol and 12 decimals, in `networks/quantus.json`), plus Localhost for a dev node. Prefix 189 comes from the runtime. - **Deploy decision taken and done:** `99483d9` (`deploy.yaml`, `infra-setup.sh`). https://qapi.blackbeard.observer serves the current build. - **Upstream licence intact:** AGPL-3.0, and the README links the upstream. **Remaining:** 1. **Record each endpoint's spec version,** in the README or the chain config. At the time of writing: mainnet 152, Heisenberg 148, Planck 148. 2. **Add a `polkadot-api/papi-console` upstream remote.** Also fix the local `origin`, which still points at the old `quantus/papi-console` path rather than `blackbeard/qapi`. 3. **Optional:** a README line on the AGPL obligation (source must be offered to users of the deployed console), to revisit if it ever goes behind auth or private. The issue's point about wss-only from a deployed page was never written down, and may not hold: browsers generally allow `ws://127.0.0.1` from an https page, so a deployed console may reach a local node.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
No items
No Label
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
grenade
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: blackbeard/qapi#3
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?