fix(cuprate): front the restricted RPC port with a Tor onion

The restricted-RPC port (18090) was `auth: none`, which the app gate treats as fully exempt — no onion, no takeover, LAN/Tailscale IP only. Flip it to `auth: open`: the gate still binds the external addresses and fronts a Tor onion for the port, just without a dashboard login challenge, since Monero wallet clients (Feather, monero-wallet-rpc, GUI) speak plain HTTP JSON-RPC and can't hold a session cookie. P2P (18183) stays `none` — no reason to Tor-front raw gossip. Regenerated releases/app-catalog.json (unsigned) to embed the updated manifest; needs scripts/sign-catalog.sh before it takes effect on any node, since origin (catalog) wins over disk for catalog-covered apps. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01NZnsiMtyJxiJBuvv7yLPUF
fix(cuprate): enable fast_sync and raise DB cache — sustained 45% CPU
2026-09-03 14:51:24 +00:00 · 2026-09-03 08:56:52 +00:00 · 2026-09-01 19:01:54 -04:00
5 changed files with 3326 additions and 3342 deletions
@@ -45,7 +45,12 @@ app:
  resources:
    cpu_limit: 0
-    memory_limit: 4Gi
+    # Raised from 4Gi alongside target_max_memory below (see files[] comment)
    # — 2026-09-03 incident: a 4Gi/3GB-cache config starved
    # cuprated's DB cache into constant eviction/flush, driving 45% sustained
    # CPU and ~595GB/24h of block I/O on a fully-synced node. 10Gi leaves
    # headroom above the 8GiB cache for the process itself.
    memory_limit: 10Gi
    disk_limit: 300Gi
  security:
@@ -82,17 +87,21 @@ app:
    # bind without an explicit i_know_what_im_doing override.
    # Restricted RPC: Monero's own purpose-built safe-for-public subset —
    # what wallets use when connecting to a "remote node". Disabled by
-    # cuprated's own default; enabled via files[] below. A dashboard login
+    # cuprated's own default; enabled via files[] below. `open`, not `gated`:
-    # would break wallet clients connecting programmatically, same
+    # the gate still takes the port over (loopback pin, external binds,
-    # reasoning as electrumx's port. The daemon still uses its canonical
+    # fronts the Tor onion) but skips the dashboard login challenge, same
-    # container port 18089, but Penpot already owns host port 18089, so this
+    # reasoning as electrumx's port — wallet clients (Feather,
-    # maps the public host port to the free 18090 instead.
+    # monero-wallet-rpc, GUI) speak plain HTTP JSON-RPC programmatically and
    # cannot complete a browser login or hold a session cookie. The daemon
    # still uses its canonical container port 18089, but Penpot already owns
    # host port 18089, so this maps the public host port to the free 18090
    # instead.
    - host: 18090
      container: 18089
      protocol: tcp
-      auth: none
+      auth: open
      auth_rationale: >-
-        Monero restricted RPC — the subset upstream considers safe for public/remote-node use. Wallets (Feather, monero-wallet-rpc, GUI) connect directly over plain HTTP JSON-RPC and cannot hold a dashboard session cookie.
+        Monero restricted RPC — the subset upstream considers safe for public/remote-node use. Wallets (Feather, monero-wallet-rpc, GUI) connect directly over plain HTTP JSON-RPC and cannot complete a browser login or hold a dashboard session cookie.
  volumes:
    - type: bind
@@ -103,11 +112,23 @@ app:
  # Settings that need to differ from cuprated's own documented defaults
  # (verified against `cuprated --generate-config` and `--dry-run` locally,
  # 2026-08-21):
  #   - fast_sync: cuprated's own default is false, which performs full
  #     cryptographic verification (ring signatures + RandomX PoW) on every
  #     incoming block instead of trusting checkpointed history. Root-caused
  #     2026-09-03 as the dominant cause of a sustained 45% CPU node,
  #     vs. 2.8% on a reference node with fast_sync = true — same chain height, same
  #     block rate. Set explicitly rather than relying on the binary
  #     default so fresh deploys don't silently regress into full-verify.
  #   - target_max_memory: cuprated's own default auto-detects total *host*
  #     RAM via sysinfo, which inside a memory-limited container would let
  #     it size caches far past what resources.memory_limit above actually
  #     grants — same class of problem bitcoin-knots' -dbcache sizing
