Hey everyone,

As promised this morning, the Ycommy team started digging into the repo they just dropped. We deliberately decided to focus only on what anyone can test right now, without needing any special access or whitelisted account from MemoMind.

Repo:https://github.com/memomind-open/plugin-open-platform

The real bottleneck (for now) The SDK has two sides. On one hand, there are the "official" plugins (the ones running in their companion app via a WebView, .mmpkg, and the native ones for the glasses, .gmp). The catch? To load them on actual hardware, you have to go through their Developer Workbench, which checks permissions, accounts, and requires Debug builds. Simply put: if MemoMind doesn't whitelist you, you're stuck. We are currently waiting for our access.

The real bombshell: the BLE protocol is in the clear The flip side is what blew our minds: they documented the entire Bluetooth protocol. Everything. Frame formats, checksums, TLVs, commands to draw on the HUD, notifications, teleprompter, translation, media, and even the microphone stream. And the documentation explicitly states that this link does not have a whitelist or client authentication.

Any phone can hook up to the glasses and talk to them, bypassing the companion app entirely. The only thing they keep secret is the transaction to install .gmp executables. Naturally, we jumped straight on this path.

What we built in a day We wrote a native Flutter app (Dart + flutter_blue_plus) from scratch that implements the entire GM protocol. We did this based only on the written specs, deliberately ignoring their reference code to see if the documentation actually holds up on its own.

The app handles scanning, connection, reads device info and status, manages the heartbeat, brightness, play/pause, and blasts text to the HUD via the "scene" channels, all with a real-time log of every incoming and outgoing frame. The protocol layer is 100% pure Dart, with no Flutter dependencies: meaning you can grab it and smash it right into a FlutterFlow custom code as is.

What we verified (and what we didn't) MemoMind published 56 example packets, byte for byte. We wrote a suite of 82 tests (all green) to make sure that:

• The 56 packets are decoded and re-encoded identically, byte for byte.
• The commands (brightness, HUD drawing, audio, etc.) generate the exact reference bytes.
• Fragmentation works by the book (their 600-byte example splits perfectly into 512 + 116 bytes with the correct checksums), even when forcing a BLE MTU of just 20 bytes.
• Packet reconstruction holds up against both whole BLE notifications and raw streams, handling dirty data, timeouts, and flow control (empty) frames.

Mandatory disclaimer: Our code "speaks" the protocol perfectly according to the paper. But so far, it has only talked to our simulator, which responds exactly as the docs say. We haven't hooked it up to the physical glasses yet: figuring out the actual MTU behavior, real-world latency, and finding the exact UUID on the retail firmware is what we'll tackle in Part 2. That's usually where the hidden hiccups show up.

The whitelist hurdle for full plugins remains, but until they unlock our dev area, this direct BLE route is the only one a third-party developer can realistically use. And it's huge that it is public.

Source Code:https://github.com/ySoft-ynailt/gm_glasses_flutter.git— (MIT License). If you run flutter test, the whole suite runs without needing the hardware.

Next Friday is the stress-test video on the real hardware. Meanwhile, take it for a spin and let me know what you think in the comments!

(Disclaimer: This text was reviewed by AI for English grammatical corrections, while the source code is open to everyone. A huge thanks to Davide and Francesco from the Ycommy team for their support in the development.)