@mmmbuto/nexuscrew 0.9.64 → 0.9.66

package/CHANGELOG.md

@@ -2,6 +2,24 @@
 
 All notable changes to NexusCrew are tracked here.
 
+## 0.9.66 — 2026-10-10
+
+- **An imported ASK from a cell with a custom tmux session can be dismissed on this node.** The local dismissal looked the cell up by decoding the session name, which only works for `cloud-*` names, so an ASK from a session such as `lab-Dev` answered 404 "unknown or invisible ask" although the node holds the grants and the owner publishes the ASK. The owner now publishes, with each ASK of its snapshot, the cell it resolved through its own definitions; this node keeps it (from the snapshot, from the cell-scoped live envelope, or from the attested origin of a pushed ASK), validates it at the authenticated ingress, binds it to the owner and to the generation of the ASK, and uses it before the name. A cell is never guessed from a name, never read from this node's own definitions and never accepted from the request. A card persisted by an older release with no authenticated cell is refused with `cell-unresolved` instead of a generic 404, and an answer in flight or of uncertain delivery still blocks the dismissal. Non-canonical names resolve only when the owner runs this release; with an older owner only canonical names decode.
+- **A remote peer can be published one way to your own admin nodes.** `nexuscrew nodes publish-remote <peer> on --audience <instanceId,...>` (and `off`, `status`) makes a peer you reach over your private `-L` tunnel visible and operable to an explicit audience of your operator nodes, while the peer reaches nothing of yours: no peer, no route, no topology, no protocol endpoint but the health probe. It is separate from Share and never restarts SSH, opens a reverse channel or touches the reverse pool.
+- **Turning it on zeroes every grant towards the peer in the same save, and widening them is refused while it is on.** Cell scope none; events, node events, files, ASK replies, operator, panel and live host off; `eventsReceive` off. `off` ends the publication and leaves the grants at zero.
+- **The topology announces the peer as a leaf, only to the audience.** What the peer reports about its own children is never requested, relayed or cached, and entries cached before the mode was turned on are purged.
+- **The store moves to schema 4 only at the opt-in, after a full protected backup.** Older stores keep loading unchanged; a release before 0.9.66 cannot read a schema 4 store, so going back means restoring the backup taken at the opt-in.
+- **`nodes inspect` shows the real grants.** It read the peer from a redacted view that carried no access fields, so it printed every grant as off and the peer as unconfigured while `nodes access` and the authorization code saw them granted. The redacted record now carries the grants and the configured marker.
+- **The access views show the grants the resource gate applies, also for records from before the grants were configured.** `nodes inspect`, `nodes access` and the node lists of Settings printed an all-denied vector for any record without the `accessConfigured` marker, while the gate reads the stored values and ignores the marker: a legacy record with `eventsAccess` and no marker read "unconfigured, off" and was granted. The views now show the real vector (seven flags and the cell scope) and keep the label and the configured flag as provenance; `nodes inspect` adds a note for a record that is not configured. What is granted does not change, and the event stream still requires a configured vector.
+
+## 0.9.65 — 2026-10-09
+
+- **Notifications from a remote node can be cleared locally, one voice or all at once.** Every imported notice offers the same close action asks already have: one request dismisses a single notice or the whole visible set of an owner. The dismissal travels to the owner over the authorized routes and is judged by the origin's view; the owner records it and publishes one `notify-closed` closure per cleared notice, so every receiver empties, including the ones that were not part of the clear. When the owner cannot take it — unreachable, or without the notices surface — the request still succeeds: the node records the intent durably, as pending with a bounded retry or as blocked until the pairing changes, and the record, not the browser, is what keeps the card down. A reload or a restart of the receiving node does not bring a cleared notice back, and once the owner takes the dismissed intent he stops serving those notices himself. "Clear" means the whole visible set of that owner on this node: every notice currently shown for him, cleared in one request inside the owner's per-request budget.
+- **A dismissal queue that cannot persist says so.** The queue still honours a cleared notice in memory when the disk refuses the write, but the operator's answer no longer looks like the durable success: queued answers (the single dismiss and the pending/blocked outcomes of clear-all) carry `durable: false` and a `degraded` reason (`queue-write-failed`, `queue-oversize`, `queue-read-failed`, `queue-schema`) when the queue cannot be written or read. The loss is real and now visible: after a restart the cleared card can come back, and the answer warns about it before that happens. A healthy write clears the flag again, and the answer returns to its normal shape.
+- **A queue file that cannot be read is never overwritten with a partial list.** When the queue file is unreadable, foreign or oversize at the first read, the node retries the read before any write, merges what the disk holds with the dismissals accepted in the meantime, and replays them in order on top of the disk. The queue keeps its bounds (200 records, 64 KiB, 15 minutes): when it is full the oldest records leave, never the dismissal just accepted. While the disk stays unreadable the answers keep declaring `durable: false` and the reason.
+- **A missed closure heals at the next read.** A browser that misses a notice's live closure frame kept the card on screen even after a fresh, complete feed-state read no longer listed the notice. For every owner whose view is fresh and authoritative, the notice panel now reconciles against that read: what the owner no longer serves goes, and a card that arrived while the read was in flight stays. Stale, incomplete or resync-flagged views keep their cards as before.
+- **An owner with a full window is no longer refused as incomplete.** A snapshot page cut exactly at its cap (50 notifications, 100 asks) was marked as incomplete on every full page, so a receiving node refused the snapshot of an owner with a full window, imported nothing and never opened the stream. The marker now means that the source had more entries than the page holds; a page exactly at the cap is whole and accepted, and a page over the cap or flagged for resync is still refused.
+
 ## 0.9.64 — 2026-10-07
 
 - **The active quick list hides stopped cells.** The active mode keeps only live cells and active degraded rows, regardless of each node's saved all or pinned preference; ordering and pins remain intact.