-  #     comment addresses. Set explicitly, comfortably under the 4Gi limit.
+  #     comment addresses. Set explicitly, comfortably under the 10Gi limit.
  #     Previously 3000000000 (~2.8GiB); that starved the DB cache and
  #     forced constant eviction/flush (595GB/24h block I/O on a node just
  #     appending ~2MB blocks every 2 minutes) — raised to 8GiB, matching
  #     the healthy reference node, and
  #     resources.memory_limit above raised in step to keep headroom above it.
  #   - rpc.restricted.enable: cuprated ships this off by default; flip on
  #     so the auth:none host port above actually serves something instead
  #     of refusing every connection. port stays at its documented default
@@ -128,21 +149,21 @@ app:
  #   - tracing.stdout.level / tracing.file.{level,max_log_files}: an
  #     operator reading Cuprated.toml on disk should be able to see and
  #     tune the log level directly instead of the file silently omitting
-  #     the whole [tracing] table (verified live on amishparadise
+  #     the whole [tracing] table (verified live on the affected node
  #     2026-09-01: the deployed file had no [tracing] section at all, and
  #     the level was only discoverable by running `cuprated
  #     --generate-config` and diffing). file.level is set to "info", NOT
  #     cuprated's own raw default of "debug" — matches the reference dev
-  #     config this app was built and tested against
+  #     config this app was built and tested against (verified 2026-09-01),
-  #     (ssmithx@archy-dev-pa:/home/ssmithx/cuprate/Cuprated.toml,
+  #     which deliberately runs file logging quieter
  #     verified 2026-09-01), which deliberately runs file logging quieter
  #     than the binary default. max_log_files similarly follows that
  #     reference (14, not the binary default of 7).
  files:
    - path: /var/lib/archipelago/cuprate/Cuprated.toml
      content: |
        network = "Mainnet"
-        target_max_memory = 3000000000
+        fast_sync = true
        target_max_memory = 8589934592
        [rpc.restricted]
        enable = true
