novox/hq
3
0
Fork 0
Code Issues Pull Requests Releases Wiki Activity

Design 25: a scoped inbox needs allow_responses, or nothing can answer

Browse Source 
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.
This commit is contained in:
jschoubben
2026-09-26 20:58:34 +02:00
parent e05825a881
commit 3f9b316015
1 changed files with 11 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files
03-DESIGN/01-to-be/25-the-bus-on-nats.md
+11
View File
@@ -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 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 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. 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 - **One user per module per node**, as today, with publish permissions
`mesh.events.<module>.<event>` for each emit, `mesh.tools.<module>.>` to serve its tools, its `mesh.events.<module>.<event>` for each emit, `mesh.tools.<module>.>` to serve its tools, its
own ack-reply subject for each durable consumer it holds, and its own inbox prefix; subscribe own ack-reply subject for each durable consumer it holds, and its own inbox prefix; subscribe