What is being worked on, what is next, and what is only being thought about. Nothing here carries a date — an item moves when it is done, not when a calendar says it should be.
Decided on, and not started.
The site half is built: the app posts a report to POST /api/bugs with a token, optionally attaching a screenshot, and it lands unlisted in a queue rather than on the page. Nothing identifying is stored — no address, no device id.
What is left is the client half: a form in each app that shows exactly what will be sent and lets you take any of it back out before it goes.
No commitment, and no date.
The client is Python and Qt, and both already run on Windows — as do pyserial, esptool and SQLite, which is everything the app is actually built out of.
What is Linux-specific is the plumbing around them, and each piece needs a Windows equivalent written rather than ported: pairing is an org.bluez.Agent1 agent on D-Bus, privileged actions go through pkexec, serial-port access is a udev rule and the dialout group, and an update installs itself with apt. On Windows the operating system does its own Bluetooth pairing and there is no serial permission to ask for, so two of those become smaller, not larger.
Nobody has started it.
The same story as Windows, and one thing on top of it: Apple will not let an unsigned build run without the user going out of their way, so a macOS release means a developer account, signing and notarisation. That is a process and a yearly fee rather than a piece of code, which is why it is listed separately from the port itself.
Nobody has started it.
Something you want that is not here? The known bugs are listed separately, and the feature matrix says what each client can do today.
MeshCore