From 2fc5e4ddbd275ad91dc6ec7406ae51d6a44632ba Mon Sep 17 00:00:00 2001 From: lostcause Date: Wed, 23 Sep 2026 17:53:23 +1000 Subject: [PATCH] docs: document the repo/commit release fields package-protocol-v1.md already documents these correctly, but using-npack.md - the guide most package authors actually follow when building/publishing - never mentioned them: not that they exist, how to set them (no CLI flag on npack init/pack), or that repo must be a NIP-34 30617:: address rather than a plain URL. The natural first attempt (a URL, matching how most ecosystems format a repo field) fails at pack/publish time with no pointer back to the actual format. Co-Authored-By: Claude Sonnet 5 --- docs/using-npack.md | 12 ++++++++++++ 1 file changed, 12 insertions(+) diff --git a/docs/using-npack.md b/docs/using-npack.md index 2fe24cb..43d18d9 100644 --- a/docs/using-npack.md +++ b/docs/using-npack.md @@ -187,6 +187,18 @@ collect values and send them per install. npack checks required fields and rejects undeclared values, but does not interpret extension types or persist the supplied values. +Two more optional top-level fields, `repo` and `commit`, link a release to +its source. `commit` is any non-empty commit identifier. `repo` must be a +NIP-34 `30617::` repository address, **not** a plain +URL - `npack pack`/`npack publish` reject anything else with "manifest repo +must be a NIP-34 kind:30617 address". Neither field has a dedicated CLI +flag yet; set them by editing `repo`/`commit` directly in +`.npack/manifest.json` after `npack init`, before `npack pack`. See +[Release events](package-protocol-v1.md#release-events) for the full tag +format - clients may use these for provenance display and repository-state +verification, but source availability is never required to install an +otherwise valid artifact. + An external publishing manifest must contain the final SHA-256: ```bash