pmtiles-swarm 0.90.0 → 0.92.0

package/CHANGELOG.md

@@ -7,6 +7,83 @@
 ### 🐞 Bug fixes
 - _...Add new stuff here..._
 
+## 0.92.0
+### 🐞 Bug fixes
+- **A stack's TileJSON published the addresses its sources are read from.** A URL source is named by
+  its URL and an S3 source by its bucket and key, and the document naming them is served to anybody
+  who can load the map — while the archives at the other end are read with credentials nobody else
+  has. The sources are gone from it entirely, which was the right answer anyway: they are the
+  ingredients of one endpoint, not a list for a client to join, and listing them invited fetching
+  those instead of the tiles. What is left is a count and a `revision` fingerprint covering the
+  recipe and what every source resolved to — the one thing the list was good for, in twenty bytes
+  rather than tens of kilobytes. The document for a 459-source stack is now 336 bytes.
+
+- **Signing in threw away the view you asked for.** A link to `#stacks` on a guarded node asked for a
+  password and then showed the archives, with the address still reading `#stacks` — which is what
+  made it look broken rather than like a redirect. Both ways into the console now land where the
+  address says.
+
+- **An archive the engine has no record of was drawn as 0%.** That is a different fact from "none of
+  it is here", and it is the more alarming one to get wrong: a library the engine failed to take back
+  after a restart read as a library that had lost its data. The row now says **not loaded**, and says
+  where the reason is logged and that nothing on disk has been touched.
+
+## 0.91.0
+### ✨ Features and improvements
+- **A source at a URL can be added by hand, not only imported.** **Add source → an address you
+  type…** in the stack editor, writing the same source the importer does. The card asks for the
+  address and for the zoom range the archive holds — a catalog archive states its range in its own
+  header and this has no header anybody has read, so leaving it empty means every tile asks it.
+  Anything published as a plain HTTPS download works, an S3 object or presigned URL included, and so
+  does `s3://bucket/key.pmtiles` for a private bucket — see below.
+
+- **A stack's source list folds up past five sources.** An imported list is several hundred rows,
+  which buried every other stack on the page under one of them. The fold says how many there are and
+  names the base; a stack of a base and a layer or two stays open, since folding that hides nothing
+  worth a click.
+
+
+- **A stack source may be an object in a private S3 bucket.**
+  `s3://bucket/terrain.pmtiles`, read with a signed request per byte range. Only for a bucket that is
+  not public — a public object or a presigned URL is an ordinary HTTPS address and always worked.
+  `endpoint` is what makes it S3-compatible rather than S3: MinIO, Ceph, Garage, R2, Wasabi and B2
+  all answer the same protocol at their own address, and path-style addressing is the default because
+  it is what they speak. Credentials go under **Settings → Feeds → S3 buckets**, per bucket or once
+  for an account; with none configured the standard `AWS_ACCESS_KEY_ID`, `AWS_SECRET_ACCESS_KEY`,
+  `AWS_REGION` and `AWS_S3_ENDPOINT` variables are read, so a machine already set up to reach a
+  bucket needs nothing typed in.
+
+  Signed here rather than by an SDK: SigV4 for a GET is a hash, four HMACs and a string, all of which
+  `node:crypto` has. An AWS client would be a large dependency for one signature, and an optional one
+  would make reading a bucket work on some installs and not on others for no reason the operator
+  could see — so it is neither optional nor a dependency. The signer is checked against AWS's own
+  published test vectors rather than against itself.
+
+
+### 🐞 Bug fixes
+- **A stack of remote sources could be served but not exported.** The bake refused any stack whose
+  sources resolved to no archive on this node, which is every stack read from URLs — refusing exactly
+  the export worth having, since baking is how terrain that lives somewhere else becomes something
+  this node holds and can seed. It also had no way to walk a remote archive's directories, which is
+  how a bake finds which tiles exist at all.
+
+- **An archive whose deepest tiles repeat said it stopped a zoom short.** Identical tiles collapse
+  into one directory entry covering a range of ids, so the last entry's own id can sit at a shallower
+  zoom than the tiles it addresses — and the header was read off that id. A client asks for nothing
+  past a header's `maxZoom`, so the deepest zoom of such an archive was unreachable. Found baking a
+  stack over flat terrain, where every tile of the last zoom was the same tile.
+
+- **A stack used as a source of another stack was reported as unresolved.** It resolves to a recipe
+  rather than to bytes, and the console's reader looked only for a catalog entry or an address — so a
+  working nested stack showed "does not resolve", with no zoom range and no box, and put a "sources
+  missing" badge on the stack above it. It now says what it stands for and how deep it reaches,
+  worked out from the sources that stack would serve.
+
+- **A stack's advertised box ignored any source that stated none.** The union was taken over
+  whichever sources had a box, so a stack of a global base plus regional patches — an imported list,
+  exactly — advertised the patches as its extent and left the base out of it. A source with no box
+  is not one covering nothing, so it is now every box or none, and none means the world.
+
 ## 0.90.0
 ### ✨ Features and improvements
 - **A stack source may name a URL instead of a category, archive or stack.** `{ "url": "https://…" }`,

