@tinycloud/cli 1.3.1 → 1.3.2-beta.1

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
package/package.json CHANGED
@@ -1,6 +1,6 @@
1
1
  {
2
2
  "name": "@tinycloud/cli",
3
- "version": "1.3.1",
3
+ "version": "1.3.2-beta.1",
4
4
  "description": "TinyCloud CLI - manage data, delegations, and nodes from the terminal",
5
5
  "author": "TinyCloud, Inc.",
6
6
  "license": "EGPL",
@@ -33,13 +33,13 @@
33
33
  "sync:courier-skill": "rm -rf skills/courier && cp -R ../courier/skills/courier skills/courier"
34
34
  },
35
35
  "dependencies": {
36
- "@tinycloud/share-sdk": "1.2.0",
37
- "@tinycloud/share-envelope": "1.2.0",
38
- "@tinycloud/node-sdk": "3.3.0",
36
+ "@tinycloud/share-sdk": "1.2.1-beta.0",
37
+ "@tinycloud/share-envelope": "1.2.1-beta.0",
38
+ "@tinycloud/node-sdk": "3.3.1-beta.0",
39
39
  "@tinycloud/node-sdk-wasm": "1.7.8",
40
- "@tinycloud/sdk-core": "3.3.0",
40
+ "@tinycloud/sdk-core": "3.3.1-beta.0",
41
41
  "@tinycloud/sdk-services": "3.3.0",
42
- "@tinycloud/operations": "0.7.0",
42
+ "@tinycloud/operations": "0.7.1-beta.0",
43
43
  "chalk": "^5.3.0",
44
44
  "commander": "^14.0.0",
45
45
  "jsdom": "26.1.0",
@@ -48,7 +48,7 @@
48
48
  "siwe": "^3.0.0"
49
49
  },
