@needmoretruth/nmts-cli 0.36.2 → 0.38.0

package/dist/s3-gateway.d.ts

@@ -0,0 +1,8 @@
+export { createGateway, gatewayHandler } from "./s3/server.ts";
+export type { DriveSource, DriveWriter, GatewayHandler, GatewayOptions } from "./s3/server.ts";
+export { createDriveSource, fetchObject, placeOf, LIST_CACHE_MS } from "./s3/drive.ts";
+export type { DriveAccount, DriveSourceOptions, ObjectReader } from "./s3/drive.ts";
+export { createStaging } from "./s3/staging.ts";
+export type { Staging, StoreFile } from "./s3/staging.ts";
+export type { GatewayCredential } from "./s3/sigv4.ts";
+export type { DriveObject } from "./s3/listing.ts";

package/dist/s3-gateway.js

@@ -0,0 +1,13 @@
+// The S3 gateway as a library: the server `nmts s3` runs, for somebody else's infrastructure.
+//
+// ⛔ ONE IMPLEMENTATION, AND THIS IS THE DOOR TO IT. A business putting NMTS behind its own storage
+//    adapters needs the protocol this package already speaks, in its own process, in front of
+//    whichever of its customers' accounts a request names. A copy of the server in the SDK would
+//    be a second place for a signature check, a listing and a multipart upload to be got right,
+//    and the copy nobody re-reads is the one that quietly disagrees.
+//
+// ⚠ WHAT IS NOT HERE: the bucket name `nmts s3` uses, the address it binds, and the pair it prints
+//   when it starts. Those are that command's answers to questions a business answers for itself.
+export { createGateway, gatewayHandler } from "./s3/server.js";
+export { createDriveSource, fetchObject, placeOf, LIST_CACHE_MS } from "./s3/drive.js";
+export { createStaging } from "./s3/staging.js";

package/docs/commands/create.md

@@ -3,8 +3,8 @@
 Commands: create
 Tiers: create=high
 
-Signs in with one account's key and creates another, printing the new code once — nothing can
-print it again, because the server stores a one-way verifier and never the NMTS key. This is how a
+Signs in with one account's key and creates another, printing the new NMTS key once — nothing
+can print it again, because the server stores a one-way verifier and never the NMTS key. This is how a
 service that keeps its customers' files in NMTS gives each customer a drive; the first account of
 all has to be made in a browser. It needs a key with `files:write` and a live human check behind
 it, and the server allows two a day and five a week per key.

package/docs/commands/env.md

@@ -8,7 +8,7 @@ gives the same thing to parse. It reports the operating system; whether this is
 container and whether root here is root on the host; whether a file written here can be kept
 private (measured, not guessed); whether there is a terminal and whether a browser could be
 opened; whether an NMTS key and an API key were found and where each came from; if the stored
-code is sealed, whether a passphrase is actually reachable; which agent left a marker here; and
+NMTS key is sealed, whether a passphrase is actually reachable; which agent left a marker here; and
 what the version check last found. The `advice` it returns is written to be repeated to the person
 as-is — do that when something in it is a `warn`.
 

package/docs/commands/extend.md

@@ -15,9 +15,6 @@ nmts extend notes/report.pdf --epochs 4   # how many epochs to add (default 2)
 If the account holds a standing share (`nmts tip`), that share of the WAL just paid goes to the
 developer right after the extension, without a question.
 
-```sh
-```
-
 Both forms print the price in WAL, the chain fee in SUI measured by a dry run of the exact
 transaction (`null` in `--json` when it could not be measured, never 0), and what the wallet
 holds. A wallet short of either exits 4 with the two numbers before anything else; a balance the

package/docs/commands/login.md

