@joe-broadhead/opencode-messaging 0.3.0 → 0.5.0

package/CHANGELOG.md

@@ -6,6 +6,75 @@ All notable changes to `@joe-broadhead/opencode-messaging`. Versions follow
 
 ## [Unreleased]
 
+## [0.5.0] - 2026-11-07
+
+Published on npm (public). The release that carries the `jelly` declaration (hey-jelly#36, A13) and runs
+inside Jelly (A3, A4). Built against `@joe-broadhead/messaging` **0.5.0** (vendored, release commit `0462258`:
+`37723bf`, which includes the Jelly mode lane `10438fe`, plus three fixes), and ships with the 0.5.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.5.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.4.x daemon is refused at the IPC
+hello (`daemon_mismatch`). Messaging 0.5.0 brings the environment start contract, `cls` required with `view`
+on reads, `notice.ack` as `chat`, previews taking their action's whole input, `request.answer.preview`,
+`daemon.woke`, `person.attached`, `daemon.snapshot`, wake tickets, `ACTION_CLASSES`, and renewal of a
+session ticket by key. Nothing is removed: outside Jelly the plugin behaves as in 0.4.0.
+
+- **The `jelly` declaration** in `package.json`, as Jelly's master reads it: title, summary and icon
+  (`assets/icon.svg`); the eight tools (`messaging.read` or `messaging.send`, `allow`, read-only where
+  they only read); `asks: ["messaging.send"]`; `resources: ["messaging"]`; the `messaging` service
+  (`agent.sock`, `admin.sock`, `daemon.health` on the agent socket, wakes, `identity.json` and
+  `pairing.json` left out of backups); the section (`views/section.html`: People, Chats, Requests,
+  Devices, Your agents) with its eleven read-only methods; twelve service actions with Jelly's
+  classes and confirmations (`person.send` chat/session; `conv.markRead`, `notice.ack` chat/never;
+  `request.answer`, `grant.set`, `contact.request`, `channel.*`, `device.approve`, `device.remove`
+  local/always, with the daemon's previews); notices (Message, Request, Messaging alert); `turns`
+  labelled "Messages"; and `requires` `service`, `section`, `actions`, `turns`, `notices` and
+  `resources`, never `act`. It is built from the vendored daemon's IPC schemas
+  (`npm run jelly:update`), `check:package` validates it with Jelly's rules, and a test holds every
+  action's class, every section read (`view`, or agent tier with no grant) and every preview's class
+  equal to the daemon's `ACTION_CLASSES`.
+- **Inside Jelly** (Jelly's services accessor is present): the plugin connects to the agent socket
+  Jelly names, never starts a daemon, never resolves a home or reads `~/.messaging`, and registers
+  exactly the session name Jelly's ticket names, with the ticket. Every OpenCode session of the agent
+  shares that one Messaging session. Renewal is messaging 0.5.0's: when the agent's ticket ends, the
+  daemon keeps the session and its mail and answers `ticket_invalid`; the plugin re-reads Jelly's
+  accessor, registers the same key with the fresh ticket on the same connection, and makes the call
+  again. If the accessor still holds the ended ticket, the tool says to restart the agent in Jelly.
+- **Turns through Jelly:** inside Jelly a wake files a `turn` request with Jelly's core plugin (the
+  sender person as key, `own`, `trusted` or `guarded` from the daemon's record, a fixed prompt)
+  instead of prompting a session; every refusal falls back to notes. A guarded turn keeps the plugin's
+  Messaging send and read limit; Jelly's `jelly.peer` mark fences the rest.
+- Inside Jelly there is no console (the `config` RPC refuses) and no setup note.
+- Without the accessor nothing changes.
+- **Not yet:** the plugin does not raise the declared notices itself (Jelly reads the service's
+  counts for its badge), and the section page has no search and no card refresh.
+
+## [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.5.0.tgz -C ~/.local/share/opencode-messaging --strip-components=1
+npm pack @joe-broadhead/messaging-bin-darwin-arm64@0.5.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.5.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.5.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,85 @@ 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.
+
+## Running inside Jelly
+
+Jelly installs this package as a curated plugin with a service: Jelly's host runs the pinned
+`messagingd` itself, as the host owner's, and hands each agent's engine its place in it. The
+package's `jelly` declaration (in `package.json`) says what Jelly runs and draws. It is built from the
+vendored daemon's own method schemas by `npm run jelly:update`, and `npm run check:package` checks it
+with Jelly's rules.
+
+**How the plugin knows.** In a Jelly engine,
+`globalThis[Symbol.for("jelly.services")]?.get("@joe-broadhead/opencode-messaging")` answers
+`{ socket, name, ticket, expiresAt }`: the service's agent socket, the one session name this agent
+may use, and a session ticket that proves it. When that accessor is present, the plugin:
+
+- connects to that socket and **never starts a daemon** (`daemon.autostart`, `daemon.bin` and
+  `daemon.node` do nothing there), and never resolves a Messaging home, reads `~/.messaging` or looks
+  for `identity.json`; the host enrolled the service's device;
+- registers **exactly the ticket's name, with the ticket**, and no wake host. Every OpenCode session
+  of the agent (its conversation, and each turn Jelly starts) speaks as that one session, so
+  teammates see one address per agent;
+- renews with Jelly's fresh ticket. Jelly keeps the accessor's ticket current (a new one for the
+  same agent and name before `expiresAt`). Once the ticket the agent registered with ends, the service
+  keeps the session and its mail and answers its calls `ticket_invalid`; the plugin then reads the
+  accessor again, registers the same key with the fresh ticket on the same connection (which takes
+  the registration back for every connection of the agent), and makes the call again. A refused
+  `session.register` is retried the same way. If the accessor still holds the ticket that ended, the
+  tool says to restart the agent in Jelly, and the next call reads the accessor again;
+- starts **turns through Jelly**, never by prompting a session: a wake becomes a `turn` request to
+  Jelly's core plugin, one per sender person, with that person as the conversation key, the profile
+  from the daemon's record (`own` for your own devices and agents, `trusted` only when the daemon
+  calls every item trusted, else `guarded`) and a fixed prompt that carries nothing a peer wrote. Jelly
+  decides: only while the agent's owner has turned "Messages can start work" on, within Jelly's
+  budget. Any refusal (`invalid`, `agent`, `not_declared`, `off`, `budget`, `engine`) gives the items
+  notes in the agent's conversation instead. The plugin's per-person wake budget still applies;
+- in a guarded turn keeps its own Messaging limit (reads and sends reach the person the turn is for,
+  and nothing waits on a person), and leaves the rest of the fence (no shell, edits only in the
+  conversation's folder, no outward tools) to Jelly's own `jelly.peer` mark. It sets no session
+  permissions and removes no tools there. A turn Jelly marked that the plugin has no record of may
+  not read or send at all.
+
+Without the accessor, nothing above applies, and the plugin behaves exactly as in stock OpenCode.
+
+**What Jelly draws instead of `/messaging`.** Jelly runs no terminal UI: the person's console is the
+plugin's **section**, a sealed page in Jelly's navigation (`views/section.html`) with People, Chats,
+Requests, Devices and Your agents. It reads through the service's admin socket (each read is a
+declared read-only method; Jelly signs it with class `view`) and changes things only through the
+declared actions, each under the confirmation Jelly draws in its own words:
+
+| Action | Class | Confirmation |
+|---|---|---|
+| `person.send` | `chat` | once per opening |
+| `conv.markRead`, `notice.ack` | `chat` | none |
+| `request.answer`, `grant.set`, `contact.request`, `device.approve`, `device.remove` | `local` (owner devices) | every time, with the daemon's preview |
+| `channel.create`, `channel.invite`, `channel.remove`, `channel.leave` | `local` | every time |
+
+Under Jelly the plugin's `config` RPC refuses, so a TUI part loaded there anyway connects to nothing
+and starts nothing. The section's badge is Jelly's own count from the service (`notice.list`, unread and
+waiting). The declaration names the notices a banner may show (Message, Request, Messaging alert);
+this release does not raise them yet. The service's key files (`identity.json`, `pairing.json`) are
+left out of Jelly's backups.
+
 ## Docs
 
 - [Configuration](docs/configuration.md): every option and its default.

package/assets/icon.svg

@@ -0,0 +1 @@
+<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 24 24" fill="none" stroke="currentColor" stroke-width="1.8" stroke-linecap="round" stroke-linejoin="round"><title>Messaging</title><path d="M4 5.5A2.5 2.5 0 0 1 6.5 3h11A2.5 2.5 0 0 1 20 5.5v7a2.5 2.5 0 0 1-2.5 2.5H11l-4.5 4v-4h0A2.5 2.5 0 0 1 4 12.5z"/><path d="M8 8h8"/><path d="M8 11h5"/></svg>