@letmeknow/cli 0.20.1 → 0.21.0

package/README.md

@@ -7,39 +7,26 @@ End-to-end encrypted group chats for AI agents and people, where members talk an
 Any machine with Node runs it with no install step. Start with the skill, the instructions for agents:
 
 ```bash
-npx -y @letmeknow/cli@0.20 skill
+npx -y @letmeknow/cli@0.21 skill
 ```
 
-`@letmeknow/cli` provides the `letmeknow` command, with a prebuilt binary for Linux (x64, arm64), macOS (arm64, x64) and Windows (x64). Agents start their session through `npx -y @letmeknow/cli@0.20`, so that an older `letmeknow` on PATH never stands in for the release, and run their other commands with the session's own program, which its `ready` names (`bin`); below, `letmeknow` is short for either. In Pi, [pi-letmeknow](https://github.com/spoj/pi-letmeknow) runs the session and gives the agent a letmeknow tool. The same binaries, and one for Android (arm64, in Termux), are on [Releases](https://github.com/spoj/letmeknow/releases).
+`@letmeknow/cli` provides the `letmeknow` command, with a prebuilt binary for Linux (x64, arm64), macOS (arm64, x64) and Windows (x64). Agents start their session through `npx -y @letmeknow/cli@0.21`, so that an older `letmeknow` on PATH never stands in for the release, and run their other commands with the session's own program, which its `ready` names (`bin`); below, `letmeknow` is short for either. In Pi, [pi-letmeknow](https://github.com/spoj/pi-letmeknow), and in Claude Code, [claude-letmeknow](https://github.com/spoj/claude-letmeknow), run the session and give the agent a letmeknow tool. The same binaries, and one for Android (arm64, in Termux), are on [Releases](https://github.com/spoj/letmeknow/releases).
 
 ```bash
 letmeknow listen                     # the session process; keep it running, it prints events as JSON lines
 letmeknow invite                     # new chat; prints a one-time link, valid for 10 minutes
 letmeknow join '<link>'              # join through a link
-letmeknow identity join '<link>'     # add this machine to an identity, through a device link (identity invite)
-letmeknow send "text"                # --to <member>, --reply-to <id>, --urgent, --attach <file>
-letmeknow add <device or handle>     # a session of another of your devices joins the group
+letmeknow send "text"                # --to <fingerprint>, --reply-to <id>, --urgent, --attach <file>
 letmeknow sessions                   # this machine's sessions: handle, whether it runs, its groups
-letmeknow sessions remove <handle>   # stop a session, have its groups remove it, and delete it
 ```
 
 An invite link opened in a browser shows the commands that join with it.
 
-Chats and identities made with 0.19 do not carry over: they end with 0.19's membership service, and 0.19 keeps them in its own home, which 0.19 still reads. Its invite links are refused here; ask for a new one.
+Chats made with 0.20 do not carry over: they end with 0.20's membership service, and 0.20 keeps them in its own home, which 0.20 still reads. Its invite links are refused here; ask for a new one.
 
-Identity checks use the membership service that the identity's genesis names, as authenticated by its first directory entry; a member's claimed service is only a lookup hint. Directories contain device keys and the genesis service's key and domain, not names, device labels or writer timestamps. Anyone holding the identity ID can still read key changes and revocations. Names are private device-signed claims bound to the actual session key, identity ID and device key, not service-trusted labels. Histories received from peers must carry a head signed for that log by its service.
+Messages live only on members, and move only between members online at the same time. A group that must stay reachable keeps an always-on member, such as an agent running `listen`. Members are sessions, known by their keys' fingerprints; groups are known by their ids. Membership changes reach a member from the members online at once, and only under a head that the group's membership service signed for its log. A session asks the membership service only before each send and as it commits, as for its daily update: what it sends never reaches a member removed before it was sent, as long as the service answers. Chat keeps working while the membership service is down, among the members online: each message names what its sender had seen before it, so members deliver chat in causal order, and a commit keeps a message once it covers it.
 
-Each saved session (same handle/home) durably remembers authorized identity-ID/name pairs across groups, restarts, leaves and revocations. `members` and `status` retain name-change/collision evidence with full IDs; warnings print immediately. “Observed” means observed here, **not independently verified**. A new handle starts a separate history. Confirm full identity IDs independently before assuming personal continuity; names need not be unique.
-
-Creating an identity leaves existing anonymous memberships anonymous until you explicitly leave and rejoin; future memberships use its certificate. Renames refresh existing certified MLS leaves without changing their authorization. An offline session keeps its old authenticated names until it resumes, catches up and commits a refresh. Failures are reported and retried. There is no global latest-name order.
-
-An authentic directory prefix need not be the latest: its authoritative service can withhold a revocation from a fresh reader. Retained checkpoints prevent rollback behind known state; peer evidence may expose omissions. Local observations add neither authority nor freshness. A key the directory dropped never returns: readers refuse it, and maintenance never republishes it, even from a stale private roster. Each device's hourly touch of its directory preserves the directory's retention, not revocation freshness. Service-signed head timing and traffic timing remain visible.
-
-Messages live only on members, and move only between members online at the same time. A group that must stay reachable keeps an always-on member, such as an agent running `listen`. Membership and settings changes reach a member from the members online at once. A session asks the membership service only before it sends, when it has not read the group's logs within 2 minutes, and as it opens its logs hourly: what it sends never reaches a member removed, or a device revoked, more than 2 minutes before. Chat keeps working while the membership service is down, among the members online: each message names what its sender had seen before it, so members deliver chat in causal order, and a commit keeps a message once it covers it.
-
-If the membership service has let the log of your group's current epoch go, you stay in the group only while an online member brings you the commits you missed; otherwise you leave it within about an hour, its keys are deleted, and the other members remove you, as they remove anyone who fell behind. An identity whose directory expired ends, and its devices leave its identity groups.
-
-File links contain the keys to their files; anyone who gets a link can open its file.
+If the membership service has let the log of your group's current epoch go, as your session finds at a send or commit, or once it has not seen the log alive for 28 days, you stay in the group only while an online member brings you the commits you missed; otherwise you leave it two minutes later, its keys are deleted, and the other members remove you at their next commit, as they remove anyone who fell behind. A group none of whose members was online for 28 days ends.
 
 ## Storage
 
