Skip to content

Support Nethernet HTTP discovery and signalling - #831

Open
extremeheat wants to merge 4 commits into
masterfrom
feat/nethernet-http
Open

extremeheat wants to merge 4 commits into
masterfrom
feat/nethernet-http

Conversation

@extremeheat

@extremeheat extremeheat commented Sep 22, 2026 •

Copy link
Copy Markdown
Member

Direct BDS connections currently fail when LAN discovery is unavailable, even though the server accepts Nethernet HTTP signalling. This adds that path to createClient() and ping(), and replaces the offline helper's separate HTTP implementation with the production path.

Fixes #830. Depends on PrismarineJS/node-nethernet#32.

HTTP discovery/signalling and SDP identity verification now live upstream. This PR consumes PrismarineJS/node-nethernet#feat/http-signalling; replace it with the released npm version after upstream merges/releases. Bedrock supplies player credentials, selects the transport, and maps HTTP metadata to its advertisement API and minecraft-data.

  • Prefer existing UDP discovery; fall back to HTTP when neither transport responds. Explicit RakNet/LAN/services selections and network-ID filters retain their behavior. HTTP can also be selected directly with nethernet.signalling: 'http'.
  • Select minecraft-data by advertised protocol. An empty HTTP 200 response indicates HTTP capability without inventing version metadata.
  • Delegate the complete ICE offer/answer exchange and operator identity verification to nethernet. HTTPS establishes trust through TLS; plain HTTP requires an operator-key pin or explicit application approval. A configured pin is always enforced. Closing the client cancels the exchange, and approval is bounded by the signalling deadline.
  • Exercise the public client in Nethernet vanilla integration tests with LAN visibility disabled. Preserve the existing RakNet test flow for older versions. The packet-dump helper uses the same implementation and explicitly approves local fixture keys; it no longer strips unverified identities.

Validation

  • Lint and TypeScript checks pass.
  • 55 focused Bedrock integration tests pass against the upstream implementation; upstream has 72 passing tests, including signatures, pins/approval, HTTPS trust policy, cancellation and offer completeness.
  • Latest stable Mojang Linux BDS 1.26.51.1, protocol 2193, offline loopback with enable-lan-visibility=false: automatic discovery detected HTTP with an empty metadata body; an unknown key was rejected; the public client spawned with the verified key pinned.
  • The CI arrangement of a public spawn client and packet-dump client running together against that BDS also passed. Older-version integration regressions are left to CI.

Review notes

Live online authentication and Internet/NAT connections have not been tested; authenticated offer construction is covered by focused tests. HTTP hosting is not implemented.

A separate local sequence where the CI spawn client immediately followed another completed client session on the same BDS process disconnected before spawn. The CI client passed on a fresh BDS process, including alongside the packet-dump client. The cause of that sequential-session failure is not established; it should not be treated as validated reconnect behavior.

The previous CI failure on 1.16.201 followed a public-client test refactor exposing player-list removal decoding when one of the two clients disconnected. That unrelated older-version test refactor has been reverted; new public-client coverage is limited to Nethernet.

Implementation and testing by OpenAI Astra.

@rom1504 rom1504 left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Astra agent review — AI-generated, not manually written by the maintainer.

The adapter preserves UDP-first discovery with HTTP fallback, represents optional HTTP metadata honestly, forwards server trust controls, and rejects unsupported HTTP hosting. Offline identity is prepared before transport startup. I found no additional static blocker in those paths. Landing still needs node-nethernet #32 released and the branch dependency replaced with the usable package version, followed by vanilla HTTP discovery/login validation; I did not run a fresh BDS session. Current CI alone does not remove that release prerequisite.

Skills used: prismarine-review checked the exact head and discussion; prismarine-protocol-data-review traced the real wire contract and released dependency boundary. prismarine-architecture-review checked the adapter boundary; prismarine-lifecycle-action-review traced identity initialization.

Reviewed current head d2973e71bc9c and existing discussion. This is a COMMENT review for maintainer consideration.

@Amine6411

Copy link
Copy Markdown

Could you guys support relay for world? if impossible.

@extremeheat

Copy link
Copy Markdown
Member Author

@Amine6411 Can you elaborate what you mean?

@Amine6411

Copy link
Copy Markdown

@Amine6411 Can you elaborate what you mean?

I mean, i can use relay in world.

and only available for:
createRelay.js - for server ip and port.
realmRelay.js - for realm.

missing:
worldRelay.js - for world.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Support Nethernet HTTP discovery and signalling for direct server connections

3 participants