Bedrock Edition in mineflayer: an edition adapter, shipped in slices

Bedrock Edition in mineflayer: an edition adapter, shipped in slices

Bedrock support has been tracked since #842 and designed in PrismarineJS/bedrock-protocol#116; the libraries it needs have been built up over the years (prismarine-registry palettes, prismarine-item, prismarine-chunk from bedrock-provider). What is missing is the mineflayer side. This proposes the shape rom1504 preferred in PrismarineJS/bedrock-protocol#116, sized to the incremental, working-slice approach asked for there, and kept inside the package boundaries #4135 sets.

I have a working proof of concept to ground the discussion (link at the bottom): the whole interaction surface running live against an official Bedrock Dedicated Server. It is offered as a reference to review the direction, not as a PR to merge — the intent is to land it as small slices once the architecture here is agreed.

Ownership (following #4135 and PrismarineJS/prismarine-contribute#15)

• bedrock-protocol owns transport, packets, login and encryption. Nothing bot-facing goes there (rom1504 in PrismarineJS/bedrock-protocol#34; extremeheat in PrismarineJS/bedrock-protocol#377 and PrismarineJS/bedrock-protocol#643).
• minecraft-data owns versioned facts and feature flags; prismarine-registry combines them with the server's runtime palettes, one registry per bot.
• prismarine-world / chunk / block / item / entity / physics own their domains, edition-aware through the registry.
• mineflayer owns the translation from packets to bot state and events, and action scheduling.

The adapter

createBot({ edition: 'bedrock', version: 'bedrock_1.26.x' }) (or a bedrock_-prefixed version) creates a bedrock-protocol client through lib/client/bedrock.js; lib/client/java.js keeps the node-minecraft-protocol path. The adapter runs the join sequence a real client performs, captured from an official 1.26.51 client against an official dedicated server: after the resource-pack phase it ends the loading screen, clears the aim-assist preset, sends set_local_player_as_initialized, then a per-tick player_auth_input heartbeat that Bedrock servers require to keep the session alive. The rest of mineflayer then sees the usual connect, login, spawn, end events.

Edition-specific packet handling lives in lib/bedrock_plugins/*, one plugin per concept, each translating into the same bot state and events the Java plugins produce. Shared, protocol-independent helpers (the chat pattern matcher and awaitMessage) move to lib/chat_patterns.js so both editions use them with no change to Java behaviour.

Version and feature gating

Versions carry the bedrock_ prefix into minecraft-data and the bare version into bedrock-protocol (extremeheat, #3539). Behaviour differences are gated with bot.supportFeature(...) the way the Java plugins already do, not with edition or version branches in library core (the same feature-flag direction PrismarineJS/bedrock-protocol#504 took for tick sync). New bot-relevant flags proposed for minecraft-data's bedrock features.json: chunksNeedSubchunkRequests, itemStackRequests, serverAuthoritativeMovement, loadingScreenPackets, tickSyncKeepAlive, resourcePackStackStep.

First slice (the opening PR)

Connection lifecycle, game state, health and food, time, spawn point, settings and chat. No world, entities, inventory or physics yet; those properties and methods are simply absent on a Bedrock bot, which is the "some basic stuff working and go from there" starting point. About 1000 lines, Java behaviour unchanged, lint clean. Deliberately small so it can be reviewed on its architecture, not its size.

Landing order after the first slice

World (subchunk requests, prismarine-chunk hashed ids) → entities (with effect/attribute name normalisation in minecraft-data first) → inventory as the transaction API in prismarine-windows (the batched ItemStackRequest model from PrismarineJS/bedrock-protocol#116) → physics and pathfinder through the shared world API and a client-tick coordinator, aligning with #4135's tick extraction.

Checks

• A test/bedrock/ suite boots a real offline Bedrock Dedicated Server (via minecraft-bedrock-server, the way bedrock-protocol's test/vanilla.js does) and asserts login, spawn, game state and a chat round-trip, skipping when a server binary cannot be fetched.
• Verified live against an official BDS 1.26.45 (login, spawn, game, chat, no packet violations) and against PowerNukkitX 3.0.1 and PocketMine-MP 5.44.3 at 1.26.30 (join, chat, death/respawn, session ticking).
• CI policy, following PrismarineJS/bedrock-protocol#11: the official dedicated server is the reference; PocketMine and PowerNukkitX run in a PR-time matrix.

Prerequisites

• PrismarineJS/minecraft-data#1321 adds Bedrock 1.26.51 (the current release; RakNet is gone from 1.26.5x servers).
• PrismarineJS/prismarine-chunk#337 fixes a hashed-runtime-id crash on any single-block update — an independent bug, but the adapter's world decode needs it.
• NetherNet reach for current servers is being handled upstream by extremeheat (PrismarineJS/bedrock-protocol#809 and PrismarineJS/bedrock-protocol#810 merged; PrismarineJS/bedrock-protocol#774 open). The adapter is independent of that work — RakNet servers up to 1.26.45 work with published bedrock-protocol today, which is what everything below is verified against.

The proof of concept (reference, not for merge)

To judge the design against real behaviour rather than a promise, the same adapter is carried through the whole interaction surface, each system verified live on an official BDS 1.26.45: world/blocks, block search and ray tracing, entities, attack/use, inventory read/move and chest deposit-withdraw (ItemStackRequest), block breaking and placement (server-authoritative, over player_auth_input / item_use), containers, entity interact and open-inventory, abilities, eating/drinking, crafting (recipes, 2x2 inventory and 3x3 table), furnace smelting, and server-authoritative movement — on top of the first slice's lifecycle/chat/health/time. 25 edition plugins, 63 offline tests, lint clean, Java behaviour unchanged.

• Branch: https://github.com/Pix3lPirat3/mineflayer/tree/feat/bedrock-edition-adapter
• A per-system writeup (API, the captured packet flow, and the live verification for each) accompanies it.

Questions to settle

1. Adapter inside mineflayer now (proposed), extracted to a prismarine-client later if the events prove reusable by flying-squid (PrismarineJS/prismarine-design#1), or a shared package from the start?
2. The feature-flag names above: acceptable in minecraft-data's bedrock features.json?
3. The inventory transaction API shape from PrismarineJS/bedrock-protocol#116 before prismarine-windows work begins.
4. Confirm the CI split: dedicated server as the gate, third-party jars in PRs only.