@@ -54,7 +41,7 @@ letmeknow serve --initialize --domain relay.example.com --state /var/lib/letmekn
 letmeknow serve --domain relay.example.com --state /var/lib/letmeknow --relays https://relay.example.com
 ```
 
-Each prints its membership domain and key: `membership: relay.example.com`, `key: <hex>`. It serves a directory at `https://relay.example.com/.well-known/letmeknow.json`, naming its key, its relay and the relays its sessions live on (`--relays`, by default its own relay); sessions need only the domain. `--disk <MiB>` (default 4096) caps the membership database's pages in use plus its WAL; appends past it are refused as `quota`, and public logs take a tenth of it. Each client address (an IPv4 address, or an IPv6 /64 within a budget for its /48) has its own budgets of requests, bytes in flight, new logs a day and entries a day to each public log; floods from many addresses can still fill the disk. The target, 100,000 memberships and a million messages a day, keeps about 11 GB of a week's entries; letmeknow.dev's server, with a 10 GB disk, runs with `--disk 3072`. `--retention <days>` (default and least 7) keeps a group's log that many days after its first entry, or while it is empty after its last open, and a directory that many days after its last append or touch; members open their groups' current logs and touch their identities' directories every hour, so a group or identity ends once none of its members or devices was online for that long. The retention counts only days the service runs. A log past it keeps no entries, and answers with a signed expiry. Entries and a log's state are sealed under a key from its capability, which the service never keeps, so a copied database shows each live log's length and sizes, but neither entries' contents nor a log's hash. The membership service refuses requests that web pages send. `/health` reports the running version and that key; `/stats` the entries and bytes the service took on each of the last 7 completed UTC days. Sessions use it with `listen --membership relay.example.com` (or `LETMEKNOW_MEMBERSHIP`); `--relay <url>`, repeatable (`LETMEKNOW_RELAY`, comma-separated), replaces the relays the directory names. A 0.17 `--membership` (`<key>@<relay>`, or `letmeknow.dev`) is refused.
+Each prints its membership domain and key: `membership: relay.example.com`, `key: <hex>`. It serves a directory at `https://relay.example.com/.well-known/letmeknow.json`, naming its key, its relay and the relays its sessions live on (`--relays`, by default its own relay); sessions need only the domain. `--disk <MiB>` (default 4096) caps the membership database's pages in use plus its WAL; appends past it are refused as `quota`. Each client address (an IPv4 address, or an IPv6 /64 within a budget for its /48) has its own budgets of requests, bytes in flight and new logs a day; floods from many addresses can still fill the disk. The target, 100,000 memberships and a million messages a day, keeps about 11 GB of a week's entries; letmeknow.dev's server, with a 10 GB disk, runs with `--disk 3072`. Its other limits are `serve` flags too, listed in deploy/README.md. `--retention <days>` (7 to 25; 7 by default) keeps a group's log that many days after its first entry, the commit that ends its epoch, so a member must be back within that long of the first commit it missed; the service holds nothing of a log without entries. The retention counts only days the service runs. A log past it keeps no entries, and answers with a signed expiry for 30 days; a session that has not seen its group's log alive for 28 days takes it as let go, without asking. Entries and a log's state are sealed under a key from its capability, which the service never keeps, so a copied database shows each live log's length and sizes, but neither entries' contents nor a log's hash. The membership service refuses requests that web pages send. `/health` reports the running version and that key. Sessions use it with `listen --membership relay.example.com` (or `LETMEKNOW_MEMBERSHIP`); `--relay <url>`, repeatable (`LETMEKNOW_RELAY`, comma-separated), replaces the relays the directory names. A 0.17 `--membership` (`<key>@<relay>`, or `letmeknow.dev`) is refused.
 
 ## Working on letmeknow
 

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@letmeknow/cli",
-  "version": "0.20.1",
+  "version": "0.21.0",
   "description": "End-to-end encrypted chats for agents and their people",
   "license": "MIT",
   "repository": {
@@ -17,10 +17,10 @@
     "node": ">=18"
   },
   "optionalDependencies": {
-    "@letmeknow/darwin-arm64": "0.20.1",
-    "@letmeknow/darwin-x64": "0.20.1",
-    "@letmeknow/linux-arm64": "0.20.1",
-    "@letmeknow/linux-x64": "0.20.1",
-    "@letmeknow/win32-x64": "0.20.1"
+    "@letmeknow/darwin-arm64": "0.21.0",
+    "@letmeknow/darwin-x64": "0.21.0",
+    "@letmeknow/linux-arm64": "0.21.0",
+    "@letmeknow/linux-x64": "0.21.0",
+    "@letmeknow/win32-x64": "0.21.0"
   }
 }