Nethernet support for joining worlds

[LucienHH]

Majority work for Nethernet support. Supports listening and joining over LAN, signalling via the franchise WebSocket and creating/joining an Xbox session.

To do

• LAN discovery
• Xbox session lookup/creation
• Signalling channel for remote connections
• Move Nethernet protocol to it's own repo?
• Move Session handling to pauth or another repo?
• Merge Add methods for fetching PlayFab and Minecraft Service tokens  prismarine-auth#107
• Handle CONNECTERROR messages received from signalling channel
• Updating docs and index.d.ts
• Tests

Closes #473

[extremeheat]

Thanks for working on this, please advise when it's ready for review

[LucienHH]

Most the work is done apart from some bits but would probably be good to start moving parts of this out of here into other areas. Mainly moving the contents of ./nethernet, I'd think it'd make sense to have this in a prismarine-nethernet repo maybe?

Same with the Xbox Session API, I think we could get away with putting this in pauth unless you think we should separate an Xbox API to another repo?

[extremeheat]

How do we know what version to connect as here if the user does not specify/can't get via ping?

[LucienHH]

If the user doesn't specify it defaults to the current version and the version isn't included in the Nethernet ping response

[extremeheat]

OK, what is advertisement.version then? We may have to figure out the version after connecting to the server then like nmp can do. It should be sent in login/network_settings packet otherwise. The current code should also be matching version by protocol version num over strings but that should be fixed outside this PR

[LucienHH]

Not entirely sure but I assume it's the version of NetherNet protocol being used as it's just a uint8. From my testing it's always been set to 3 over multiple version updates.

[extremeheat]

node-fetch can be removed in favor of native fetch now that it's also removed from prismarine-auth

[socket-security]

Review the following changes in direct dependencies. Learn more about Socket for GitHub.

Diff	Package	Supply Chain Security	Vulnerability	Quality	Maintenance	License
	xbox-rta@​2.1.0
	json-bigint@​1.0.0
	ws@​8.20.0

View full report

[yntha]

Hi, great work so far on this PR. I've developed a similar nethernet implementation that is fully working as of the latest update to minecraft. The new bedrock signalling servers use the JSON-RPC format, not the old Type/From/Message format.

On Realm connections (and some newer Xbox session flows), the signalling websocket sends messages in this format:

{
  "jsonrpc": "2.0",
  "method": "NetherNetMessage",
  "params": {
    "fromNetherNetId": "12312312312312312",
    "innerMessage": "<SignalStructure b64 payload>"
  }
}

And expects signals from the client in this format:

{
  "jsonrpc": "2.0",
  "method": "NetherNetMessage",
  "params": {
    "netherNetId": "12312312312312312",
    "message": "<SignalStructure b64 payload>"
  }
}

I've patched src/websocket/signal.js with the following, that adds legacy protocol support and jsonrpc support. Callers can switch to the new protocol via signallingProtocol: 'jsonrpc' when calling createClient:

const client = bedrock.createClient({
  transport: 'nethernet',
  useSignalling: true,
  signallingProtocol: 'jsonrpc',
  //...
})

Internal patch (to src/websocket/signal.js):

// new parameter 'options'
constructor(networkId, authflow, version, options = {}) {
  //...
  this.protocol = options.protocol || 'legacy'
}

// send new or legacy format
write(signal) {
  const message = this.protocol === 'jsonrpc'
    ? stringify({
        jsonrpc: '2.0',
        method: 'NetherNetMessage',
        params: {
          netherNetId: String(signal.networkId),
          message: signal.toString()
        }
      })
    : stringify({ Type: MessageType.Signal, To: signal.networkId, Message: signal.toString() })
  this.ws.send(message)
}

onJsonRpcMessage(message) {
  const signal = parseJsonRpcSignal(message)
  if (!signal) return debug('Unhandled jsonrpc message', message)
  this.emit('signal', signal)
}

I also modified the onMessage function to catch inbound jsonrpc messages by default when all other cases fail:

default: {
  if (message.jsonrpc) this.onJsonRpcMessage(message)
}

Helpers:

function parseSignalMessage(message) {
  if (typeof message !== 'string') return null
  try {
    const parsed = JSON.parse(message)
    const signal = parseJsonRpcSignal(parsed)
    if (signal) return signal
  } catch {}
  return SignalStructure.fromString(message)
}

function parseJsonRpcSignal(message) {
  const params = message?.params || message?.Params || message?.result || message?.Result
  if (!params || typeof params !== 'object') return null
  const signalText = params.message || params.Message || params.innerMessage || params.InnerMessage
  if (!signalText) return null
  const signal = SignalStructure.fromString(signalText)
  const networkId = params.netherNetId || params.NetherNetId || params.fromNetherNetId || params.FromNetherNetId || params.fromPlayerId || params.FromPlayerId
  if (networkId) signal.networkId = String(networkId)
  return signal
}

And in src/client.js, pass the protocol through:

this.nethernet.signalling = new NethernetSignal(
  this.connection.nethernet.networkId,
  this.options.authflow,
  this.options.version,
  { protocol: this.options.signallingProtocol }
)

The parseSignalMessage replacement for SignalStructure.fromString on inbound signals can handle both protocols, so the same code path works regardless of what the server sends.

I'd be happy to open a follow up pr against this branch if that'd be easier. Let me know! 🙂

[LucienHH]

Hi @yntha, appreciate the write up! Yeah please do that'd be very helpful as I haven't had time recently to work on this.

[yntha]

#735

[extremeheat]

Ready for merge into a dev branch?

[extremeheat]

Looks like CI failing is that related to PR?