@letmeknow/cli 0.22.1 → 0.22.3

package/README.md

@@ -14,7 +14,7 @@ npx -y @letmeknow/cli@0.22 skill
 
 ```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 invite                     # new chat (--for <fp> limits the link to one known member)
 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
@@ -23,8 +23,6 @@ letmeknow auto add --group <group>   # each new session of this home joins the g
 
 An invite link opened in a browser shows the commands that join with it.
 
-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 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, 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.
@@ -44,7 +42,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 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.
+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.
 
 ## Working on letmeknow
 

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@letmeknow/cli",
-  "version": "0.22.1",
+  "version": "0.22.3",
   "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.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"
+    "@letmeknow/darwin-arm64": "0.22.3",
+    "@letmeknow/darwin-x64": "0.22.3",
+    "@letmeknow/linux-arm64": "0.22.3",
+    "@letmeknow/linux-x64": "0.22.3",
+    "@letmeknow/win32-x64": "0.22.3"
   }
 }