HyperNet 0.10.4

Core 0.10.4 fixes relay admission when a valid renewed route voucher follows a cached older generation. New references still require fresh certified context, possession, a current Permit and normal consumption accounting.

Page submissions now advance the last content revision, independently of the ledger record generation. Approved revision 1 can be followed by submitted revision 2. Use Suite 0.10.3 for the matching client verification.

Quiesce activity and ensure every old authority replica has fully applied the same committed history before the coordinated stopped upgrade. Use signed packages and the normal reviewed runtime transition; retain keys, journals, floors, usage and Page history. See Documentation/UpgradeRecovery.md and Runtime.md. Existing deployment and platform qualification limits remain.

Verify the signed archive and exact finite target policy with your independently pinned publisher key. Download the corresponding source and unchanged system-library source archives alongside the binary package when redistributing this release.

HyperNet 0.10.3

Core 0.10.3 supports explicitly reviewed renewal of stopped relay and application services while retaining their network, service, endpoint, TLS and application identities. Route generations advance under current authority and consent; privacy and resource limits remain fixed, and withdrawal stays terminal.

The runtime selects its supported slirp4netns path without changing Podman defaults. Desktop setup can inspect occupied subnets, and interrupted network creation recovers only when a bounded inspection proves the exact generated network absent. Binding renewal verifies the retained TLS inputs and returns errors for missing or changed artifacts.

Use Suite 0.10.2 to author and verify renewed service artifacts. See the installation guide and release notes. Existing Linux qualification retains its documented scope; this release does not establish additional performance or platform claims.

HyperNet 0.10.2

Linux 0.10.2

Version 0.10.2 adds optional acknowledgement of consumed fresh reads and improves
application-stream cleanup scheduling. Download the signed
Linux 0.10.2 release.
Package signatures, installed checks and native results identify exact artifacts;
earlier release evidence retains its original scope.

Changes and compatibility

• Application authority checks overlap in finite rounds of at most four queued
  and active checks in total. Read-only renewal of an established stream can
  start a round and share its four exchange slots with already-current checks.
  Completion closes admission; completed slots do not refill and the original
  round end does not extend. A later check without the existing gate or round
  headroom waits at the original FIFO head for normal preparation. The actor
  retains challenge preparation, current
  authority verification and durable publication. Expiry, cancellation, current
  floors and original caller deadlines remain enforced. Unestablished streams,
  endpoint renewal and authority-changing cleanup retain exclusive turns.

• A fresh successful stream permit can renew the same still-current stream gate
  from its exact certified result. The action receipt keeps its original deadline
  and old-gate clipping. The same certified result may renew the exact registered
  receiving-endpoint gate atomically with the stream gate; the fixed forwarding
  lifetime does not extend. An expired open cached stream gate may use bounded
  readiness renewal before a separate fresh check. Closed or ended streams cannot revive.
  Bounded inactive-stream diagnostics distinguish these lifecycle states.

• Private authority readiness preserves typed peer closure and socket reset.
  Fresh-authority recovery can suspend and reopen the endpoint after these
  transport failures. Buffered replies are drained before closure. Timeout,
  invalid descriptors and invalid signed replies remain distinct failures;
  recovery does not extend deadlines or preserve old admissions.

• A signed acknowledgement releases only the exact completed read after its
  authorised recipient consumes the verified result. It binds the original scope,
  read, statement, result and deadline. Pending reads and lost responses retain
  their original expiry and recovery. The 32-read and 768 KiB limits remain.

• A private same-inode socket alias and optional final-service TLS negotiation
  identify cleanup support. Legacy peers retain their existing read/poll behavior;
  missing support skips cleanup without opening a replacement session. Cleanup
  cannot grant authority, renew a deadline or change a consumed result.

• Application endpoints renew their own and live-stream permission before closing
  completed streams when measured headroom is insufficient. Local close still
  invalidates the stream immediately. One held completion remains within the
  existing capacity accounting; unknown authoritative Close outcomes retain exact
  requester recovery.

• Ready application work classes take finite turns, and due streams renew in
  service order. Maintenance cannot indefinitely overtake a queued check or
  completed handshake. These dispatch bounds do not promise a wall-clock latency.

