Moddable SDK 10.1.0

Moddable SDK 10.1 contains improvements made between October 17, 2026, and November 4, 2026.

This is another big month for the Embedded JavaScript universe. Thank you to everyone who contributed.

A special thank you to @robertmorelli for reporting ten Regular Expression conformance issues in a single month. He created a new test tool irx, an inverted-pair regex fuzzer. The results are invaluable. We resolved all the issues, which, as an added bonus, fixed a long-standing test262 RegExp failure.

Much More ECMA-419 Cryptography

This release includes implementations of the latest draft ECMA-419 Cryptography APIs. These APIs are being actively worked on for the ECMA-419 5th Edition and consequently may still change. The new modules include:

• Random Number Generation
• Cipher (Encryption and Decryption)
• Cryptographic Key
• Signature
• Message Authentication Code
• Key Agreement
• Key Derivation
• Cryptographic Digest (first introduced earlier this year)

To validate the feasibility of implementing the ECMA-419 Cryptography APIs across a variety of devices, we've created three different backend implementations:

1. KCL. A pure software implementation using the cryptographic primitives built into the Moddable SDK from the start.
2. PSA. PSA is Arm's cryptography API for embedded devices, adopted by Espressif's ESP-IDF and the Zephyr RTOS. Our PSA backend works with both. On ESP-IDF targets, PSA benefits from hardware-accelerated operations.
3. macOS. Using Apple's CryptoKit (and some older APIs where CryptoKit doesn't provide needed functionality). This backend has the most limitations, though it is still very usable for most purposes.

Check out the working committee draft for API details. The TC53 committee is actively seeking feedback from individuals with experience and expertise in cryptographic APIs to help refine and improve these APIs so they can provide a secure, stable, efficient foundation moving forward.

TLS Improvements and Experimental TLS 1.3

TLS is the protocol used to secure nearly all network communication. We've migrated our TLS implementation to use the new ECMA-419 Cryptography APIs. This allows TLS to benefit from the performance optimizations and hardware security of some backends (e.g., PSA and CryptoKit). It also provides an essential validation of the new APIs. Along the way, we removed all support for versions of TLS before 1.2 and fixed a number of bugs that came up during testing.

In addition, we've created an experimental implementation of TLS 1.3. You can try this out for yourself by making one change: in $MODDABLE/modules/embedded/io/socket/tcp/tls/manifest.json change $(MODDABLE)/modules/crypt/tls_419.json to $(MODDABLE)/modules/crypt/tls. Early testing has shown excellent results, but more testing is needed. Please let us know what you find.

The TLS implementations make use of the supports feature of ECMA-419 Cryptography to determine which features are available from the runtime's backend. They use that information to filter the list of cipher suites reported to the server. That means that builds of the same project running on different devices may select different cipher suites. If that is important to you, check the cryptography backend configurations.

Important – TLS Vulnerability

We would like to thank the Pazo team for reporting a security vulnerability in the TLS 1.2 implementation. The vulnerability made it possible for a server to bypass certain security checks, causing a client to believe they had a secure connection to a server when they didn't. This isn't trivial to exploit; we don't know of any attacks. That said, update your software! Moddable SDK 10.1 addresses this issue. If you need help migrating your project, please let us know. You can reach out to us at the coordinates at the end of the release notes.

Pazo reported the issue following our vulnerability disclosure guidelines. If you discover a vulnerability, we encourage you to do the same.

Web Cryptography

Web Cryptography is the standard Web Platform API to perform common cryptographic operations. It is supported in web browsers and is part of ECMA-429, the Minimum Common Web API. We've created an implementation of Web Cryptography built on top of the new ECMA-419 Cryptography APIs. We've tested it against the same Web Platform tests used to validate implementations in web browsers.

Web Cryptography is a high-level API, less flexible than ECMA-419 Cryptography but easier to use. There are some operations, notably streaming encrypt/decrypt and streaming digest, that are impossible with the Web Cryptography design. The overhead of Web Cryptography is reasonably light, so if the convenience and web compatibility benefit your project, don't hesitate to use it.

Our implementation supports commonly used algorithms:

• SHA digests
• AES encryption (CBC, CTR, and GCM) and key wrapping
• HMAC
• PBKDF2 and HKDF key derivation
• RSA signatures and encryption
• ECDSA signatures
• ECDH and X25519 key agreement

RSA key generation and EdDSA are not yet available. An algorithm the ECMA-419 Cryptography backend doesn't provide is rejected with a NotSupportedError, the same as an unknown algorithm in a web browser (and web browsers don't support all Web Cryptography features!).

Repository Reorganization Continues

As the migration to standard ECMA-419 APIs settles in, we're reorganizing the repository a bit so it makes more sense. First, we've moved most of our Web Platform modules to $MODDABLE/modules/web. Next, we created $MODDABLE/modules/embedded and moved most of the ECMA-419 module implementations there. This simplifies finding implementations. For example, the ECMA-419 module specifier for I2C is embedded:io/i2c and its path in the SDK is $MODDABLE/modules/embedded/io/i2c. We've updated all manifests, examples, and guides to use the new paths. We have not yet updated $MODDABLE/examples and $MODDABLE/tests to move their directories from io to embedded, but hope to complete that for Moddable SDK 10.2.