@@ -7,7 +7,7 @@ Tiers: login=none · login.plain=high(unsafe-code-storage) · login.env=high(pla
 (`NMTS_API_KEY_FILE`, `NMTS_API_KEY`) with the server, and stores that too. It prints the key's
 public handle and never the key. It does not replace a stored key unless the run says so.
 
-Every later command needs the passphrase, from `NMTS_PASSPHRASE` or a terminal. A sealed code with
+Every later command needs the passphrase, from `NMTS_PASSPHRASE` or a terminal. A sealed key with
 no passphrase in reach is not a usable credential; `nmts env` says which case this machine is in.
 
 Two other shapes exist and both are locked until a person opens them once, at a terminal:

package/docs/commands/logout.md

@@ -5,7 +5,7 @@ Tiers: logout=none
 
 Removes the NMTS key and API key this tool stored on this machine. Nothing on the server
 changes: the key stays valid until revoked (`nmts key revoke`, or the account screen), and the
-account is untouched. A code that came from an environment variable or a file is not touched
+account is untouched. An NMTS key that came from an environment variable or a file is not touched
 either — this only forgets what `nmts login` wrote.
 
 Run it when a machine is handed over or a task is finished on a machine the person does not keep.

package/docs/commands/marks.md

@@ -5,5 +5,5 @@ Tiers: star=none · unstar=none · pin=none · unpin=none · label=none · unlab
 
 Free and reversible; nothing here asks. `star <files>` gathers files in favourites, `pin <files>`
 holds them at the top of their folder, and `label <name> <files>` attaches a word you choose; the
-`un-` forms take each off. A label exists while a file wears it. `label --rename <old> <new>`
+`un-` forms take each off. A label exists while a file has it. `label --rename <old> <new>`
 renames a label on every file that carries it; `unlabel <name> --all` takes it off all of them.

package/docs/commands/mcp.md

@@ -28,6 +28,6 @@ codex    mcp add nmts -- nmts mcp --out /where/files/should/land
 opencode mcp add nmts -- nmts mcp --out /where/files/should/land
 ```
 
-A sealed stored code is opened once, at startup; `nmts mcp` never prompts, so a sealed code with
+A sealed stored NMTS key is opened once, at startup; `nmts mcp` never prompts, so a sealed key with
 no `NMTS_PASSPHRASE` exits 3 at startup rather than hang. Arguments are checked against what each
 tool declares — `"dry_run": "true"` is a refusal, not an upload.

package/docs/commands/put.md

@@ -3,8 +3,8 @@
 Commands: put
 Tiers: put=medium · put.wallet=high(wallet)
 
-This is the command that spends. The price is one credit per started mebibyte, printed before the
-upload starts. In the default mode it asks first (answer at the terminal, or run with `--yes`);
+`put` spends credits: one per started mebibyte, and the price is printed before the upload
+starts. In the default mode it asks first (answer at the terminal, or run with `--yes`);
 in an auto mode it runs when you judge it is what the person wants.
 
 ```sh

package/docs/commands/wallet.md

@@ -74,12 +74,10 @@ Three coin subcommands sign, and every signed transaction is irreversible by any
   explorer. It is outside the wallet unlock and its ceiling. A standing share of every WAL
   payment is `nmts tip`, not a gift on its own.
 
-One more reads the gifts back, and one flag on it publishes a name:
-
-- `wallet hall` prints the gift hall of fame — the developer, then the ten largest senders as read
-  from the public chain, with the rest of the list at nmts.me/hall; reading it signs nothing and
-  needs no NMTS key. `--name <name>` (1 to 24 characters, no links, not an address) signs a
-  short message with the wallet this account pays from — the wallet a gift left from — so the
-  server shows that name beside its address, and `--remove` puts the entry back to a shortened
-  address. Reading which wallet that is opens the file list, so naming yourself needs an API key
-  where reading the hall needs none.
+`wallet hall` prints the gift hall of fame — the developer, then the ten largest senders as read
+from the public chain, with the rest of the list at nmts.me/hall; reading it signs nothing and
+needs no NMTS key. `--name <name>` (1 to 24 characters, no links, not an address) signs a
+short message with the wallet this account pays from — the wallet a gift left from — so the
+server shows that name beside its address, and `--remove` puts the entry back to a shortened
+address. Reading which wallet that is opens the file list, so naming yourself needs an API key
+where reading the hall needs none.

package/docs/commands/whoami.md

@@ -3,10 +3,10 @@
 Commands: whoami
 Tiers: whoami=none · whoami.reveal=high(reveal)
 
-Prints the account id the stored code belongs to, offline, with no server call. `--json` gives it
+Prints the account id the stored NMTS key belongs to, offline, with no server call. `--json` gives it
 to a program.
 
 `--reveal` prints the NMTS key itself. An agent never needs this — the tool already holds the
-code — so it is locked until a person runs `nmts unlock reveal` at a terminal, and then asked about
+key — so it is locked until a person runs `nmts unlock reveal` at a terminal, and then asked about
 on every run in every mode but skip-permissions. Never write the NMTS key anywhere it can be read
 again: a log, a commit, a file, a message. It is the only key to the account and cannot be rotated.

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@needmoretruth/nmts-cli",
-  "version": "0.36.2",
+  "version": "0.38.0",
   "description": "Command-line and MCP access to NMTS (NeedMoreTruthStorage, https://nmts.me): open-source, end-to-end encrypted storage on the Walrus network. No fee to NMTS; you pay the network from your own wallet. For people and for their agents.",
   "license": "Apache-2.0",
   "publishConfig": {
@@ -77,6 +77,14 @@
       "types": "./dist/drive-paths.d.ts",
       "default": "./dist/drive-paths.js"
     },
+    "./drive-edit": {
+      "types": "./dist/drive-edit.d.ts",
+      "default": "./dist/drive-edit.js"
+    },
+    "./s3-gateway": {
+      "types": "./dist/s3-gateway.d.ts",
+      "default": "./dist/s3-gateway.js"
+    },
     "./upload-file": {
       "types": "./dist/upload-file.d.ts",
       "default": "./dist/upload-file.js"