Skip to content

feat(config): node LAN exposure switches — monero.zmq_lan_access + tari.grpc_lan_access#761

Merged
VijitSingh97 merged 1 commit into
developfrom
feat/760-tari-grpc-lan-access
Jul 24, 2026
Merged

feat(config): node LAN exposure switches — monero.zmq_lan_access + tari.grpc_lan_access#761
VijitSingh97 merged 1 commit into
developfrom
feat/760-tari-grpc-lan-access

Conversation

@VijitSingh97

Copy link
Copy Markdown
Collaborator

Closes #760. The serving side of the remote-node modes (#103): one stack's synced nodes become consumable by other stacks through config alone.

Why

monero.rpc_lan_access existed but publishes only the RPC — a remote P2Pool needs the ZMQ feed too — and the Tari base node published nothing at all. Serving another stack today means hand-run socat forwards (exactly what the #78 bench setup did on gouda this week). After this PR that whole arrangement is three config keys.

What

  • monero.zmq_lan_access (default false): publishes monerod's ZMQ feed (18083); loopback-only otherwise. A separate key from rpc_lan_access deliberately — that key's documented use is wallets, and widening it would silently change existing deployments' exposure.
  • tari.grpc_lan_access (default false): publishes the bundled Tari base node's gRPC (18142); loopback default matches the console-wallet gRPC publish's stated trust boundary. Ignored in tari.mode: remote (the service is profile-gated off; nothing binds).
  • Security posture inherited from MONERO_RPC_BIND: both binds are host-only DEST in describe_change when flipping to 0.0.0.0 (not dashboard-editable, not confirm-gated), with the no-auth trust warning in the message. Trust model is feat(tari): remote Tari base-node mode (#103) #754's, stated at every switch: plaintext/unauthenticated feeds, trusted networks only.
  • Docs: config-reference rows + both remote-node sections now name the serving-side switches; CHANGELOG entry under Unreleased.

Coverage (tier 1, per the testing strategy)

Verified locally

make test-stack 1682 passed / 0 failed · make test-compose green · make test-frontend green (config-group completeness covers the new keys) · shellcheck/shfmt, biome, yamllint, markdownlint, docs-voice all pass.

🤖 Generated with Claude Code

…_lan_access (#760)

The serving side of the remote-node modes. monero.rpc_lan_access existed
but published only the RPC — a remote P2Pool needs the ZMQ feed too, and
the Tari base node published nothing at all, so serving another stack
meant hand-run socat forwards (what the #78 bench setup did on gouda).

- monero.zmq_lan_access: publishes monerod's ZMQ (18083); a separate key
  from rpc_lan_access on purpose — that key's documented use is wallets,
  and widening it would change existing deployments' exposure.
- tari.grpc_lan_access: publishes the bundled Tari base node's gRPC
  (18142); loopback by default, matching the console-wallet publish's
  trust boundary. Ignored in remote mode (the service is profiled off).
- Both flips to 0.0.0.0 are DEST in describe_change (host-only, like
  MONERO_RPC_BIND), with the no-auth trust warning in the message.
- Docs: config rows + the remote-node sections now name the serving-side
  switches; CHANGELOG entry.
- Tier 1: describe_change direction tests + the #523 black-box render
  extended for all three binds (default localhost, true → 0.0.0.0).

Closes #760.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
@VijitSingh97
VijitSingh97 merged commit 9ee2f0b into develop Jul 24, 2026
16 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

tari.grpc_lan_access: publish the Tari base-node gRPC on the LAN (serving side of #103)

1 participant