Updated rngit documentation

docs/markdown/git.md

@@ -797,10 +797,27 @@ $ rngit release rns://remote_node/public/myrepo fetch "1.2.0:source_*.tgz"
 
 If your pattern contains no wildcard characters, it must match an artifact name exactly, which is useful for fetching single, specific artifacts. When a pattern matches multiple artifacts, all matched files are fetched and verified. If no artifacts match the pattern, the fetch aborts with an error indicating no matches were found.
 
-**Offline Verification**
+### Offline Verification
 
 Because the release manifest contains embedded signatures, you can verify the integrity of release artifacts offline, without connecting to the repository node. The `rnid` and `rngit` utilities can validate artifact signatures against `.rsg` and manifest files.
 
+**Using a release manifest:**
+
+Ensure the release manifest is located in the same directory as the release artifacts, then run:
+
+```text
+# Verify all artifacts in the manifest
+$ rngit release myapp-1.2.0.rsm verify
+
+# Or, verify only specific artifacts
+$ rngit release myapp-1.2.0.rsm verify "latest:*.whl"
+```
+
+This will load the manifest, and verify all files currently on-disk, but will not attempt to fetch the latest release manifest from the origin, or update local files to match it.
+
+#### NOTE
+The `verify` operation is functionally equivalent to using the `fetch` operation with the `--offline` flag, and they can be used interchangably.
+
 **For individual files:**
 
 Ensure the `.rsg` signature is located in the same directory as the release artifact, then run:
@@ -811,23 +828,13 @@ $ rnid -V myapp-1.2.0.tar.gz
 
 This validates that the artifact file matches the signature created during the release process. Combined with the manifest’s own signature, this provides end-to-end verification from the original release creation to the final installation.
 
-**For a complete release:**
-
-Ensure the release manifest is located in the same directory as the release artifacts, then run:
-
-```text
-$ rngit release myapp-1.2.0.rsm fetch --offline
-```
-
-This will load the manifest, and verify all files currently on-disk, but will not attempt to fetch the latest release manifest from the origin, or update local files to match it.
-
 ### Creating Signed Releases
 
 Reticulum and the `rngit` system makes it easy to create signed releases that your users can verify and update securely. When you create a release using `rngit`, the program automatically:
 
 1. Generates an Ed25519 signature for each artifact file using your identity’s signing key
 2. Creates `.rsg` signature files alongside each artifact in your distribution directory
-3. Constructs a signed release manifest (`manifest.rsm`) containing metadata, an artifact list, and embedded signatures
+3. Constructs a signed `manifest.rsm` release manifest containing metadata, an artifact list, and embedded signatures
 4. Transmits both artifacts, signatures and manifest to the remote node specified as release origin
 
 As an example, to create and publish a release from all files in the folder named `dist`, simply run:

docs/markdown/index.md

@@ -234,6 +234,7 @@ to participate in the development of Reticulum itself.
     * [Configuration Example](git.md#configuration-example)
   * [Verified Releases](git.md#verified-releases)
     * [Obtaining Verified Releases](git.md#obtaining-verified-releases)
+    * [Offline Verification](git.md#offline-verification)
     * [Creating Signed Releases](git.md#creating-signed-releases)
   * [Release Management](git.md#release-management)
     * [The Release Workflow](git.md#the-release-workflow)

docs/markdown/using.md

@@ -1262,7 +1262,7 @@ $ rnpath -b
 
 ### Automated List Sourcing
 
-Manually blocking identities is effective for immediate threats, but maintaining an up-to-date blocklist for a large network is impractical. Reticulum supports **automated list sourcing**, allowing your node to subscribe to blackhole lists maintained by trusted peers, or a central authority you manage yourself.
+Manually blocking identities is effective for immediate threats and annoyances, but maintaining an up-to-date blocklist across many nodes on a large network is impractical. Reticulum supports **automated list sourcing**, allowing your node to subscribe to blackhole lists maintained by trusted peers, or a central authority you manage yourself.
 
 #### WARNING
 **Verify Before Subscribing!** Subscribing to a blackhole source is a powerful action that grants that source the ability to dictate who you can communicate with. Before adding a source to your configuration, verify that the maintainer aligns with your usage policy and values. Blindly subscribing to untrusted lists could inadvertently block legitimate peers or essential services.
@@ -1278,6 +1278,9 @@ To enable automated sourcing, add the `blackhole_sources` option to the `[reticu
 ...
 # Automatically fetch blackhole lists from these trusted sources
 blackhole_sources = 521c87a83afb8f29e4455e77930b973b, 68a4aa91ac350c4087564e8a69f84e86
+
+# Optional update interval, defaults to one hour
+blackhole_update_interval = 60
 ...
 ```