package/docs/NODES.md

@@ -85,6 +85,49 @@ Temporary loss of reachability does not revoke consent. An authorized node
 remains visible as stale/offline until an authoritative refresh restores it or
 confirms withdrawal.
 
+## Publish a remote node, one way (host-only)
+
+Share publishes **this** installation on a peer's hub. The opposite need is
+real too: a remote node you reach over your own private `-L` tunnel (a sandboxed
+box, say) that your own admin nodes must be able to see and operate, while the
+remote node must see nothing of yours. That is the **host-only publication**:
+
+```bash
+nexuscrew nodes publish-remote <name|nodeId> on --audience <instanceId>,<instanceId>
+nexuscrew nodes publish-remote <name|nodeId> off
+nexuscrew nodes publish-remote <name|nodeId> status [--json]
+```
+
+- It is **not Share**. It never calls the Share path, restarts SSH, opens a
+  reverse (`-R`) channel or touches the reverse pool: the tunnel stays the
+  private `-L` it was.
+- The **audience** is an explicit list of `instanceId`s of your own direct peers
+  that already hold the operator grant. Unknown ids, ids of peers without that
+  grant and the published peer itself are refused. There is no wildcard.
+- The boundary is one-way and is decided here, on the installation that owns
+  the tunnel. An audience member (operator grant re-read on every call) reaches
+  the peer; **the peer reaches nothing** — no other peer, no route, no topology,
+  nothing of this installation — whatever grants its record carries or gains.
+  Everyone else, including your other admin nodes, does not see it at all.
+- The topology announces the peer as a **leaf**, only to the audience: what the
+  peer says about its own children is never requested or relayed.
+- Turning it on zeroes, in the same single save, every grant towards the peer
+  (cell scope none; events, node events, files, ASK replies, operator, panel and
+  live host off; `eventsReceive` off), and any later edit that would widen them
+  is refused while the mode is on. `off` ends the publication at once and leaves
+  the grants at zero: reopening anything is an explicit act.
+- Turning it on moves the store to **schema 4**, and only then, after taking a
+  full protected backup next to `nodes.json`
+  (`nodes.json.pre-publish-remote-<time>-<sha>.bak`, mode 0600). Older stores
+  keep loading unchanged. A release older than 0.9.66 cannot read a schema 4
+  store (the schema is closed): going back means restoring that backup.
+- Already-open streams (a terminal attached before `off`) are not torn down by
+  `off`; new calls are refused. Read `off` as "no new request", not as an
+  instant cut of a channel that is already open.
+- A reader's topology cache is emptied by the **next authoritative answer** from
+  this installation. A reader that cannot reach it keeps showing the peer, marked
+  stale, until then; nothing is pushed to it.
+
 ## Which cells a node may see
 
 Sharing decides whether a node is reachable. A **cell scope** decides how much
@@ -200,6 +243,7 @@ nexuscrew nodes test                    # every peer, plus what is only claimed
 nexuscrew nodes up|down|connect|disconnect <name|nodeId>
 nexuscrew nodes restart|reconnect <name|nodeId>
 nexuscrew nodes share <name|nodeId> on|off
