OpenNet v0.2.0

OpenNet v0.2.0

OpenNet v0.2.0 adds one boundary I wanted to make explicit: a valid connection
is not automatically permission to use every topic.

I thought about putting identity and permissions directly into ONP/1, but that
would force one authorization model onto small home projects, classroom labs,
and certificate-managed deployments alike. Instead, this release keeps every
ONP/1 byte unchanged and adds an optional policy callback to the Python server.

What is new

• OpenNetServer(..., authorizer=...) accepts a synchronous or asynchronous
  decision function.
• Peer.tls_enabled reports whether the connection uses TLS.
• Peer.tls_peer_certificate exposes the certificate dictionary supplied by
  Python's verified TLS layer.
• ServerStats.authorization_denials counts fail-closed policy decisions.
• Arduino receive callbacks reuse the validated frame allocation for payloads
  instead of copying into a second vector.
• Constrained firmware can instead use a caller-owned receive buffer and
  onMessageView, while poll work, writes, and outstanding ACKs are bounded.
• CLI file sends are size-checked before reading, server logs hide values by
  default, and repeated --allow-topic-prefix options provide a simple shared
  allowlist.
• Connection and handler overload paths return bounded ERROR responses before
  closing instead of failing silently.
• CI, CodeQL, and release workflows pin third-party actions to immutable commit
  IDs.
• Deterministic network-fault coverage now exercises concurrent sends,
  byte-by-byte frame truncation, fragmented ACK delivery, and 2,240 single-bit
  or seeded-random header mutations.
• The release workflow now runs native Arduino tests and the ESP32 build before
  packaging a tag.

Oh! The ordering is the important part here. The authorizer runs after strict
frame validation but before duplicate suppression, the application handler, and
the ACK. A denied frame receives a generic ERROR and the connection closes. An
authorizer exception follows the same path without exposing its details. An
accepted frame is ACKed before bounded handler dispatch; handler completion is
an application result rather than a transport-delivery signal.

Compatibility

ONP/1 remains version 1. The 24-byte header, frame kinds, flags, value types,
CRC-32, and Arduino/Python frame bytes are unchanged. ACK emission now follows
the existing transport-acceptance definition consistently; it still uses the
same ONP/1 ACK frame. Existing Python servers do not need to provide an
authorizer, and existing Arduino constructors and onMessage callbacks remain
source-compatible while the bounded alternatives are optional.

The enum wire-facing types remain explicitly one byte, with compile-time checks.
The C++ object size itself remains toolchain-dependent; the documented memory
model separates bounded frame bytes from String, vector, allocator, transport,
and TLS overhead.

Python and Arduino also consume one shared malformed-frame vector set for UTF-8,
JSON, control text, and typed scalar validation. JSON nesting is bounded to 32
arrays/objects in both implementations.

Install

python -m pip install \
  https://github.com/devkyato/OpenNet/releases/download/v0.2.0/opennet_protocol-0.2.0-py3-none-any.whl

Arduino IDE users can install OpenNet-0.2.0.zip. Linux or Raspberry Pi users
can extract OpenNet-linux-0.2.0.tar.gz and run sudo ./install.sh. Check every
download against SHA256SUMS.

Verification

• 113 Python tests, including authorization, real loopback mutual TLS, control
  backpressure, timeout, concurrency, truncation, and deterministic mutation
  paths.
• Strict Ruff and mypy checks.
• Native C++ protocol tests, the main esp32dev firmware build, and all four
  Arduino example compiles.
• Local documentation links, a fresh-wheel import/CLI smoke test, matching
  release checksums, and reproducible Arduino/Linux bundles.

These tests do not turn into a hardware field claim. The existing measured
loopback numbers remain labeled as v0.1.1 results, and direct BLE GATT remains
unsupported.

For the narrative walkthrough, see
Authorizing topics.
The exact security boundary remains in the
security guide.