@@ -1,32 +1,29 @@
 {
  "changelog": [
-    "**Lightning sends work again after the LND 0.21.2 update.** LND 0.21 removed the old synchronous payment route the node's backend paid through (`/v1/channels/transactions`) — every Lightning send answered the literal \"Not Found\" and the wallet showed \"Payment failed: Not Found\". The backend now pays through the supported Router.SendPaymentV2 route, keeps the same settle-then-report behaviour (a slow multi-hop payment is still tracked to completion, never falsely declared failed), and translates LND's failure reasons into plain advice. A new gate test speaks the payment route directly against the running LND, so an image/backend skew like this can never ship silently again.",
+    "**Lightning sends work again — v1.8.9's payment switch lost the fee budget.** Moving payments to LND 0.21's supported route (Router.SendPaymentV2) shipped without a fee limit, and the v2 API treats an absent limit as **zero allowed fees**: every real route carries a routing fee, so the pathfinder rejected them all and the wallet answered \"No route to the recipient\" on every send — all day, on healthy channels with plenty of liquidity. The router debug log made it unambiguous (`fee_limit=0 mSAT` on every failing wallet payment; the same payment succeeded by hand the moment a fee limit was set). Payments now carry lncli's default budget (the payment amount), the wallet's amount handling for zero-value invoices is preserved, and a unit test pins the limit can never be zero again.",
-    "**The node no longer pins HSTS — HTTP access is a supported mode, and it stays working.** The HTTPS listener used to send `Strict-Transport-Security: max-age=31536000; includeSubDomains`; browsers that visited HTTPS once cached that and then silently upgraded the still-open HTTP dashboard's calls to HTTPS, which is a scheme change — cross-origin — so every request died as \"CORS blocked / Failed to fetch\" while the node was perfectly healthy. The HTTPS listener now actively clears the cached policy (`max-age=0`) and port 80 sends no HSTS at all, which is deliberate: the node's certificate is optional and self-signed, and devices that haven't installed the CA must keep plain-HTTP access (that's what Settings → Node certificate is for). If your browser already cached the old policy, visiting the dashboard over HTTPS once after this update clears it; a gate test now refuses any config that reintroduces the pin.",
+    "**A channel that drops its peer link now heals itself — on every node.** Restarting LND (an app update, a reboot, container churn) can leave a channel's peer connection down for hours while both endpoints keep the channel flagged disabled in the routing graph: the node looks perfectly healthy, the wallet shows balance, and every payment in either direction fails \"no route to the recipient\". Observed live: a node's only channel sat unroutable for ~17 hours after the LND 0.21.2 update, with no sign of it in any dashboard. The daemon now watches the channel graph as desired state — every open channel should have a live peer — and reconnects any that don't, using the peer's advertised addresses. Nodes without LND are untouched; an unreachable peer is retried gently, not hammered.",
-    "**App frames open over HTTPS again — including the ones that \"did not connect.\"** The launcher asked the signed catalog for each app's port policy under the name you click (\"Mempool Web\", \"Bitcoin Knots\"), but the catalog declares those ports under the manifest that owns them (the Mempool web container, Bitcoin UI). The lookup missed, the launcher handed the iframe an `http://` address, and the browser blocked it as mixed content — the app tile went blank or spun forever. Port resolution now follows launch aliases (mempool-web, bitcoin-knots/bitcoin-core, lnd, electrs and friends), falls back to a port-wide catalog scan when the id is unknown, and the catalog is warmed as soon as the dashboard loads rather than only in the App Store, so the very first app you open already knows which ports serve TLS.",
+    "**The Lightning wallet states the node's real funding state instead of \"you have no channel.\"** Trying to send while a freshly opened channel was still waiting for on-chain confirmations — or when all its balance sits on the far side — raised a modal that claimed the node had NO channel at all (the outbound sum is legitimately zero in both states), pointed the user at opening a second channel, and — for payment routing failures — even showed the *receiving* copy. The funding gate now reads the channel list it already fetched: a confirming channel gets \"it unlocks automatically once confirmed, nothing is needed from you\", a far-side balance gets \"you can receive, but there's nothing to send right now\", a routing/liquidity payment failure says so instead of claiming channel problems, and only a genuinely channel-less node keeps the open-one guidance."
    "**Signing in to IndeeHub with Nostr works over HTTPS.** The NIP-07 bridge compared the app frame's origin for exact equality with the recorded `http://` app URL — a frame the browser upgraded to HTTPS (or any scheme change) was silently ignored, and replies addressed to the stale origin were refused outright, so Nostr sign-in quietly did nothing. The bridge now matches host and port (scheme intentionally ignored) and always replies to the frame's real origin.",
    "**Nginx Proxy Manager starts again.** Converting it to a platform manifest dropped two things its image needs: the `/etc/letsencrypt` mount its boot script hard-requires, and the `NET_BIND_SERVICE` capability its internal nginx needs to bind ports 80/443/81 under the orchestrator's `--cap-drop=ALL`. The result was an endless start/die loop (a node watched it restart 3,176 times). Both are declared in its manifest now, its certs live on unchanged under the same persistent app directory, and the signed catalog carries the fix so installed nodes heal on the next update.",
    "**Portainer's first-run token is in the app page, not buried in \"server logs.\"** New Portainer versions mint a one-time setup token on a fresh install and print it only to the container logs — on an appliance that meant telling the user to go read a server log to get into their own app. The token now appears in the same launch interstitial as app login credentials (with a copy button), only while first-run setup is actually pending; once the admin account exists the card disappears on its own."
  ],
  "components": [
    {
-      "current_version": "1.8.9-alpha",
+      "current_version": "1.8.10-alpha",
-      "download_url": "https://source.archipelago-foundation.org/lfg2025/archy/releases/download/v1.8.9-alpha/archipelago",
+      "download_url": "https://source.archipelago-foundation.org/lfg2025/archy/releases/download/v1.8.10-alpha/archipelago",
      "name": "archipelago",
-      "new_version": "1.8.9-alpha",
+      "new_version": "1.8.10-alpha",
-      "sha256": "39795958963680f56763e3c05e3fe0cd589c30edd9a09416ad325bab4c862123",
+      "sha256": "6c8bd41fed44cd999cb360c00e1b66a2d19d19812cc2b0c8a1677eec2a9579e6",
-      "size_bytes": 64139152
+      "size_bytes": 64178056
    },
    {
-      "current_version": "1.8.9-alpha",
+      "current_version": "1.8.10-alpha",
-      "download_url": "https://source.archipelago-foundation.org/lfg2025/archy/releases/download/v1.8.9-alpha/archipelago-frontend-1.8.9-alpha.tar.gz",
+      "download_url": "https://source.archipelago-foundation.org/lfg2025/archy/releases/download/v1.8.10-alpha/archipelago-frontend-1.8.10-alpha.tar.gz",
-      "name": "archipelago-frontend-1.8.9-alpha.tar.gz",
+      "name": "archipelago-frontend-1.8.10-alpha.tar.gz",
-      "new_version": "1.8.9-alpha",
+      "new_version": "1.8.10-alpha",
-      "sha256": "624dd10dfea09809be1fdddc7eac804e1fde66ff3d552cb90d56d9ac550ed944",
+      "sha256": "6b25de8a8e1a4f7fe51594f9bbbe21f5820f417af47a8b309c2dbf8f8723b719",
-      "size_bytes": 97734650
+      "size_bytes": 97736297
    }
  ],
  "release_date": "2026-09-01",
-  "signature": "d7d724b910e827651240bd9520102d66932b57a8a8d674ef645c45eb77f78c123fb45d294ec07f8bbfc3713ed9bd9f98096f59ff18cd6098df51aa473e771908",
+  "signature": "b69926bcb1851ff7d6a5b24519cd4a8015aab4ed4b588ee989d8ce6e3beaeb2cc0eb38078f522ded0d389fe53b7dbcdbf3f40c534b4bfafa5cf4a2ab2c59e40f",
  "signed_by": "did:key:z6Mkfu5LT8d4DjETtrkATvHh9Dvcbnr7zBCUwfau8Sw7DLWT",
-  "version": "1.8.9-alpha"
+  "version": "1.8.10-alpha"
 }