+nexuscrew nodes publish-remote <name|nodeId> on --audience <id,...>|off|status
 nexuscrew nodes cells <name|nodeId> all|none|Cell1,Cell2
 nexuscrew nodes remove <name|nodeId> --yes
 ```

package/docs/NOTIFICATIONS.md

@@ -119,6 +119,40 @@ browser, keeps the app fully usable, and never changes the other side's push
 setup. Turning it back on requires the same button, so a device that was asked
 to stay silent does not re-subscribe itself.
 
+## Clearing imported notifications
+
+An imported notice can be closed like a local one, for a single notice or for
+the whole visible set of one owner with a single request. The closure is not a
+browser-side hide; the protocol keeps every view of that owner honest:
+
+- **The owner records it.** The dismissal travels the authorized routes to the
+  owner, is judged by the origin's view, and is answered by one `notify-closed`
+  closure frame per cleared notice. Closures enter the owner's feed history, so
+  a receiver that was offline recovers them from the backlog; the receiving
+  side never turns a closure into a card.
+- **Every receiver empties.** Once the owner has recorded the dismissal he
+  stops serving those notices, so no node that holds a view of him keeps
+  showing them, whether it was live during the clear or reloads afterwards.
+- **The intent survives when the owner cannot take it.** If the owner is
+  unreachable the clear still succeeds: the node records the intent durably
+  (a bounded local queue, retries with backoff, one delivery attempt per owner
+  at a time) and hands it over when the owner is back. If the owner has no
+  notices surface at all the record stays blocked until the pairing changes.
+  In both cases the record — not the browser — is what keeps the card down: a
+  reload or a restart of the node does not bring it back. If the queue cannot
+  write (disk refusal), the intent is still honoured in memory but it cannot
+  survive a restart: the answer declares it with `durable: false` and the
+  degradation reason, instead of looking like the durable success.
+- **A browser that misses a closure heals at the next read.** The closure
+  frame travels live; a browser that never received it (offline, tab asleep)
+  catches up at the next fresh feed-state read, which reconciles the panel
+  with what the owner still serves. Views that are stale, incomplete or
+  flagged for resync never reconcile, so a degraded feed cannot silently
+  empty the panel.
+- **"Clear" is the whole visible set of that owner.** It closes every notice
+  currently shown for him on this node, in one request inside the owner's
+  per-request budget — never one request per card.
+
 ## Platform notes
 
 | Platform | Expected behavior |

package/docs/SECURITY.md

@@ -107,6 +107,46 @@ Federated ASK creation and closure go only to configured `admin` peers, hop by
 hop. Each hub checks its own next peer before forwarding. This rule does not
 change generic notifications or the relay of ASK replies.
 
+### Host-only publication
+
+`nexuscrew nodes publish-remote <peer> on --audience <ids>` publishes a remote
+peer to an explicit audience of your own operator nodes and nothing else (see
+[Connect nodes](NODES.md)). The security properties, each covered by a test:
+
+- **One way.** The check is on the authenticated peer record found by its token,
+  never on a header, a query or the visited chain. Audience → peer is allowed;
+  peer → anything is refused in the route relay, in the WebSocket upgrade, in
+  the topology collector and on every protocol endpoint except the health
+  probe.
+- **Two locks on the peer's own access.** All grants towards it are zeroed in
+  the same save that turns the mode on, and the class gate refuses a host-only
+  peer regardless of the grants its record shows. The `user` preset with no
+  visible cell does **not** give this: it keeps events, node events and file
+  reads granted. Do not use it as an isolation boundary.
+- **Re-read, not remembered.** Audience membership and the operator grant are
+  read from the store on every call; revoking either, or turning the mode off,
+  takes effect on the next request.
+- **No Share, no reverse channel.** The mode cannot coexist with Share on the
+  same peer, and enabling Share on a published peer is refused before any SSH
+  restart is attempted.
+- **Not covered:** a stream opened before `off` stays open until it closes (the
+  next upgrade is refused), a reader that cannot reach this installation keeps
+  its cached view of the peer until its next authoritative answer, and an
+  audience member is itself trusted to forward further according to its own
+  access rules.
+
+### What the access views show
+
+`nodes inspect`, `nodes access` and the node lists of Settings show, for each
+peer, the grants **the resource gate applies** — the stored values, read the way
+the gate reads them — together with a label and a *configured* flag. The label
+and the flag say how the vector was set (a preset, or a record from before the
+grants existed that was never configured); they do not change what is granted.
+A record that is not configured but carries a grant is shown with that grant on
+and the label `unconfigured`. The event stream is stricter than the resource
+gate: it also requires a configured vector. Apply a preset to make a legacy
+record explicit.
+
 ### Cell scope
 
 A per-node cell scope narrows what one paired node sees and can act on. It is