We're doing our best to make these changes in a way that doesn't break your projects. Projects that use the old paths will see warnings during builds that display the new path. Please update your projects as soon as you see these, as we'll remove the backwards compatibility in the coming months.

ESP32-P4 Silicon Support Lands

The ESP32-P4 is a powerful new chip from Espressif that's a little bit different. It is a dual-core RISC-V device with plenty of IO but no built-in radio. Up until now, every Espressif silicon we've supported has had a radio. Instead, a board using ESP32-P4 brings its own radio for Wi-Fi and/or Bluetooth. Unsurprisingly, this is often provided by a low-cost Espressif chip too. This mix-and-match approach allows products to pair the optimal radio with the powerful ESP32-P4 to meet their design goals.

Because this design is a bit unusual for the ESP-IDF, it has been more work to support than recent Espressif silicon. This release includes support for two ESP32-P4 devices from Waveshare: ESP32-P4-Pico and the ESP32-P4-WIFI6-Touch-LCD-3.5. These are a model for other ESP32-P4 development board integrations to follow. The Moddable SDK uses Espressif’s ESP-Hosted components to implement Wi-Fi and Bluetooth transparently to the developer.

The P4-Pico has built-in speaker and microphone, plenty of flash, and PSRAM. The ESP32-P4-WIFI6-Touch-LCD-3.5 is a full-featured development device with a 3.5” touch-screen, camera, speaker, microphone, SD card, and lots of flash and PSRAM. An ESP32-C6 is included onboard for Wi-Fi and Bluetooth.

Zephyr – Cryptography, Better Networking, and Zephyr v4.5

The Zephyr project recently released Zephyr RTOS v4.5 and we've moved the Moddable SDK to that. There are a few changes that are not backwards compatible, so be sure to update.

As noted above, we've brought ECMA-419 Cryptography to Zephyr using PSA, the cryptography API on Zephyr. Whether PSA uses a software or hardware-accelerated backend depends on the Zephyr port.

Testing our TLS 1.3 implementation on Zephyr uncovered bugs in our TCP and Listener socket implementations. Those have been fixed, providing greater reliability and improved transfer speeds.

We also improved our recommended patch to Zephyr to suppress needless logs on ESP32 targets as they significantly reduce performance. See the Zephyr docs for details.

Guides for Sensor Developers

Sensor drivers are probably the most common integration in the Moddable SDK. Every new development board seems to bring a new sensor. We've expanded our popular Guides with a collection of practical advice for developers (and their LLMs) implementing new sensor drivers. They are a quick read and packed with useful tips, some of which might not always be obvious (even to your LLM).

Details

Items described above are not repeated below.

• Modules
  • Commodetto
    • Outline. Higher-precision math on scaling and rotation to eliminate pixel jitter
  • HTTP Server - defend against lines longer than scratch buffer
  • Piu
    • Kinetic Scroller resistance at start and end of range
  • DNS-SD - fix defense of claimed name
• Platforms
  • ESP32
    • I2S PDM sample rate validation and better default (all must be an integer multiple of 8000 Hz)
    • Board support
      • Waveshare P4 Pico – ESP32-P4 with built-in speaker and microphone.
      • ESP32-P4-WIFI6-Touch-LCD-3.5 - ESP32-P4 with hosted ESP32-C6 for BLE and Wi-Fi. 16 MB flash and 32 MB PSRAM, camera, audio, display, touch and SD support.
      • M5Stick S3 (contributed by @stc1988) #1798
  • Pebble
    • Ignore evented callbacks after machine clean-up (contributed by @jplexer) #1743
    • Count host time with the kernel uptime (contributed by @gmarull) #1799
    • Fix conformance of HTTP in host provider instance
    • Don't truncate HTTP headers that contain a colon
    • Eliminate race conditions in app-message
  • Zephyr
    • Moddable SDK now runs on main thread instead of spinning up a separate thread
    • Native stack size in manifest respected
• XS JavaScript Engine
  • Avoid unintended format string when reporting a marshall error
  • Regular Expression fixes (reported by @robertmorelli)
    • v flag rejects an empty character class #1751
    • /iv character class fails to match a case equivalent #1752
    • counted repetition misses a valid match #1753
    • counted group misses a match using a zero-width alternative #1755
    • lazy repetition of an empty group produces a false match #1756
    • hangs when repeating a group that can match empty #1757
    • counted alternative matches with too few repetitions #1758
    • loses a capture from the last successful repetition #1759
    • stops at an empty iteration instead of matching a #1760
    • d flag reports wrong indices after non-ASCII text #1761
  • Conformance fixes for double to integer rounding in case of a tie
• Tools
  • xsl (XS Linker) now outputs archive opcodes for preloaded modules, saving RAM on function closures and strings
  • xst (XS test tool) optimizations to reduce overhead on Fuzzilli testing
  • xsdb (XS debugger) gets an interrupt command to stop execution (equivalent of ^C, but easier for an LLM)
  • mcconfig resolves build variables in config strings
  • mcrun and mcconfig support localization spread across multiple files for a single language

Contact Us

If you have questions or suggestions about anything here, please reach out:

• Start a new Discussion on our GitHub repository.
• Drop by our Gitter to chat.
• Contact us on Bluesky at @moddable.bsky.social.
• Contact us on X / Twitter at @moddabletech.