@joe-broadhead/opencode-messaging 0.3.0 → 0.4.0

package/CHANGELOG.md

@@ -6,6 +6,32 @@ All notable changes to `@joe-broadhead/opencode-messaging`. Versions follow
 
 ## [Unreleased]
 
+## [0.4.0] - 2026-11-07
+
+Published on npm (public). Built against `@joe-broadhead/messaging` **0.4.0** (vendored, release commit `da50b5d`:
+the release `172a6ba` plus a docs commit), and ships with the 0.4.0 daemon: the five platform packages
+`@joe-broadhead/messaging-bin-{darwin-arm64,darwin-x64,linux-arm64-gnu,linux-x64-gnu,win32-x64}` are pinned at exactly
+0.4.0, each by the registry's integrity in the lockfile and by its executable's sha256 in the launcher, both equal to the
+release's `SHA256SUMS` and provenance. A 0.3.x daemon is refused at the IPC hello (`daemon_mismatch`).
+
+- **Sign in with Jelly** in `/messaging`. In a hosted realm, a device that is no one's yet (the managed
+  realm right after "Use Messaging by Jelly" too) is offered **Sign in with Jelly** first and **Link this
+  device** second. Sign-in shows Jelly ID's link (with a QR code), the user code and this key's
+  fingerprint, with the instruction to approve only if the page shows the same; it opens the browser on
+  request (never over SSH), waits with `device.login.status`, can be cancelled (closing the waiting screen
+  cancels too), and shows the outcome in fixed text. `login_unsupported` (Jelly ID without contract v1.2,
+  production today) is one plain sentence pointing to Link this device, never retried. New console text
+  for `login_unsupported` and `login_denied`.
+- **Devices** shows how a Jelly-vouched device signed in (`via`: through the browser, or on a Jelly host).
+  A device that signed in through the browser removes another device with a fresh sign-in (`device.login`
+  with `remove`); one approved by QR says to do it from Jelly.
+- **`/messaging-status`** shows the binding with `via`, and a sign-in still waiting in the browser.
+- **Tasks name their authors** (core): each text of a task in `tasks` and `read` has `author`
+  (`titleAuthor`, `statusAuthor`): `ours`, unfenced and cleaned, or `peer`, fenced. The plugin's
+  provenance stopgap of 0.3.0 is gone; its test stays as the guard of core's contract. The skill
+  explains the field. Goldens follow.
+- Agent tools never sign in.
+
 ## [0.3.0] - 2026-11-06
 
 The first published release (npm, public). It ships with messaging 0.3.0 and pins the five

package/README.md

@@ -73,10 +73,10 @@ the executable (without it, the plugin uses the Node fallback):
 
 ```bash
 mkdir -p ~/.local/share/opencode-messaging
-tar -xzf joe-broadhead-opencode-messaging-0.3.0.tgz -C ~/.local/share/opencode-messaging --strip-components=1
-npm pack @joe-broadhead/messaging-bin-darwin-arm64@0.3.0           # your platform's package
+tar -xzf joe-broadhead-opencode-messaging-0.4.0.tgz -C ~/.local/share/opencode-messaging --strip-components=1
+npm pack @joe-broadhead/messaging-bin-darwin-arm64@0.4.0           # your platform's package
 mkdir -p ~/.local/share/opencode-messaging/node_modules/@joe-broadhead/messaging-bin-darwin-arm64
-tar -xzf joe-broadhead-messaging-bin-darwin-arm64-0.3.0.tgz \
+tar -xzf joe-broadhead-messaging-bin-darwin-arm64-0.4.0.tgz \
   -C ~/.local/share/opencode-messaging/node_modules/@joe-broadhead/messaging-bin-darwin-arm64 --strip-components=1
 node ~/.local/share/opencode-messaging/dist/messaging.js --help    # the messaging CLI of this version
 ```
@@ -85,7 +85,7 @@ node ~/.local/share/opencode-messaging/dist/messaging.js --help    # the messagi
 { "plugins": [{ "package": "/Users/you/.local/share/opencode-messaging" }] }
 ```
 
-`npm install ./joe-broadhead-opencode-messaging-0.3.0.tgz` into a folder OpenCode loads works too: it
+`npm install ./joe-broadhead-opencode-messaging-0.4.0.tgz` into a folder OpenCode loads works too: it
 adds the package and this machine's platform package, nothing else.
 
 ## Install from a local path
@@ -139,15 +139,20 @@ or join a team (self-host)**; nothing is written until you pick. Then:
   thread. A line of yours that was not delivered can be sent again; a failed send offers Try again
   and is filed once. Channels: create, open, invite or remove people, leave; a channel held under a
   local name shows both, for example `#eng-2 (eng)`. Search: every word must match.