50
50
  "devDependencies": {
51
- "@tinycloud/courier": "0.2.0",
51
+ "@tinycloud/courier": "0.2.1-beta.0",
52
52
  "@tinycloud/replica": "0.3.0",
53
53
  "@types/node": "^20",
54
54
  "tsup": "^8.0.0",
@@ -371,7 +371,7 @@ printf '%s' "$SHARE_URL" | "$TC" share inspect - --json # verify,
371
371
  printf '%s' "$SHARE_URL" | "$TC" share receive - --stdout # bearer link: verified bytes
372
372
  printf '%s' "$SHARE_URL" | "$TC" share receive - --output .
373
373
 
374
- "$TC" share list --json # sender history, no complete URLs
374
+ "$TC" share list --json # sender history, no complete URLs; human rows are shareId, target, expiresAt, status (active, revoked or expired), tab-separated
375
375
  "$TC" share show <id> [--reveal-link]
376
376
  "$TC" share notify <id> --to alice@example.com # retry email delivery within 5 minutes of publication
377
377
  "$TC" share revoke <id> # bearer or addressed share this profile created
@@ -392,12 +392,16 @@ Versions are kept by default and count against the owner's storage. The node doe
392
392
 
393
393
  **Bearer vs addressed.** A bearer link (default, `--to anyone`) is `/viewer#tc1=<TinyCloud delegation>`: anyone holding the complete URL can read the file until it expires, and revocation cannot recall copies already received. Addressed links (`--to email:`, `--to did:`, `--to domain:`) are `/s/inline#v=2&p=<sealed Policy/v3 envelope>`: the content is encrypted and only the named recipient can open it after proving their email or DID in Share. `tinycloud share receive` returns the bytes of a bearer link; for an addressed link it exits 6 with `CLAIM_REQUIRED` because the recipient claims it in Share. `--notify` requires the `read` action: exact-email targets invite the matched mailbox; domain targets need `--notify-to` naming one canonical mailbox at that exact domain and a node reporting version 1.17.3 or later. The CLI refuses unsupported domain invitations before uploading or registering a share. A session-only publisher can deliver its own domain policy when the invoking DID matches its signed owner DID; a different sender DID cannot. `tinycloud share notify <id> --to <mailbox>` can address another mailbox in a domain share under the same node and sender-DID requirements; it refuses stored shares without `read` or on an unsupported node before sending.
394
394
 
395
+ **Short links (addressed shares).** `share publish` prints an addressed share as a short link, `https://share.tinycloud.xyz/s/<id>#v=3&k=<key>&c=<cid>`. Share's short-link service stores only the sealed envelope bytes under `<id>`. The read key `k` and the CID `c` of those bytes stay in the fragment, so the service never receives the key, and `share receive`/`share inspect` refuse bytes that do not hash to `c`. `--long-link` prints the self-contained `/s/inline#v=2&p=…` link instead. If the short-link service is unavailable, publishing still succeeds: the CLI prints the long link, warns on stderr that it is long, and `--json` adds `shortLinkError` (`rate-limited`, `capacity`, `rejected`, `unavailable`, `invalid-response`, `too-large` or `token-store-failed`). That includes a refused or timed-out connection: each short-link request gives up after 10 seconds. Every publish first reads Share's public configuration from the same host, so if that host is unreachable altogether the publish stops before anything is shared, with `SHARE_SERVICE_UNAVAILABLE` (exit 4). The short link's delete token is kept in the owner's `default` space at `xyz.tinycloud.share/shares/<shareId>/.short-link.json`, the same key the Share web composer uses, so either client can revoke a share the other published. `share show <id> --reveal-link` prints the same short link, and `share revoke` deletes the stored envelope after the node confirms the revocation; a failed delete only warns, and the envelope expires with the share. Sender history and the `--notify` invitation still carry the long link. Bearer links are unchanged.
396
+
395
397
  The fragment after `#` is the read key. Browsers never send it to a server; `--notify` gives the link to TinyCloud only to email your recipients. Keep complete URLs out of logs. Human publish output is exactly one URL. JSON publish output never contains the link: it retains the redacted publication fields (including the share id) and adds `notification` (the `ShareNotifyResult`, including `state`, `attempts`, and optional failure `reason`) when `--notify` was requested. To get the complete link after a `--json` publish, run `tinycloud share show <id> --reveal-link`, ideally writing it straight to a private file. Inspect never prints plaintext or secret-bearing fields. Receive uses a sanitized single-segment filename and refuses overwrite unless `--force`. `revoke` asks the owner node to revoke the share (an addressed share's Policy/v3 root, or a bearer link's delegation) and reports `revoked` only when the node confirms it; receiving the link then fails; for a bearer link, `tinycloud share receive` reports `SHARE_REVOKED` (exit 4, "This share link has been revoked by its sender."). Revoking an already revoked share keeps its original `revokedAt`. A bearer revoke that cannot proceed revokes nothing: `SHARE_ISSUER_KEY_UNAVAILABLE` (exit 5) when this profile cannot sign for the link, `SHARE_LINK_UNAVAILABLE` (exit 4) when the stored link is missing or does not match the record, and `SHARE_REVOKE_REJECTED` (exit 4, with the node's reason) when the node refuses. `SHARE_REVOKE_UNCONFIRMED` (exit 1) means the node answered without confirming: the link may already be revoked, history is not marked revoked, and you should check whether the link still opens before retrying. Pre-cutover blob-backed and plaintext `?tc2` links are not accepted.
396
398
 
397
399
  **Publish history status.** `share publish --json` reports the sender-history write as `history`: `{"recorded": true}` when the share was saved, or `{"recorded": false, "reason": "<CODE>"}` when it was not. `HISTORY_UNREADABLE` means the existing history file cannot be decrypted or parsed with the current session key. `HISTORY_READ_FAILED` means the filesystem refused or failed to read that file. `HISTORY_WRITE_FAILED` means a filesystem or permission error during the write. `HISTORY_UNAVAILABLE` covers every other failure, including a profile-lock timeout. The exit status is 0 in all four cases, so do not retry the publish on this result: a retry creates a duplicate share. The stderr warning names the reason and the share id and CID to keep. It never includes the link, the key, or ciphertext. When `--notify` delivers but the delivery confirmation cannot be saved, `history.recorded` stays `true` (the share itself was saved) and the warning names the reason, the share id, and the CID.
398
400
 
399
401
  **Notification window.** The CLI requests a stable signed delivery authorization until the earlier of share expiry and 5 minutes after its sender-history `registeredAt` timestamp. The node allows an authorization no more than 5 minutes in the future; keeping the expiry stable also makes idempotent retries use the same request. After the window, `tinycloud share notify` prints `partial-failure` (exit 9; JSON `retryable: false`, `reason: "delivery-window-expired"`) and explains that the sender must publish a new share and invite the recipient then. `share publish --notify --json` includes the same failure under `notification`. A confirmed repeat within the window prints `already-delivered`; an unconfirmed failed attempt remains retryable until the window closes. If the sender history cannot record a successful delivery confirmation, the CLI warns on stderr but preserves the successful publish/notify result; a later repeat can report `delivered` again.
400
402
 
403
+ **Email-addressed shares need decrypt.** An addressed share (`--to email:`, `did:`, `domain:`) is encrypted to the owner's encryption network, so the publishing session must hold `tinycloud.encryption/decrypt` on it. A local-key profile always does. A session-only sign-in such as `builtin:share-publishing` does not (the manifest deliberately omits it), and the CLI refuses before any upload, registry write or network call: `PERMISSION_DENIED`, exit 5, "this sign-in can't create email-addressed shares ... Nothing was shared." Share from https://share.tinycloud.xyz as the account owner, ask the owner to share it, or use `--to anyone`, which works from that sign-in.
404
+
401
405
  **History and node preflight.** Post-publication sender-history writes wait up to 45 seconds for another process's profile lock (including stale-lock recovery). If the first history write still fails, the CLI warns and keeps its normal exit status: human output still prints the published link, but `--json` output stays redacted, and because the share was not recorded, `share show <id> --reveal-link` cannot recover it either. A later `share list`, `share notify <id>`, or `share revoke <id>` cannot find that share by ID. An immediate `--notify` can still deliver using the in-process record. Other share-command profile-lock timeouts report `PROFILE_LOCK_TIMEOUT` with a retry hint. Standalone domain notification validates the recipient and expired delivery window locally before contacting `/info`: an expired window remains exit 9 even if the node is unavailable. A node-info transport failure, including a stalled response body, is `UNAVAILABLE` (exit 4); a completed but unsupported or malformed version is `INVALID_ARGUMENT` (exit 2). Publish-time refusals say nothing was shared and no invitation was sent; standalone notify refusals say no invitation was sent.
402
406
 
403
407
  **Concurrent history changes.** A Share command resolves its profile once for authentication and every sender-history operation, including retries; a later default-profile change cannot redirect a share link into another profile. If a write waits more than about 2 seconds to acquire the profile lock, the CLI writes one waiting notice to stderr naming that profile. A profile removed after an earlier history read or during an operation, or repeated key/salt changes, returns `SHARE_HISTORY_RETRY` (exit 1) with a retry hint; a profile missing from the outset still returns `PROFILE_NOT_FOUND` with the setup hint. If a history retry follows a revoke, check the node state before trying again: revocation might already have succeeded even though sender history could not record it.