From 3f9b316015e4ec0603833e1e6d8ca2f22da403bf Mon Sep 17 00:00:00 2001 From: jochen Date: Sat, 26 Sep 2026 20:58:34 +0200 Subject: [PATCH] Design 25: a scoped inbox needs allow_responses, or nothing can answer Found composing the first real configuration. Scoping every inbox to its owner is right and leaves a responder unable to reply, because the answer goes to the caller's inbox. The fix is not a wider grant but the server's own allow_responses: one reply to the subject of a message the user actually received. Without it every tool call times out while the permission list looks correct. --- 03-DESIGN/01-to-be/25-the-bus-on-nats.md | 11 +++++++++++ 1 file changed, 11 insertions(+) diff --git a/03-DESIGN/01-to-be/25-the-bus-on-nats.md b/03-DESIGN/01-to-be/25-the-bus-on-nats.md index 84c5340..61bdb53 100644 --- a/03-DESIGN/01-to-be/25-the-bus-on-nats.md +++ b/03-DESIGN/01-to-be/25-the-bus-on-nats.md @@ -129,6 +129,17 @@ expresses this exactly, per subject, and better than a vhost could: permissions name only that one prefix, for the reply to any request it makes and nothing wider. First review found the account note without this and read it as "any user may subscribe any inbox" — which was accurate against the text as it stood. + + **And a scoped inbox needs `allow_responses`, or nothing can answer.** Revision, found while + composing the first real configuration: the rule above scopes each user's inbox to itself, + which is right — and leaves a responder unable to reply, because the answer goes to the + *caller's* inbox, which the responder has no permission for. The two ways out are granting + every responder `_INBOX.>`, which is exactly the blanket grant this bullet refuses, or NATS's + own `allow_responses`: the server permits one reply to the reply-subject of a message the user + actually received, within a TTL, and nothing else. So authority to answer is bounded by having + been asked, and only principals that serve something are granted it — a pure consumer gets + nothing. Without this the scoping is not merely incomplete: every tool call in the mesh times + out, and the permission list looks correct while it happens. - **One user per module per node**, as today, with publish permissions `mesh.events..` for each emit, `mesh.tools..>` to serve its tools, its own ack-reply subject for each durable consumer it holds, and its own inbox prefix; subscribe