Support for Multiple Peripherals per Extension - questions regarding implementation/pull request

Goal

Allow Scratch extensions to discover, connect, and manage multiple peripherals simultaneously instead of limiting connections to a single device.

Motivation

I have multiple Lego WeDo 2.0 hubs (each providing 2 sensor/motor ports). While the official LEGO app allows connecting multiple hubs to one project, Scratch currently limits the extension to a single hub.

Proposed GUI changes

• Device Connection Modal:
  • While the connection modal is open, Scratch continues discovering devices while displaying currently connected hubs.
  • Users can toggle connection states for individual hubs with a single click.
• Dynamic Block Menus:
  • Once one or more hubs are connected and the modal is closed, the block dropdown menus dynamically update to display all available motors/sensors across all connected hubs (Plug & Play).

---

Proof of Concept

I have built a working prototype running on Linux. During development, several architectural questions arose. I would love to get feedback from the Scratch maintainers and community to align my implementation with Scratch's architectural goals for a future Pull Request.

Note on dynamic dropdowns: Scratch already supports dynamic block dropdown menus via callbacks, which works exceptionally well for runtime Plug & Play sensors/motors across hubs.

---

Technical Bottlenecks & Proposed Solutions

1. Session-Based Communication in ble.js / bt.js & Scratch Link

Currently:

1. A single BLE/BT JSON-RPC session handles both discovery and connection for a single peripheral.
2. Scratch Link constraint: WebSocket sessions handling discovery only allow connecting to devices discovered within that same session.

Proposed Solution:
Allow Scratch Link to connect to devices without requiring prior discovery in the exact same WebSocket session (connecting can fail gracefully regardless of this change).

• Workflow: The client handles discovery in one WebSocket session, then opens separate sessions to manage connections to individual devices.
• I verified this approach using an open-source Linux implementation of Scratch Link. Adapting Windows/macOS implementations should be doable.
• bt.js / ble.js clients in scratch-vm would be updated to decouple discovery from connection management and handle multi-device sessions.

2. Extension Definition Flags

Extensions should be able to declare support for multiple devices:

• Introduce an optional flag (e.g., allowMultiplePeripherals: true) in the peripheral extension configuration.

3. State Tracking in VM / Runtime

The runtime and peripheral management layer need a gateway to track active connections:

• Proposed API methods: getConnectedPeripherals(extensionId) and setConnectedPeripherals(extensionId, deviceIds).

4. Device Connection Modal Updates

Because auto-connect (existing extension flag) is not suitable for multi-device workflows, we should build on top of the standard connection chooser dialog:

• Option A: Extend the standard "scanning-step" view to support multi-selection and active connection toggling.
• Option B: Introduce a dedicated scanning step component (e.g., scanning-step-multi).

What do you think of this?

Note: The initial prototype was developed with the assistance of an AI agent, and I have acquired a solid understanding of the relevant parts of scratch-vm, scratch-gui, and Scratch Link. Also this text was marked-up with help of AI :-) *

Start by reviewing the mentioned scratch-vm ble.js and bt.js clients, the scratch-gui scanning-step view, and the Scratch Link session constraint. Before implementation, get maintainer agreement on the connection model, extension flag, runtime API, and modal approach; done would be an approved, scoped design for multi-peripheral support.