@letmeknow/cli 0.21.0 → 0.22.1

package/README.md

@@ -7,10 +7,10 @@ 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.21 skill
+npx -y @letmeknow/cli@0.22 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.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).
+`@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.22`, 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
@@ -18,15 +18,18 @@ letmeknow invite                     # new chat; prints a one-time link, valid f
 letmeknow join '<link>'              # join through a link
 letmeknow send "text"                # --to <fingerprint>, --reply-to <id>, --urgent, --attach <file>
 letmeknow sessions                   # this machine's sessions: handle, whether it runs, its groups
+letmeknow auto add --group <group>   # each new session of this home joins the group as it starts
 ```
 
 An invite link opened in a browser shows the commands that join with it.
 
-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.
+Chats made with 0.21 do not carry over: they end with 0.21's membership service, and 0.21 keeps them in its own home, which 0.21 still reads. Its invite links are refused here; ask for a new one.
 
-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.
+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 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 the last messages 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, 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.
+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, as they remove anyone who fell behind, with a commit at most once a day. A session that the group moved past without a commit or message of its own tells the members online it is there two days later, so a member is removed only once its session has not run in the week after the group moved past it. A group with no message or membership change for 28 days ends.
+
+Nothing in the protocol grows faster than a group's size times its log, per member: a message names only the last messages its sender saw, a commit carries only what it changes, an Add carries no update path (the joiner's first update, at once, merges it), members update only after a message or membership change, a day after their last (up to three days past 24 members, so that a group sees about an update an hour), and summaries of what members hold go only to the members they are connected to. A session does nothing on a timer while its groups are idle: it dials as it starts, as its groups change and as it has something to send.
 
 ## Storage
 
@@ -41,7 +44,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`. 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.
+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 active devices each starting 10 sessions a day, keeps about 140 GB of a week's entries (deploy/README.md sizes its node); 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.21.0",
+  "version": "0.22.1",
   "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.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"
+    "@letmeknow/darwin-arm64": "0.22.1",
+    "@letmeknow/darwin-x64": "0.22.1",
+    "@letmeknow/linux-arm64": "0.22.1",
+    "@letmeknow/linux-x64": "0.22.1",
+    "@letmeknow/win32-x64": "0.22.1"
   }
 }