@@ -1,32 +1,29 @@
 {
  "changelog": [
-    "**Lightning sends work again after the LND 0.21.2 update.** LND 0.21 removed the old synchronous payment route the node's backend paid through (`/v1/channels/transactions`) — every Lightning send answered the literal \"Not Found\" and the wallet showed \"Payment failed: Not Found\". The backend now pays through the supported Router.SendPaymentV2 route, keeps the same settle-then-report behaviour (a slow multi-hop payment is still tracked to completion, never falsely declared failed), and translates LND's failure reasons into plain advice. A new gate test speaks the payment route directly against the running LND, so an image/backend skew like this can never ship silently again.",
+    "**Lightning sends work again — v1.8.9's payment switch lost the fee budget.** Moving payments to LND 0.21's supported route (Router.SendPaymentV2) shipped without a fee limit, and the v2 API treats an absent limit as **zero allowed fees**: every real route carries a routing fee, so the pathfinder rejected them all and the wallet answered \"No route to the recipient\" on every send — all day, on healthy channels with plenty of liquidity. The router debug log made it unambiguous (`fee_limit=0 mSAT` on every failing wallet payment; the same payment succeeded by hand the moment a fee limit was set). Payments now carry lncli's default budget (the payment amount), the wallet's amount handling for zero-value invoices is preserved, and a unit test pins the limit can never be zero again.",
-    "**The node no longer pins HSTS — HTTP access is a supported mode, and it stays working.** The HTTPS listener used to send `Strict-Transport-Security: max-age=31536000; includeSubDomains`; browsers that visited HTTPS once cached that and then silently upgraded the still-open HTTP dashboard's calls to HTTPS, which is a scheme change — cross-origin — so every request died as \"CORS blocked / Failed to fetch\" while the node was perfectly healthy. The HTTPS listener now actively clears the cached policy (`max-age=0`) and port 80 sends no HSTS at all, which is deliberate: the node's certificate is optional and self-signed, and devices that haven't installed the CA must keep plain-HTTP access (that's what Settings → Node certificate is for). If your browser already cached the old policy, visiting the dashboard over HTTPS once after this update clears it; a gate test now refuses any config that reintroduces the pin.",
+    "**A channel that drops its peer link now heals itself — on every node.** Restarting LND (an app update, a reboot, container churn) can leave a channel's peer connection down for hours while both endpoints keep the channel flagged disabled in the routing graph: the node looks perfectly healthy, the wallet shows balance, and every payment in either direction fails \"no route to the recipient\". Observed live: a node's only channel sat unroutable for ~17 hours after the LND 0.21.2 update, with no sign of it in any dashboard. The daemon now watches the channel graph as desired state — every open channel should have a live peer — and reconnects any that don't, using the peer's advertised addresses. Nodes without LND are untouched; an unreachable peer is retried gently, not hammered.",
-    "**App frames open over HTTPS again — including the ones that \"did not connect.\"** The launcher asked the signed catalog for each app's port policy under the name you click (\"Mempool Web\", \"Bitcoin Knots\"), but the catalog declares those ports under the manifest that owns them (the Mempool web container, Bitcoin UI). The lookup missed, the launcher handed the iframe an `http://` address, and the browser blocked it as mixed content — the app tile went blank or spun forever. Port resolution now follows launch aliases (mempool-web, bitcoin-knots/bitcoin-core, lnd, electrs and friends), falls back to a port-wide catalog scan when the id is unknown, and the catalog is warmed as soon as the dashboard loads rather than only in the App Store, so the very first app you open already knows which ports serve TLS.",
+    "**The Lightning wallet states the node's real funding state instead of \"you have no channel.\"** Trying to send while a freshly opened channel was still waiting for on-chain confirmations — or when all its balance sits on the far side — raised a modal that claimed the node had NO channel at all (the outbound sum is legitimately zero in both states), pointed the user at opening a second channel, and — for payment routing failures — even showed the *receiving* copy. The funding gate now reads the channel list it already fetched: a confirming channel gets \"it unlocks automatically once confirmed, nothing is needed from you\", a far-side balance gets \"you can receive, but there's nothing to send right now\", a routing/liquidity payment failure says so instead of claiming channel problems, and only a genuinely channel-less node keeps the open-one guidance."
    "**Signing in to IndeeHub with Nostr works over HTTPS.** The NIP-07 bridge compared the app frame's origin for exact equality with the recorded `http://` app URL — a frame the browser upgraded to HTTPS (or any scheme change) was silently ignored, and replies addressed to the stale origin were refused outright, so Nostr sign-in quietly did nothing. The bridge now matches host and port (scheme intentionally ignored) and always replies to the frame's real origin.",
    "**Nginx Proxy Manager starts again.** Converting it to a platform manifest dropped two things its image needs: the `/etc/letsencrypt` mount its boot script hard-requires, and the `NET_BIND_SERVICE` capability its internal nginx needs to bind ports 80/443/81 under the orchestrator's `--cap-drop=ALL`. The result was an endless start/die loop (a node watched it restart 3,176 times). Both are declared in its manifest now, its certs live on unchanged under the same persistent app directory, and the signed catalog carries the fix so installed nodes heal on the next update.",
    "**Portainer's first-run token is in the app page, not buried in \"server logs.\"** New Portainer versions mint a one-time setup token on a fresh install and print it only to the container logs — on an appliance that meant telling the user to go read a server log to get into their own app. The token now appears in the same launch interstitial as app login credentials (with a copy button), only while first-run setup is actually pending; once the admin account exists the card disappears on its own."
  ],
  "components": [
    {
-      "current_version": "1.8.9-alpha",
+      "current_version": "1.8.10-alpha",
-      "download_url": "https://source.archipelago-foundation.org/lfg2025/archy/releases/download/v1.8.9-alpha/archipelago",
+      "download_url": "https://source.archipelago-foundation.org/lfg2025/archy/releases/download/v1.8.10-alpha/archipelago",
      "name": "archipelago",
-      "new_version": "1.8.9-alpha",
+      "new_version": "1.8.10-alpha",
-      "sha256": "39795958963680f56763e3c05e3fe0cd589c30edd9a09416ad325bab4c862123",
+      "sha256": "6c8bd41fed44cd999cb360c00e1b66a2d19d19812cc2b0c8a1677eec2a9579e6",
-      "size_bytes": 64139152
+      "size_bytes": 64178056
    },
    {
-      "current_version": "1.8.9-alpha",
+      "current_version": "1.8.10-alpha",
-      "download_url": "https://source.archipelago-foundation.org/lfg2025/archy/releases/download/v1.8.9-alpha/archipelago-frontend-1.8.9-alpha.tar.gz",
+      "download_url": "https://source.archipelago-foundation.org/lfg2025/archy/releases/download/v1.8.10-alpha/archipelago-frontend-1.8.10-alpha.tar.gz",
-      "name": "archipelago-frontend-1.8.9-alpha.tar.gz",
+      "name": "archipelago-frontend-1.8.10-alpha.tar.gz",
-      "new_version": "1.8.9-alpha",
+      "new_version": "1.8.10-alpha",
-      "sha256": "624dd10dfea09809be1fdddc7eac804e1fde66ff3d552cb90d56d9ac550ed944",
+      "sha256": "6b25de8a8e1a4f7fe51594f9bbbe21f5820f417af47a8b309c2dbf8f8723b719",
-      "size_bytes": 97734650
+      "size_bytes": 97736297
    }
  ],
  "release_date": "2026-09-01",
-  "signature": "d7d724b910e827651240bd9520102d66932b57a8a8d674ef645c45eb77f78c123fb45d294ec07f8bbfc3713ed9bd9f98096f59ff18cd6098df51aa473e771908",
+  "signature": "b69926bcb1851ff7d6a5b24519cd4a8015aab4ed4b588ee989d8ce6e3beaeb2cc0eb38078f522ded0d389fe53b7dbcdbf3f40c534b4bfafa5cf4a2ab2c59e40f",
  "signed_by": "did:key:z6Mkfu5LT8d4DjETtrkATvHh9Dvcbnr7zBCUwfau8Sw7DLWT",
-  "version": "1.8.9-alpha"
+  "version": "1.8.10-alpha"
 }