• Endpoint retirement survives a competing caller Close. An endpoint-only
  StreamRetirementContext read obtains the current session, service and route
  records without granting forwarding permission. Retirement matches the original
  proof generation and signed-proof digest; a reused slot is left unchanged.
  The one held cleanup preserves its original deadline and uses bounded backoff.
  Any unknown signed Close outcome must resolve before another is prepared.
  A check blocked by that pending ordinary Close keeps its place at the queue
  head within its original deadline; later checks cannot overtake it. Recovery
  retains both ordinary-operation and retirement-fence exclusion.

• Bounded capacity diagnostics report retained count and bytes, incoming charge,
  earliest expiry and fixed ceilings without payloads or requester identities.

Use Core 0.10.2 and Suite 0.10.1 for cleanup across Core and native Suite read
consumers. Earlier payload and authority-check peers remain compatible, with
completed reads retained until expiry when optional cleanup is unavailable.
No grant, state-contract or one-use authority migration is introduced.
The additive retirement-context query requires supporting authority replicas.
Upgrade the committee before relying on this recovery; an older committee refuses
the query without an ordered-mutation fallback or an extended cleanup deadline.

Upgrade and qualification scope

The target remains native Ubuntu 24.04 x86_64 with GNU libc 2.39. Source-bound
component checks cover actual quorum collection removal after Suite consumption
over admitted TLS, legacy session reuse, original deadlines and renewal/close
scheduling. They do not establish application throughput, concurrent-user capacity
or a new platform. Earlier native results retain their original source and binary
identities; a version change does not relabel earlier executable evidence.

Follow stopped service replacement and renew local artifact consent before
activation. Preserve complete authority state, requester journals, identities,
package trust and retained floors. The package contract remains
HyperNet080Authority2. Use a separately authenticated, signed target for the
exact package; do not reset existing trust or assume a target sequence
from the version number. See upgrade and recovery.

Signed package

The release contains HyperNet-0.10.2-linux-x86_64.tar, its .sig,
HyperNet-0.10.2-linux-x86_64.target.json, its .sig, Publisher.pub,
SHA256SUMS and SHA256SUMS.sig. The signed target uses root generation 1,
sequence 20 and version floor 0.10.2. Authenticate the publisher independently
and preserve retained package trust; never lower its sequence or version floor.
The unchanged corresponding-source archive is HyperNet-0.10.1-system-sources.tar.xz;
its older filename identifies the retained dependency inputs, not the runtime version.

Installed qualification covers the final executable on Ubuntu 24.04 x86_64 with
GNU libc 2.39. The same runtime bytes also participated in an admitted application
pilot on Ubuntu 26.04 amd64 with GNU libc 2.43: eight interactive clients and four
support endpoints used twelve receiving streams and two admitted applications.
The deployment allowed sixteen relay and application connections, eight authority
endpoint connections and two native connector sessions. This is a bounded topology,
not qualification of every configured slot, independent host failure domains or
arbitrary application load. Application-specific throughput and latency results
belong to that application's qualification report. Earlier GUI and platform
results retain their original artifact scope; no independent security audit is claimed.

HyperNet 0.10.1

Core 0.10.1 fixes application authority readiness near permission renewal. Endpoint and selected-stream preparation retain the original signed challenge ceiling without extending caller waits, route lifetime, consent or permission expiry.

Compatible with HyperNetSuite 0.10.0. No wire or retained-state migration is required for this patch. Stop affected services before replacement and renew local artifact consent. Preserve authority state, journals, identities and package trust.

Qualified on native Ubuntu 24.04 x86_64 (GNU libc 2.39). Maintained Rust/package checks, native application renewal/reconnect/revocation, signed package installation, trust-floor advancement and installed-image confinement pass. This does not establish application throughput or another supported platform.

Authenticate the publisher and use the signed target policy (sequence 7, version floor 0.10.1). Retain existing trust. See release notes and verification instructions, installation, and upgrade and recovery.

HyperNet 0.10.0

HyperNet Core 0.10.0 adds optional local application authority checks and typed transport context while preserving version-1 payload companions and protocol-7 transport. The checks bind the exact live incoming session, proposed action, signed endpoint identity and original deadline. Certified denial is distinct from unavailable authority; a receipt does not grant application-level permission.

