Is integration with real-world hardware (via external servers) within the intended scope of TurboWarp extensions?

[jobluetooth]

Hi!

I’m interested in building an unsandboxed TurboWarp extension that connects projects to real-world hardware (e.g. GPIO on a Raspberry Pi).

Due to browser limitations, this would usually require an external server (for example: a small HTTP/WebSocket service running on the Raspberry Pi that the extension communicates with).

Before investing more time, I wanted to ask:

• Is this kind of real-world / hardware integration something that is considered within scope or desirable for the TurboWarp ecosystem?
• Are extensions that rely on external services (local or remote) generally acceptable, assuming they are clearly documented and optional?
• Are there any security or policy concerns I should be especially aware of for such use cases?
• Would a local-only model (e.g. http://localhost / LAN IP, no public cloud) be viewed more favorably?

My goal would be educational / maker-style projects (physical computing, robotics, experiments), not bypassing Scratch restrictions.

I’d really appreciate guidance on whether this aligns with TurboWarp’s direction, and if there are recommended patterns for this kind of extension.

Thanks!

[Brackets-Coder]

Hello there, nice question!
Depending on the board's capabilities, there are certainly a large number of ways something like this can be achieved. Any extension running a local server has as much of a security concern as the user, but any extension with access to a remote server is generally not a good idea as it's out of the user and extension's control. Because of this, a local-only model would definitely be viewed more favorably.

As far as whether it's within intended scope, I don't know. Basically every Turbowarp extension is software-only except for Augmented Reality and Gamepad, both of which use accessible web APIs anyway.
You could do it how Scratch does it and build a plugin of some sort (like Scratch Link) but we probably wouldn't like that.

The best way I would recommend doing it is build a bluetooth extension that can communicate with any bluetooth-compatible board via web APIs instead of any network at all, though you may achieve limited functionality for non-bluetooth boards or specialized boards that are beyond the generalized features of such a bluetooth extension.

If anyone has any other suggestions, please let me know!

[jobluetooth]

Thanks a lot for the detailed response, that’s very helpful.

My current architecture is a local-only model: the TurboWarp unsandboxed extension communicates with a locally running server (e.g. on a Raspberry Pi or the user’s machine) via REST for setup/capabilities and WebSockets for real-time GPIO events. The server then directly controls the GPIOs.

One important distinction from existing WebSocket/HTTP extensions is that this is not a generic networking interface. The blocks are domain-specific and hardware-oriented (e.g. “set GPIO 17 HIGH / LOW”), and the user never deals with URLs, ports, payloads, or response handling. The local server is an implementation detail, not part of the programming model.

Given that such a local server would be required, I wanted to ask for guidance on the user-facing distribution model:

What would be considered an acceptable way to make a required local server accessible to users?

A small self-hosted service they explicitly install and run?

A prebuilt binary or script for platforms like Raspberry Pi?

Clear documentation + manual startup only?

I want to make sure this aligns with TurboWarp’s expectations around security, transparency, and user control, and avoid anything that feels similar to a background helper or plugin like Scratch Link.

Any recommendations or examples of preferred patterns would be greatly appreciated. Thanks again!

[Brackets-Coder]

I'm unfamiliar with your implementation, but I'm inferring from your comment that some kind of layer must also be installed on the compatible hardware.
From my limited research, it seems like WebRTC can communicate with physical boards provided that they can receive information from that API.
Without a background plugin, I know for certain it will be very difficult. Thinking through it right now, a practical way might be to have a block or pop-up requesting connection to a physical board, and if necessary flashing the necessary firmware or something to the board by downloading a ZIP I guess.

You also have to consider the fact that not only project creators will be using this extension, but anyone using the project. What does the implementation look like? How do the project creators provide services for their users? What kinds of services? Will a project, for example, receive information from a moisture sensor attached to an Arduino, and then use other extensions to send a notification to your phone saying your plant needs water? There's all kinds of ways this can go, and in my very limited experience with physical boards (Micro:Bit, RaspberryPi, Arduino) I don't think I can help you very much with the practical side of implementation, but I'd be happy to help you with the conceptual side where I can!