@@ -1,29 +0,0 @@
 {
  "changelog": [
    "**Lightning sends work again — v1.8.9's payment switch lost the fee budget.** Moving payments to LND 0.21's supported route (Router.SendPaymentV2) shipped without a fee limit, and the v2 API treats an absent limit as **zero allowed fees**: every real route carries a routing fee, so the pathfinder rejected them all and the wallet answered \"No route to the recipient\" on every send — all day, on healthy channels with plenty of liquidity. The router debug log made it unambiguous (`fee_limit=0 mSAT` on every failing wallet payment; the same payment succeeded by hand the moment a fee limit was set). Payments now carry lncli's default budget (the payment amount), the wallet's amount handling for zero-value invoices is preserved, and a unit test pins the limit can never be zero again.",
    "**A channel that drops its peer link now heals itself — on every node.** Restarting LND (an app update, a reboot, container churn) can leave a channel's peer connection down for hours while both endpoints keep the channel flagged disabled in the routing graph: the node looks perfectly healthy, the wallet shows balance, and every payment in either direction fails \"no route to the recipient\". Observed live: a node's only channel sat unroutable for ~17 hours after the LND 0.21.2 update, with no sign of it in any dashboard. The daemon now watches the channel graph as desired state — every open channel should have a live peer — and reconnects any that don't, using the peer's advertised addresses. Nodes without LND are untouched; an unreachable peer is retried gently, not hammered.",
    "**The Lightning wallet states the node's real funding state instead of \"you have no channel.\"** Trying to send while a freshly opened channel was still waiting for on-chain confirmations — or when all its balance sits on the far side — raised a modal that claimed the node had NO channel at all (the outbound sum is legitimately zero in both states), pointed the user at opening a second channel, and — for payment routing failures — even showed the *receiving* copy. The funding gate now reads the channel list it already fetched: a confirming channel gets \"it unlocks automatically once confirmed, nothing is needed from you\", a far-side balance gets \"you can receive, but there's nothing to send right now\", a routing/liquidity payment failure says so instead of claiming channel problems, and only a genuinely channel-less node keeps the open-one guidance."
  ],
  "components": [
    {
      "current_version": "1.8.10-alpha",
      "download_url": "https://source.archipelago-foundation.org/lfg2025/archy/releases/download/v1.8.10-alpha/archipelago",
      "name": "archipelago",
      "new_version": "1.8.10-alpha",
      "sha256": "6c8bd41fed44cd999cb360c00e1b66a2d19d19812cc2b0c8a1677eec2a9579e6",
      "size_bytes": 64178056
    },
    {
      "current_version": "1.8.10-alpha",
      "download_url": "https://source.archipelago-foundation.org/lfg2025/archy/releases/download/v1.8.10-alpha/archipelago-frontend-1.8.10-alpha.tar.gz",
      "name": "archipelago-frontend-1.8.10-alpha.tar.gz",
      "new_version": "1.8.10-alpha",
      "sha256": "6b25de8a8e1a4f7fe51594f9bbbe21f5820f417af47a8b309c2dbf8f8723b719",
      "size_bytes": 97736297
    }
  ],
  "release_date": "2026-09-01",
  "signature": "b69926bcb1851ff7d6a5b24519cd4a8015aab4ed4b588ee989d8ce6e3beaeb2cc0eb38078f522ded0d389fe53b7dbcdbf3f40c534b4bfafa5cf4a2ab2c59e40f",
  "signed_by": "did:key:z6Mkfu5LT8d4DjETtrkATvHh9Dvcbnr7zBCUwfau8Sw7DLWT",
  "version": "1.8.10-alpha"
 }