0.8.1

chore(release): bump version to 0.8.1 (#39)

No binary changes since 0.8.0; this bump exists to trigger
`release.yml`, which now publishes a multi-arch Docker image
to `ghcr.io/calimero-network/boot-node` (added in #38). The
metadata job in `release.yml` is gated on `release_exists ==
'false'` for the Cargo-manifest version, so a fresh version is
required to drive the buildx job that pushes:

  * ghcr.io/calimero-network/boot-node:0.8.1
  * ghcr.io/calimero-network/boot-node:latest
  * ghcr.io/calimero-network/boot-node:edge

Downstream merobox switches from a locally-bundled Dockerfile
(merobox#256+ no longer ships a NAT gateway image; the
boot-node image is the next bundled artifact to retire) to
pulling the `:edge` tag from GHCR, mirroring how it already
pulls `ghcr.io/calimero-network/merod`.

Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

0.8.0

relay: tune libp2p relay::Config for production-grade workloads (#36)

The boot-node was running with libp2p-relay's `Config::default()` for
every field except `max_circuit_bytes` (which had already been bumped
from 128 KiB to 100 MiB). The remaining defaults are sized for the
libp2p test-suite, not for a multi-user network, and they are visible
in clients' reservation-accept logs as:

    Limit { duration: Some(120s), data_in_bytes: Some(104857600) }
            ^^^^^^^^^^^^^^^^^^^
            libp2p default max_circuit_duration = 2 * 60 s

A 2-minute per-circuit lifetime is short enough that gossipsub mesh
formation, state-delta sync, and any non-trivial application stream
gets cut mid-flight. The 4-circuits-per-peer cap further limits how
many distinct remote peers a single client can talk to through this
relay simultaneously.

Set the following on top of `Config::default()`:

    max_circuit_bytes           = 1 GiB     (was 100 MiB)
    max_circuit_duration        = 1 hour    (was 2 minutes)
    max_circuits                = 4096      (was 16)
    max_circuits_per_peer       = 256       (was 4)
    max_reservations            = 2048      (was 128)
    max_reservations_per_peer   = 8         (was 4)

These values size a single relay instance for ~200 active users
holding circuits to ~20 distinct peers each, with sync/state-delta
streams allowed to run for an hour and up to 1 GiB per circuit. The
EC2 instance hosting the relay should be at least `c7g.large`
(2 vCPU / 4 GiB RAM) to provide enough memory for per-circuit state
at these caps; the current `c7g.medium` (1 vCPU / 2 GiB) will be
tight under the new totals.

Reservation/circuit rate-limiters remain at libp2p defaults
(30/peer/2min and 60/IP/min). Those weren't the binding constraint
in the failure-mode logs that motivated this change, and leaving
them in place keeps a sensible abuse-prevention floor.

Bumps version to 0.8.0 for the AMI / Terraform pin to track.

Related: calimero-network/infrastructure#89 (fleet expansion + EC2
sizing), calimero-network/core#2438 (client-side complement: dial
throttling, address filtering, AutoNATv2 candidate filtering).

Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

0.7.0

chore: bump version to 0.7.0

0.6.0

feat: expose prometheus metrics (#22)

0.5.2

chore: bump relay max bandwidth to 100MiB (#21)

0.5.1

chore: define max circuit bytes (#19)

chat-example-0.5.0

fix: remove success logs when rendezvous discovery fails due to no ex…

chat-example-0.4.0

ci: install cross before doing cross compilation build, fix typo (#15)

chat-example-0.3.0

feat: implement relay and rendezvous peer discovery based on identify…

chat-example-0.2.0

feat: implement mdns and rendezvous peer discovery (#9)

* feat: implement mdns and rendezvous peer discovery

* chore: bump version, cleanup logging

* docs: update readme

* feat: replace HashMap with BTreeMap for relays and rendezvous