dhttp v0.4.0

dhttp v0.4.0

This release aligns the DHTTP facade and access-control crates on the dhttp-home 0.3 line.

Published packages

• crates.io: dhttp 0.4.0
• crates.io: dhttp-access 0.3.0
• npm: @genmeta/dhttp 0.4.0
• PyPI: dhttpy 0.4.0

Changes

• Publishes dhttp-access 0.3.0 with the current home-loading API.
• Updates the DHTTP facade dependency graph to use dhttp-access 0.3.0.
• Updates native Node and Python package versions to 0.4.0.

Authentication and provenance

• Release tag: v0.4.0
• Annotated tag object: 1205b9e97cecfd01871a0a65ceeb07091f5be14f
• Target commit: 0dc0e17
• Published surfaces: crates.io dhttp 0.4.0 and dhttp-access 0.3.0; npm @genmeta/dhttp 0.4.0; PyPI dhttpy 0.4.0
• Trusted Publishing / provenance workflows: crates.io run 28222720947, npm run 28222720992, PyPI run 28222720978, all at commit 0dc0e17

dhttp v0.3.0

dhttp v0.3.0

This release moves the dhttp facade to the 0.3.0 compatibility line and updates endpoint construction for the current DHTTP/3, discovery, and scoped-home APIs.

Highlights:

• Updated the facade to consume typed local endpoint updates from the underlying DHTTP network stack.
• Switched the default STUN bootstrap path to resolver-owned DDNS bootstrap names.
• Isolated H3 DNS client endpoints so DNS-underlay construction does not inherit the final endpoint resolver cycle.
• Added scoped DHTTP home loading for user and global home contexts.
• Published dhttp-home 0.3.0 with scoped home loading as the only public loading API. Linux/macOS retain /etc/dhttp as the global default, while Windows requires explicit global-home configuration.
• Kept dhttp-access on its independent 0.2.0 release line because its public version did not change.

Compatibility notes:

• dhttp 0.3.0 depends on h3x 0.5.0 and dyns 0.5.0.
• dhttp-identity remains 0.2.0.
• dhttp-home is 0.3.0.
• dhttp-access remains 0.2.0.

Release surface:

• dhttp 0.3.0
• dhttp-home 0.3.0
• dhttp-api 0.3.0 npm/PyPI binding surface

Full changelog: v0.2.0...v0.3.0

Authentication and provenance:

• Release tag: v0.3.0
• Annotated tag object: 9fa2690f6a738c7bf787e27df4ea22b577c4cc9c
• Target commit: 64cd960
• Published surfaces: crates.io dhttp 0.3.0 and dhttp-home 0.3.0; npm @genmeta/dhttp 0.3.0; PyPI dhttpy 0.3.0
• Trusted Publishing / provenance workflows: crates.io run 28221759272, npm run 28221759247, PyPI run 28221759269, all at commit 64cd960

dhttp v0.2.0

dhttp v0.2.0

DHTTP endpoint facade release for the DHTTP 0.4.0 release wave.

Changes:

• Bump the dhttp workspace release line to 0.2.0 and align Rust, npm, and PyPI package metadata.
• Stage and consume dhttp-identity 0.2.0, including DHTTP certificate-chain key and sequence validation.
• Add public DHTTP DNS planning and construction helpers for endpoint-owned networks and QUIC endpoints.
• Wire endpoint DNS operations into Endpoint::builder() with append-only resolver/publisher configuration and default H3/mDNS/System behavior.
• Make endpoint DNS publishing listen-owned and allow named endpoints with no publishers to listen without starting a publication loop.
• Add Endpoint::from_parts(...) for adapting an existing H3 endpoint, publisher aggregate, and DHTTP network while validating identity and network invariants.
• Update endpoint DNS tests and README dependency examples for the 0.2.0 release line.
• Converge cross-repo release dependencies to published crates.io versions: h3x 0.4.0, dyns 0.4.0, and dhttp-identity 0.2.0.

Release surfaces:

• crates.io: dhttp-home 0.2.0, dhttp-access 0.2.0, dhttp 0.2.0.
• npm: @genmeta/dhttp 0.2.0.
• PyPI: dhttpy 0.2.0.

Release role:

• Follows dhttp-identity 0.2.0, h3x 0.4.0, dyns 0.4.0, and dshell 0.4.0 publication.
• Unblocks downstream gmutils and gateway release validation through the endpoint facade.

Verification:

• cargo metadata --format-version 1
• cargo fmt --all -- --check
• git diff --check -- . ':(exclude).cargo'
• TMPDIR=/target/tmp cargo test --workspace --all-features --all-targets
• cargo clippy --all-targets --all-features -- -D warnings
• cargo publish --dry-run --locked -p dhttp-home -p dhttp-access -p dhttp
• dhttp PR #3 final CI passed.

Authentication and provenance:

