Manifest

The access manifest is an optional JSON sidecar that tells the broker how to screen traffic before your handler runs. The filename alone gets a port open to everyone; the manifest is how you lock it down. Proposed the format below.

The sidecar file

A manifest sits beside its handler, sharing the whole name up to the extension:

echo.tcp.7000.port.js       the handler
echo.tcp.7000.port.json     its access manifest

The pattern is <name>.<proto>.<port>.port.json. It syncs like any supporting file but opens no port of its own — it only configures the handler it names.

Fields

Field	Type	Meaning
`allow`	string[]	Source CIDRs permitted to connect (`"10.0.0.0/8"`, `"203.0.113.4/32"`). If present, anything not matched is denied.
`deny`	string[]	Source CIDRs refused. Evaluated after `allow`, so `deny` wins on overlap.
`maxConnections`	number	TCP only — the ceiling on concurrent connections the broker will hold open for this handler. Further connections are refused until one closes.
`rateLimit`	object	Per-source limit, `{ perIp: number, window: seconds }` — new TCP connections or UDP datagrams per source IP per window. Excess is dropped.
`tls`	object	`{ enabled: boolean, cert: … }`. TCP only. When enabled the broker terminates TLS and hands the handler plaintext (see Q5). Cert source shape is not yet fixed.
`idleTimeout`	number	Seconds a connection (TCP) or a source's session window (UDP) may sit with no traffic before the broker closes or forgets it.

Example

{
  "allow": ["10.0.0.0/8", "203.0.113.0/24"],
  "deny": ["10.9.0.0/16"],
  "maxConnections": 256,
  "rateLimit": { "perIp": 20, "window": 10 },
  "tls": { "enabled": true, "cert": "on-demand" },
  "idleTimeout": 120
}

Defaults when absent

With no manifest, the filename still runs — under permissive defaults, so the manifest is purely additive lockdown.

Field	Default with no manifest
`allow` / `deny`	Open to all sources.
`maxConnections`	A sane connection cap the broker sets, not unlimited — enough to run, low enough to avoid a trivial exhaustion.
`rateLimit`	None applied.
`tls`	Off — plaintext.
`idleTimeout`	A default idle cutoff so abandoned connections don't accumulate.

Precedence with a module `access`

A module may also export an access object. The intent is a split by when the value is needed: anything the broker must know before running your code — allowed sources, TLS, caps — is authoritative in the sidecar, so policy and the firewall can act before a single line of the handler executes. A module access can only refine per-connection decisions the broker makes after hand-off — it cannot loosen what the sidecar locked.

⚑ Open question · Manifest: sidecar vs exported vs both (Q3)

Where should access policy live — a sidecar <name>.<proto>.<port>.port.json, an access object exported by the module, or both? The sidecar can be read without executing any handler code, which is exactly what you want for anything the broker enforces before a connection reaches your code (allowed sources, TLS, connection caps): policy and the OS firewall can act on it up front. An exported object is more ergonomic and lives next to the logic, but reading it means loading and running the module.

Proposed: the sidecar JSON is authoritative for everything the broker must know before running handler code; the module may only refine per-connection decisions after hand-off. Open: whether to support the exported form at all, and the exact precedence rules if both are present.