The paired Core/Suite release includes directional privacy evidence, bounded cancellation and a receiving-service Python example. Read the interface guide and installation and upgrade notes.

Qualification covers native Ubuntu 24.04 x86_64. Other platforms and sustained adversarial-load capacity remain unqualified. The existing 0.9.1 permission migration still applies when upgrading from 0.9.0. Install the coordinated Core/Suite versions before enabling version-2 checks.

Authenticate the publisher independently and use the trusted package tools from tag v0.10.0. The signed target advances to sequence 6 and version floor 0.10.0. Preserve the existing product trust directory and rollback floor. The release includes the signed binary package, target policy, corresponding dependency sources, publisher key and signed checksums.

HyperNet 0.9.1

HyperNet Core 0.9.1 restricts shared action codes 29 and 30 to the intended resource purpose throughout every non-root grant. Application streams require Service scopes; sealed publication requires Object/Namespace scopes. Network-wide and mixed-purpose grants cannot execute either family, including through a narrower delegated child. Review displays show the scope-dependent meaning.

Read the permission scope and migration guide before upgrading. Signed history remains unchanged. Broad application, service and sealed-review bindings need the explicit replacement workflow described there. Upgrade the authority committee, Core endpoints and Suite clients together. Before replacement, all voters must finish applying the same old-version committed boundary; follow the certified inspection and stopped-journal checks in the migration guide.

Native Ubuntu 24.04 x86_64 remains the qualified platform. The release includes signed binaries, the signed target policy (sequence 5, version floor 0.9.1), corresponding sources and signed checksums. Authenticate the publisher independently and preserve existing package trust. See installation and verification.

HyperNet 0.9.0

HyperNet 0.9.0 adds reusable, consented application streams for private services across HyperNet relays. Application identities, exact service bindings and scoped permissions remain separate from user keys. Explicit renewal and current authenticated proofs preserve retained security floors during recovery.

Core includes the authority and confined rootless hosting runtime, protocol 7 application transport and segmented committed history.

Native Ubuntu 24.04 x86_64 is qualified within the documented platform and upgrade limits. Core hosting needs rootless Podman, delegated cgroup v2, seccomp and Landlock ABI 6 or newer. Native ARM, Windows, macOS and SELinux-enabled operation remain unqualified. No independent security certification or long-running throughput guarantee is claimed.

Protocol 7 needs matching Core and Suite. Preserve stopped backups, private profiles, journals and package trust before switching versions; 0.8 cannot read new 0.9 state. The generation-1 publisher is unchanged; this release uses signed target sequence 3 and version floor 0.9.0. Follow the signed installation procedure, using independently accepted publisher trust.

Download the package, detached signature, signed target and public key together. Signed SHA256SUMS also covers the corresponding third-party source archive. The source tag identifies the exact release source. Production builds remove local build paths; the completed source-bound integration evidence includes a verified 4,079,434,577-byte model transfer, pause/resume, actual remote inference, cancellation and live grant revocation. New production bytes receive signed installation and native package checks.

HyperNet 0.8.0 for Linux

HyperNet 0.8.0 is available for native Linux x86_64.

Permissioned Byzantine authority, consented rootless hosting, relay-only reader routes, durable content recovery and replicated administration.

Download the signed binary archive, its signature, the signed target policy and
Publisher.pub. The matching source accompaniment, SHA256SUMS and its signature
are included. Follow the release and installation guide
for prerequisites, independent publisher authentication and the complete commands.

The packaged profile is qualified on Ubuntu 24.04 x86_64 with GLIBC 2.39 or newer.
Other distributions require the recorded ABI and runtime controls. ARM, macOS,
Windows and SELinux-enabled hosting remain unqualified. Core hosting needs
rootless Podman, delegated cgroup v2, seccomp and Landlock ABI 6 or newer.

Known limits include slow larger transfers, CLI mail enrolment and administration,
and no saturation, long-soak, full screen-reader or independent security assessment.
Earlier network and recovery evidence retains its original executable identities.
This release does not establish independent operator or failure-domain separation.

Publisher root generation: 1.
Package-tool root pin:
6529f9e574e73409ec578c9e9a66e683fef6ae885704d22d75538781b4b43b1e.
Authenticate that identity independently before initialising package trust.