• GitHub release created with an authenticated gh session and gh release create v0.2.0 --verify-tag.
• Release tag: v0.2.0
• Annotated tag object: 1e9af6202d0578c6a5e4dac00ee3700bc3a6f196
• Target commit: 2e870efad4f969b9cfe696ca8e91035a02135b21
• crates.io: dhttp-home 0.2.0, dhttp-access 0.2.0, dhttp 0.2.0
• npm: @genmeta/dhttp 0.2.0
• PyPI: dhttpy 0.2.0
• Trusted Publishing / provenance workflows:
  • crates.io: Publish crates.io run 27652233802, attempt 3, SHA 2e870efad4f969b9cfe696ca8e91035a02135b21
  • npm: Publish npm run 27652233795, attempt 1, SHA 2e870efad4f969b9cfe696ca8e91035a02135b21
  • PyPI: Publish PyPI run 27652233798, attempt 1, SHA 2e870efad4f969b9cfe696ca8e91035a02135b21

v0.1.0-dhttp-identity

dhttp v0.1.0-dhttp-identity

This tag is the formal git anchor for the dhttp-identity 0.1.0 line in the staged initial DHTTP release sequence.

Included changes

• prepare the initial 0.1.0 workspace release across dhttp, dhttp-identity, dhttp-home, dhttp-access, and dhttp-api
• re-export the dhttp-access facade from the top-level dhttp crate
• alias the published dyns package as the workspace ddns dependency surface
• publish workspace crates sequentially in release automation
• gate crates.io, npm, and PyPI publication by registry state so uninitialized packages are skipped instead of being bootstrapped automatically
• align the workspace with h3x 0.3.1 and unify dhttp-identity source identity to avoid mixed workspace/registry dependency graphs
• make crates.io dry-run validation follow the same registry-eligibility selection as real publish, so PR CI only dry-runs packages that are actually eligible for release

Tag behavior

For this staged identity tag, automated publish workflows are expected to remain no-op where packages are not yet initialized on their target registries:

• crates.io skips packages that are already published or not yet initialized
• npm skips @genmeta/dhttp because the package is not yet initialized
• PyPI skips dhttpy because the package is not yet initialized

This tag exists to provide the stable git reference for dhttp-identity in the cross-repository release wave before the final dhttp v0.1.0 release tag.

DHttp v0.1.0 — The endpoint stack for the True Internet

DHttp v0.1.0 — The endpoint stack for the True Internet

DHttp v0.1.0 is the first public release of the DHttp endpoint stack: an Apache-2.0 implementation of peer-capable HTTP APIs built on QUIC, HTTP/3, mutual TLS identity, endpoint-aware name resolution, and policy-based access control.

It keeps the Web’s request/response model, then extends it toward a network where applications, devices, services, and agents can connect directly as named, authenticated peers.

Highlights

• Endpoint equality

  • Introduces the dhttp Rust SDK for building endpoints that can both initiate requests and serve HTTP APIs.
  • Provides endpoint creation, client requests, server listening, trust defaults, DNS integration, and QUIC/H3 networking through a unified application API.

• Name as identity

  • Introduces dhttp-identity for DHttp names, identity certificates, subject-key metadata, and signing/verification helpers.
  • Establishes .dhttp.net as the canonical public DHttp identity namespace.

• Local-first identity material

  • Introduces dhttp-home for local DHttp home directories, identity profiles, settings, certificates, and private keys.
  • Supports loading named endpoints from local credential material so endpoints can come online from their own identity.

• Fine-grained access

  • Introduces dhttp-access for identity-aware access expressions, matchers, HTTP integration, optional SQLite persistence, and CLI-facing access primitives.
  • Enables authorization by verified identity and HTTP context instead of network location alone.

• Endpoint-aware reachability

  • Integrates H3 DNS, mDNS, and system DNS for endpoint discovery.
  • Allows listening endpoints to publish reachable endpoint records as part of their service lifetime.

• Native language SDKs

  • Adds Node.js support under @genmeta/dhttp.
  • Adds Python support under dhttpy.
  • Brings the same endpoint model to Rust, JavaScript, and Python with high-level request/server APIs and raw message primitives.

• Everything is a service

  • Keeps HTTP APIs first-class while adding peer identity, local-first routing, endpoint equality, and decentralized reachability.
  • Provides a foundation for agentic connectivity: agents, services, applications, and devices can have verifiable names, expose APIs, and communicate across networks.

Release targets

This release covers the first public DHttp SDK surface:

• Rust:
  • dhttp
  • dhttp-identity
  • dhttp-home
  • dhttp-access
• Node.js:
  • @genmeta/dhttp
• Python:
  • dhttpy

Rust SDK foundation

The Rust SDK line is built on the published DHttp stack versions:

• h3x = 0.3.1
• dyns = 0.3.0
• dhttp-identity = 0.1.0

This gives the release a stable registry-based foundation for Rust SDK adoption.

Why this matters

Traditional HTTP assumes servers are special. Traditional DNS mostly names locations. Traditional private networking hides endpoints behind topology.

DHttp turns the endpoint itself into the primitive:

• the endpoint can initiate and serve;
• the name authenticates the peer;
• DNS describes reachable endpoint records;
• access is granted by verified identity and HTTP context;
• local, private, proxied, and public paths can converge under one model.

This first SDK release provides the foundation for an open, local-first, decentralized, HTTP-compatible network where everything can be a service.