package/docs/configuration.md

@@ -20,6 +20,7 @@ Some settings only take effect on restart. Those are marked **restart**.
 - [Scheduled sources](#scheduled-sources)
 - [Subscriptions](#subscriptions)
 - [Serving tiles](#serving-tiles)
+- [S3 buckets](#s3-buckets)
 - [Mutable publishing](#mutable-publishing)
 - [Authentication](#authentication)
 - [Statistics](#statistics)
@@ -776,6 +777,96 @@ connection, a piece already in flight. Ten attempts later it is one piece at the
 far end of an archive nobody has finished, and asking every fifteen seconds
 achieves nothing but log lines.
 
+## S3 buckets
+
+A stack source may be an address rather than an archive this node holds, and
+that address may name an object in a bucket:
+
+```json
+{
+  "sources": [{ "url": "s3://terrain/planet.pmtiles", "encoding": "terrarium" }]
+}
+```
+
+Only for a bucket that is **not public**. A public object, or a presigned URL,
+is an ordinary HTTPS address: write it as one and none of this applies.
+
+```json
+{
+  "s3": [
+    {
+      "bucket": "terrain",
+      "endpoint": "https://minio.lan:9000",
+      "region": "us-east-1",
+      "accessKeyId": "…",
+      "secretAccessKey": "…"
+    }
+  ]
+}
+```
+
+| field             | default            |                                                      |
+| ----------------- | ------------------ | ---------------------------------------------------- |
+| `bucket`          | any                | which bucket this row is for; unset matches all      |
+| `endpoint`        | AWS for the region | what makes it S3-compatible rather than S3           |
+| `region`          | `us-east-1`        | signed into every request, whether or not it is used |
+| `accessKeyId`     | —                  |                                                      |
+| `secretAccessKey` | —                  |                                                      |
+| `sessionToken`    | unset              | for temporary credentials                            |
+| `pathStyle`       | path, unless AWS   | `false` puts the bucket in the hostname              |
+
+A source is read through the row naming its bucket, or through whichever row
+names none: one set of credentials for a whole account is the ordinary case,
+and writing the same keys once per bucket is busywork with a copy-paste
+mistake in it.
+
+### The endpoint is the whole point
+
+MinIO, Ceph, Garage, Cloudflare R2, Wasabi and Backblaze B2 all answer the
+same protocol at their own address, so naming that address is the difference
+between "S3" and "S3-compatible". Path-style addressing is what they speak and
+is the default here; AWS withdrew it for buckets made after September 2020, so
+an `amazonaws.com` endpoint puts the bucket in the hostname instead. Set
+`pathStyle` only for a server that insists on the other one.
+
+### Credentials from the environment
+
+With no rows configured at all, the standard variables are read — the same
+ones the AWS CLI, rclone, go-pmtiles and tileserver-gl use, so a machine
+already set up to reach a bucket needs nothing written here:
+
+| variable                                     |                                 |
+| -------------------------------------------- | ------------------------------- |
+| `AWS_ACCESS_KEY_ID`, `AWS_SECRET_ACCESS_KEY` | required for any of it to apply |
+| `AWS_SESSION_TOKEN`                          | temporary credentials           |
+| `AWS_REGION`, `AWS_DEFAULT_REGION`           | region                          |
+| `AWS_S3_ENDPOINT`, `AWS_ENDPOINT_URL_S3`     | endpoint                        |
+| `AWS_S3_FORCE_PATH_STYLE`                    | addressing                      |
+
+### Signed here, not by an SDK
+
+SigV4 for a GET is a hash, four HMACs and a string, all of which `node:crypto`
+already has. An AWS client would be a large dependency for one signature, and
+an optional one would make reading a bucket work on some installs and not on
+others for no reason the operator could see — so it is neither optional nor a
+dependency. The signer is checked against AWS's own published test vectors
+rather than against itself.
+
+Every request is signed as it goes out, including the range: the header, each
+directory and each tile. Nothing is presigned and nothing is cached but the
+bytes, so revoking a key stops reads at the next request rather than at the
+next restart. Changing the settings drops the open readers for the same
+reason.
+
+### What a bucket source is, and is not
+
+It is a URL source in every other respect — see
+[tile-stacks.md](tile-stacks.md), "A source read straight from a URL". It
+carries its own `minzoom`, `maxzoom` and `bounds`, it is never seeded or
+retired, and it can be baked: a stack over private buckets exports to an
+ordinary archive with an infohash, which is the path from "terrain we hold in
+a bucket" to "terrain we publish".
+
 ## Mutable publishing
 
 Announcing the current build of each category over the DHT (BEP 46).

package/docs/tile-stacks.md

@@ -60,6 +60,7 @@ of its parts.
 - [Syncing a stack to another node](#syncing-a-stack-to-another-node)
 - [What the offline merge got wrong](#what-the-offline-merge-got-wrong)
 - [The stack editor](#the-stack-editor)
+- [Merging vector sources](#merging-vector-sources)
 - [Staging](#staging)
 - [Open questions](#open-questions)
 
@@ -541,21 +542,42 @@ Derived from the resolved sources rather than from any one archive:
 - `attribution` — every source's, concatenated.
 - `tiles` — `/stacks/<id>/{z}/{x}/{y}.<ext>`.
 
-Plus a non-standard `stack` block naming what it resolved to, mirroring the
-`latest` block on `/latest/<category>/tiles.json`, so a consumer can tell one
-resolution from the next:
+Plus a non-standard `stack` block, mirroring the `latest` block on
+`/latest/<category>/tiles.json`, so a consumer can tell one resolution from the
+next:
 
 ```jsonc
 "stack": {
   "id": "planet-terrain",
-  "revision": 7,
-  "sources": [
-    { "category": "gebco", "infohash": "a074186d…", "name": "GEBCO_2026_…" },
-    { "category": "planet-bathymetry", "infohash": "…", "name": "…" }
-  ]
+  "space": "elevation",
+  "sources": 2,
+  "revision": "9f2c1a77b3e04d16"
 }
 ```
 
+`revision` covers the recipe and what every source resolved to, so it moves
+when a category resolves to a new build — which is the whole reason the block
+exists.
+
+### The sources themselves are not in it
+
+They were once, and it was wrong twice over.
+
+A stack's sources are not a client's to join. They are the ingredients of one
+endpoint, and this document exists to point at that endpoint: a map reads
+`tiles`, not the archives behind it. Listing them invites somebody to fetch
+those instead, which is the one thing a stack is there to stop them having to
+do.
+
+And a source may be an **address**. A URL, or a bucket and a key, published in
+a document that is served to anybody who can load the map — while the archive
+at the other end of it is read with credentials nobody else has. The tiles are
+public on purpose; where they come from is not.
+
+What is left says the same thing the list said, in twenty bytes rather than
+tens of kilobytes: how many sources there are, and a fingerprint that moves
+when any of them does.
+
 ## When a source will not answer
 
 A cache-mode source with no reachable peers, a category that resolves to an
@@ -1681,6 +1703,22 @@ archive — Mapterhorn's own base stops at z12 — is upscaled for a deeper
 request exactly as GEBCO is, through the same code, because reading one is now
 a question of which store method answers and nothing else.
 
+### Adding one by hand
+
+**Add source → an address you type…** in the stack editor, which is the same
+source the importer writes and edits the same way. The card asks for two
+things nothing else can know: the address, and the zoom range the archive
+holds. A catalog archive states its range in its own header and a URL source
+has no header this node has read, so an unstated range means every tile asks
+it — correct, and the thing worth avoiding once there are several.
+
+Anything published as a plain HTTPS download works, which includes an S3
+bucket that serves range requests: an object URL, or a presigned one, is an
+address like any other, and this asks for byte ranges the way any PMTiles
+reader does. What it cannot do is a private bucket named `s3://…`, which is
+not a URL a browser or a fetch can follow — that needs a signed request and
+somewhere to keep the credentials, and neither exists here yet.
+
 ### Cheap to have hundreds of
 
 The one thing that makes hundreds of these practical rather than merely
@@ -1830,6 +1868,14 @@ that is a map changing at 4am with nothing to say why. A hand-written source
 carries no `importedFrom`, is never replaced, and is the place for anything the
 index could not have told us.
 
+### Seeing them in the console
+
+A stack's source list collapses behind a summary once there are more than
+five, with the count and the base named on the fold. A stack imported from a
+provider's list is several hundred rows and drawing them flat buries every
+other stack on the page under one of them; a stack of a base and a layer or
+two stays open, since folding that hides nothing worth a click.
+
 ## Finding a stack
 
 A stack has no infohash and appears in no feed, so nothing about it is
@@ -2175,6 +2221,135 @@ Debounced, and it should not follow the map past the stack's `maxzoom`: above
 that the client overzooms and there is nothing new to see, but the tiles are
 still requested and still composited.
 
+## Merging vector sources
+
+**Not built.** This is the design, written down before anything is started so
+that the hard part is on record rather than discovered halfway through it.
+
+Most of the machinery is indifferent to what a tile contains. Source
+resolution, per-source `minzoom`, `maxzoom` and `bounds`, painting order,
+nested stacks, the cache, the ETag, `unionOfTileIds` and the bake all treat a
+tile as an opaque thing, and the byte-for-byte passthrough already serves a
+vector archive today. What a vector space adds is a merge, and the merge is
+where the analogy with the two pixel spaces breaks.
+
+### What has no vector analogue
+
+`opacity`, `blend`, `feather`, `featherMetres`, `gaussianBlurSigma`,
+`output.encoding`, `output.tileSize`, `maskValues`, `maskRange` and
+`maskColors`. Every one of them is an operation on a pixel, and there are no
+pixels. A recipe naming any of them under a vector space should be **refused by
+validation**, not accepted and ignored: a stack that says `feather: 50` and
+draws a hard edge is a worse answer than one that will not save.
+
+The idea of a mask survives in three other forms — clip to a **shape**, keep or
+drop whole **layers** by name, and filter **features** by a property. Those
+three are the vector mask, and none of them is a mask in the sense the
+elevation space means.
+
+### Overlap is the whole problem
+
+The pixel spaces work because the unit is a pixel, every source has one
+everywhere, and "the topmost covered source wins" is a complete rule. Vector's
+unit is a feature. Two sources that both carry a `water` layer over the same
+ground hold **two polygons of the same lake**, and emitting both overwrites
+neither. The tile carries both, the style draws both, and it shows as doubled
+outlines, darker semi-transparent fills, duplicated labels, and z-fighting
+between them.
+
+So the first thing a vector space has to define is what winning means. Three
+answers, and the third is not a default:
+
+**Per-layer replacement.** For each layer _name_, the topmost source carrying it
+supplies it whole, and the same-named layer of every source below is dropped for
+that tile. No geometry work at all: read the layer list, choose, re-emit. It is
+the right answer for a base plus an overlay of layers the base does not have —
+an OSM base under your own `buildings`, or under contours generated from the
+terrain these stacks already merge — and it is correct for a base plus a patch
+wherever the tile falls wholly inside the patch.
+
+**Clip and union.** Each source is clipped to its own coverage, and the source
+below is additionally clipped _against_ the coverage of the one above it, so the
+two cannot both carry the same lake. This is the true counterpart of the pixel
+merge, and the only thing that works on a tile the boundary of a patch runs
+through. A **rectangle** clip in tile coordinates is cheap and exact —
+Sutherland-Hodgman for polygons, Liang-Barsky for lines — and a rectangle is
+what an imported file list states for every patch in it. An arbitrary
+**cutline** is a different matter and wants a real polygon-clipping library.
+
+**Renaming.** The patch's `water` becomes `patch_water`, and the style decides
+what to do with it. No conflict and no geometry work, at the cost of a style
+that has to know. Worth having as a way out; not worth having as the rule.
+
+The recommendation is per-layer replacement as the default, rectangle clipping
+for the base-and-patch case, and a **recipe warning** wherever two sources carry
+the same layer with no clip between them: _sources 0 and 1 both provide `water`,
+and tiles where they meet will carry both_. Silent doubling is the failure that
+gets found six months later by somebody squinting at a coastline.
+
+### A seam cannot be feathered
+
+Where two sources disagree geometrically at a boundary, a road jogs and a
+coastline steps, and there is nothing to fade. [Feathering a
+seam](#feathering-a-seam) works because a pixel can be a mixture of two values.
+A feature cannot be a mixture of two features.
+
+Vector merging is therefore clean only where the sources were cut to agree — the
+same condition that makes a provider's raster patches merge cleanly, minus the
+fade that hides the cases where it is not quite true. That belongs in the
+console rather than on the map.
+
+### Overzooming a parent
+
+Possible, and needed: a base to z12 under a patch to z14 has to climb the base
+at z13, exactly as [resampling from a parent](#resampling-from-a-parent-tile)
+does for pixels. Scale the parent's coordinates by the zoom difference, subtract
+the quadrant's offset, clip to the extent plus the buffer. Exact for geometry,
+and it invents nothing: the generalisation and the label placement were chosen
+for the parent's zoom, so an overzoomed tile is thinner than a real one at that
+zoom and looks it.
+
+### Extent, buffer and schema
+
+Sources at different **extents** — 4096 and 512 are both common — have to be
+normalised to one before anything is combined. A power-of-two ratio is exact;
+anything else quantises coordinates.
+
+**Buffers** have to be re-clipped after any coordinate change, or features leak
+past the edge of the tile and draw twice at the join.
+
+**Schemas** are the quiet one. Two sources whose `water` layers use `class` and
+`kind` merge into a layer the style half understands, and nothing in the merge
+can reconcile them. Worth comparing key sets on the first merged tile and
+reporting the disagreement as a problem on the stack, the way an unresolved
+source is reported.
+
+**Feature ids** collide across sources. Renumbering settles the collision and
+breaks any client-side feature state keyed on them, so it is a choice to make
+out loud rather than a detail to settle inside the encoder.
+
+### The libraries
+
+`@mapbox/vector-tile` and `pbf` to read, `vt-pbf` to write. Small, pure
+JavaScript, and ordinary dependencies rather than a probe: the optional
+treatment [the codec gets](#the-codec-problem) exists because a native build
+genuinely fails to install on some platforms, and none of that applies here.
+
+Not written here either, unlike the PMTiles writer and the S3 signer. A protobuf
+round-trip has more edge cases than either — geometry command encoding, unknown
+value types, key and value pools shared across features — and getting one wrong
+produces a tile that parses and is subtly wrong.
+
+### Staging, when it is started
+
+1. **Layer operations only.** `space: "vector"`, with keep, drop and rename by
+   layer name, over the per-source zoom and bounds skipping that already exists.
+   Covers base-plus-overlay, and needs no geometry code whatsoever.
+2. **Overzoom and rectangle clipping.** Covers base-plus-patch, which is the
+   shape [importing a list of URLs](#importing-a-list-of-urls) makes easy to
+   build.
+3. **Cutline clipping and property filters.**
+
 ## Staging
 
 1. ~~**Recipe and resolution.**~~ Done. `data/stacks.json`, load and validate,
@@ -2206,10 +2381,11 @@ handling whatsoever.
 
 ## Open questions
 
-- **Vector tiles.** Merging MVT layers from two archives is a real want and a
-  completely different operation — decode protobuf, merge layer by layer,
-  re-encode, with feature ID collisions to settle. It should be its own feature
-  and should not be smuggled in under `space`.
+- **Vector tiles.** Designed rather than open now: see [merging vector
+  sources](#merging-vector-sources). It is its own space and its own merge,
+  and what stays open is whether the overlap rule proposed there — layer
+  replacement by default, clipping for a patch — holds up against a real
+  pair of archives.
 - **Does the recipe travel?** A stack is a small JSON document and the feed
   already distributes documents. Publishing recipes so a subscriber gets the
   stack along with its sources is attractive, and raises an obvious question

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "pmtiles-swarm",
-  "version": "0.90.0",
+  "version": "0.92.0",
   "description": "BitTorrent distribution for PMTiles map archives: create torrents, watch folders, publish and subscribe to RSS feeds, and seed through qBittorrent or an embedded client",
   "type": "module",
   "main": "src/index.js",

package/src/api.js

@@ -50,15 +50,7 @@ import {
   stackCoverage,
   stackEtag,
 } from './stacks.js';
-
-/**
- * How many sources a stack's TileJSON names before it starts counting.
- *
- * Generous for a hand-written recipe -- those run to a handful -- and a hard
- * stop for one imported from a provider's index, where the list is hundreds
- * long and every entry is an address no client reads.
- */
-const TILEJSON_SOURCE_LIMIT = 25;
+import { bakeRevision } from './bake.js';
 
 const here = path.dirname(fileURLToPath(import.meta.url));
 
@@ -3400,45 +3392,64 @@ export function createApp({
           // The order the recipe lists them: lowest priority first, last
           // wins. The console shows this order as it stands rather than
           // inverting it, so the screen and the file never disagree.
-          sources: resolved.sources.map((source) => ({
-            index: source.index,
-            name: source.name,
-            pinned: source.pinned,
-            required: source.required,
-            // What kind of source this is, said outright rather than left to
-            // be inferred from which fields happen to be null. A URL source
-            // has no infohash and no catalog entry, so a reader guessing from
-            // those calls it an unresolved category -- which is two wrong
-            // things about a source that is working perfectly well.
-            kind: source.remote
-              ? 'url'
-              : source.nested
-                ? 'stack'
-                : source.pinned
-                  ? 'archive'
-                  : 'category',
-            // A URL source resolves by definition: there is nothing to look
-            // up, the address is the answer. Whether it can actually be read
-            // is a question for the first tile, the same as for an archive
-            // this node holds but cannot open.
-            resolved: Boolean(source.entry) || Boolean(source.remote),
-            url: source.remote ?? null,
-            infohash: source.entry?.infoHash ?? null,
-            archiveName: source.entry?.name ?? null,
-            // The recipe's own, where it states them. For a URL source that is
-            // the only place they are known without opening the file, and it
-            // is what the merge itself uses to decide whether to.
-            minzoom:
-              source.entry?.pmtiles?.minZoom ?? source.source?.minzoom ?? null,
-            maxzoom:
-              source.entry?.pmtiles?.maxZoom ?? source.source?.maxzoom ?? null,
-            bounds:
-              source.entry?.pmtiles?.bounds ??
-              (Array.isArray(source.source?.bounds)
-                ? source.source.bounds
-                : null),
-            format: source.entry?.pmtiles?.format ?? null,
-          })),
+          sources: resolved.sources.map((source) => {
+            // A nested stack answers for the ground its own sources cover,
+            // and knows it without opening anything -- so the row can say
+            // what it reaches rather than a dash.
+            const inner = source.nested ? stackCoverage(source.nested) : null;
+            return {
+              index: source.index,
+              name: source.name,
+              pinned: source.pinned,
+              required: source.required,
+              // What kind of source this is, said outright rather than left to
+              // be inferred from which fields happen to be null. A URL source
+              // has no infohash and no catalog entry, so a reader guessing from
+              // those calls it an unresolved category -- which is two wrong
+              // things about a source that is working perfectly well.
+              kind: source.remote
+                ? 'url'
+                : source.nested
+                  ? 'stack'
+                  : source.pinned
+                    ? 'archive'
+                    : 'category',
+              // A URL source resolves by definition: there is nothing to look
+              // up, the address is the answer. Whether it can actually be read
+              // is a question for the first tile, the same as for an archive
+              // this node holds but cannot open.
+              resolved:
+                Boolean(source.entry) ||
+                Boolean(source.remote) ||
+                Boolean(source.nested),
+              // How many sources the nested recipe has, which is the only
+              // useful thing to say in a column that names an archive file for
+              // every other kind: a stack resolves to a recipe, not to bytes.
+              nested: source.nested ? source.nested.sources.length : null,
+              url: source.remote ?? null,
+              infohash: source.entry?.infoHash ?? null,
+              archiveName: source.entry?.name ?? null,
+              // The recipe's own, where it states them. For a URL source that is
+              // the only place they are known without opening the file, and it
+              // is what the merge itself uses to decide whether to.
+              minzoom:
+                source.entry?.pmtiles?.minZoom ??
+                source.source?.minzoom ??
+                inner?.minzoom ??
+                null,
+              maxzoom:
+                source.entry?.pmtiles?.maxZoom ??
+                source.source?.maxzoom ??
+                inner?.maxzoom ??
+                null,
+              bounds:
+                source.entry?.pmtiles?.bounds ??
+                (Array.isArray(source.source?.bounds)
+                  ? source.source.bounds
+                  : (inner?.bounds ?? null)),
+              format: source.entry?.pmtiles?.format ?? null,
+            };
+          }),
         };
       });
       // Reported so the console can say "install sharp" beside the stacks
@@ -3781,34 +3792,27 @@ export function createApp({
         minzoom: coverage.minzoom,
         maxzoom: coverage.maxzoom,
         bounds: coverage.bounds,
-        // Names what it resolved to, so a consumer can tell one resolution
-        // from the next without diffing tile URLs — the same reason the
-        // `/latest/` document carries a `latest` block.
+        // Says that it resolved, and whether the resolution has moved, so a
+        // consumer can tell one from the next without diffing tile URLs --
+        // the same reason the `/latest/` document carries a `latest` block.
         //
-        // Capped. A stack imported from a provider's file index has hundreds
-        // of sources — Mapterhorn's is 458 — and listing every one puts tens
-        // of kilobytes of addresses in a document every map load fetches, to
-        // say something no client does anything with. What the block is for is
-        // telling one resolution from the next, and what moves between
-        // resolutions is the infohashes, so those are what it keeps.
+        // A count and a fingerprint rather than the sources themselves. They
+        // were listed here once, and it was wrong twice over. A stack's
+        // sources are not a client's to join: they are the ingredients of one
+        // endpoint, and a document listing them invites somebody to fetch
+        // those instead of the tiles. And a source may be an address -- a URL,
+        // or a bucket and a key -- which this document has no business
+        // publishing: the tiles are public where the archives behind them are
+        // read with credentials nobody else has.
+        //
+        // The fingerprint covers the recipe and what every source resolved
+        // to, so it moves when a category resolves to a new build. That was
+        // the only thing the list was good for.
         stack: {
           id: resolved.stack.id,
           space: resolved.stack.space ?? 'elevation',
-          sources: resolved.sources
-            .slice(0, TILEJSON_SOURCE_LIMIT)
-            .map((source) => ({
-              name: source.name,
-              infohash: source.entry?.infoHash ?? null,
-              archive: source.entry?.name ?? null,
-            })),
-          // Said rather than silently truncated: a consumer comparing two of
-          // these has to know it is looking at part of a list.
-          ...(resolved.sources.length > TILEJSON_SOURCE_LIMIT
-            ? {
-                more: resolved.sources.length - TILEJSON_SOURCE_LIMIT,
-                total: resolved.sources.length,
-              }
-            : {}),
+          sources: resolved.sources.length,
+          revision: bakeRevision(resolved),
         },
       };
       // A stack says how its tiles are encoded, so a style pointing at it does