-- **Devices:** your devices with their vouch. In a hosted realm: **Link this device** (a QR code
-  and a six-digit code, on the new device), **Approve a new device** (paste its link, then type the
-  code the new device shows; the approving device never shows it), and remove this device.
+- **Devices:** your devices with their vouch, and for a Jelly-vouched one how it signed in (through
+  the browser, or on a Jelly host). In a hosted realm, a device that is no one's yet is offered
+  **Sign in with Jelly** first ([below](#sign-in-with-jelly)) and **Link this device** second (a QR
+  code and a six-digit code, approved from a device that already has Jelly). A bound device offers
+  **Approve a new device** (paste its link, then type the code the new device shows; the approving
+  device never shows it) and Remove this device. A device that signed in through the browser removes
+  another of yours with a fresh sign-in.
 - **Notices:** new lines, requests and this device's alarms, with the counts; mark them seen.
 - **Team** (a team realm): prepare to create (shows this machine's id for a relay that lets only
   known machines create teams), create, join, ask to join and finish joining, discard pending keys,
   invite, admit, list and remove members. Pending keys serve one purpose at a time.
 - **This device**, and the command **`/messaging-status`**: who you are, the realm and binding (the
-  managed realm by name, "Messaging by Jelly"), the relay, the directory, and any alarm with its
+  managed realm by name, "Messaging by Jelly"; how this device signed in; a sign-in still waiting in
+  the browser), the relay, the directory, and any alarm with its
   next step.
 
 Every error the console shows reads `<code>: <what happened>. Next: <step>.`
@@ -194,9 +199,10 @@ trusted on first use. In `/messaging`, on a fresh home:
    reached, the pinned values stand on their own.
 2. It writes the pinned realm into the home's `config.json` and starts the daemon, which makes this
    computer's keys.
-3. **Devices → Link this device** opens next: a QR code and a six-digit code. Approve it from a device
-   that already has Jelly and type the code there. Once it is approved, this computer is one of your
-   devices. A hosted person's first device is always one that Jelly enrols, so this is the way in.
+3. **Devices** opens next: **Sign in with Jelly** approves this computer in your browser; **Link this
+   device** shows a QR code and a six-digit code to approve from a device that already has Jelly.
+   Once it is approved, this computer is one of your devices. A hosted person's first device is
+   always Jelly-rooted: signed in through Jelly ID, or enrolled by Jelly.
 
 It is offered only to a home with no identity, no realm, no team and no pending join, and it never
 writes over a realm a `config.json` already has. A home in Messaging by Jelly has no `team.*`: it
@@ -204,6 +210,25 @@ cannot create or join a self-hosted team later. Agent tools never join a realm.
 the block by hand; [configuration.md](docs/configuration.md#messaging-by-jelly) has it, and
 [security.md](docs/security.md#messaging-by-jelly-the-pinned-realm) says how to check the key.
 
+## Sign in with Jelly
+
+In a hosted realm, a device signs in through the browser at Jelly ID, without another device
+(messaging 0.4.0's `device.login`). In `/messaging`, Devices, **Sign in with Jelly**:
+
+1. Choose to open Jelly ID in your browser, or to show the link (with a QR code, for another device),
+   copied if you ask. Over SSH the console opens nothing and says to open the link elsewhere.
+2. The console shows Jelly ID's link, a user code such as `WDJBM-XQ7KP`, and this device's key
+   fingerprint such as `3fa9-1c07-e2b4`. Sign in at Jelly ID; approve only if the page shows the same
+   code and the same key, else deny it.
+3. The console waits for the outcome and closes by itself: signed in, denied, expired or cancelled.
+   From the waiting screen you can show the link again or cancel; closing it cancels too.
+
+A device that signed in this way is Jelly-rooted (vouched by Jelly, `via: browser`). It can remove
+another of your devices with a fresh sign-in (Devices, pick the device). A device approved by QR
+cannot. **Until Jelly ID offers browser sign-in** (Jelly's contract v1.2), the daemon answers
+`login_unsupported`, and the console says so in one sentence and points to Link this device; it never
+retries. Agent tools never sign in: `device.login` is on the daemon's admin socket only.
+
 ## Docs
 
 - [Configuration](docs/configuration.md): every option and its default.