I miss the days when most people had a vanilla looking computer. You wouldn't have felt out of place at the LAN party lugging in your dad's old Packard Bell tower that you used for your gaming rig.
We still appreciated visually stunning PCs. Not just for the works of art that they were, but also for the DIY skill and ethic you were actually required to demonstrate to build and mod them.
Nowadays, it's all just "RGB by default". By my angry old man standards, it looks gauche. Then again, I suppose it's the new vanilla?
It's disappointing to see. It doesn't take much work to configure a MQTT server to require client certificates for all connections. It does require an extra step in provisioning to give each device a client certificate. But for a commercial product, it's inexcusably negligent.
Then there's hardening your peripheral and central device/app against the kinds of spoofing attacks that are described in this blog post.
If your peripheral and central device can securely [0] store key material, then (in addition to the standard security features that come with the Bluetooth protocol) one may implement mutual authentication between the central and peripheral devices and, optionally, encryption of the data that is transmitted across that connection.
Then, as long as your peripheral and central devices are programmed to only ever respond when presented with signatures that can be verified by a trusted public key, the spoofing and probing demonstrated here simply won't work (unless somebody reverse engineers the app running on the central device to change its behaviour after the signature verification has been performed).
To protect against that, you'd have to introduce server-mediated authorisation. On Android, that would require things like the Play Integrity API and app signatures. Then, if the server verifies that the instance of the app running on the central device is unmodified, it can issue a token that the central device can send to the peripheral for verification in addition to the signatures from the previous step.
Alternatively, you could also have the server generate the actual command frames that the central device sends to the peripheral. The server would provide the raw command frame and the command frame signed with its own key, which can be verified by the peripheral.
I guess I got a bit carried away here. Certainly, not every peripheral needs that level of security. But, into which category this device falls, I'm not sure. On the one hand, it's not a security device, like an electronic door lock. And on the other hand, it's a very personal peripheral with some unusual capabilities like the electrical muscle stimulation gizmo and the room occupancy sensor.
[0]: Like with the Android KeyStore and whichever HSMs are used in microcontrollers, so that keys can't be extracted by just dumping strings from a binary.
A lot of BLE peripherals are very easy to probe. And there are libraries available for most popular languages that allow you to connect to a peripheral and poke at any exposed internals with little effort.
As for the reverse engineering, the author claims that all it took was dumping the strings from the Dart binary to see what was being sent to the bluetooth device. It's plausible, and I would give them the benefit of the doubt here.
Controllers provide analogue controls (eg. thumbsticks and triggers) that most keyboards don't have.
If, as you suggest, the control schemes of video games are becoming less complex (Forward, down, forward, high punch) then surely the result would be more games that are playable with only a keyboard, not fewer?
The OP delivered a drive-by contribution and proceeded to condescend one of the maintainers. They posted the interaction to HN (for the second time) out of spite for the maintainer, labelling it an instance of gatekeeping.
Having a polite and diplomatic conversation about a non-trivial contribution idea is a common prerequisite for it to be accepted into a project, like Hapi.js.
It's no surprise that project maintainers don't wish to work with recalcitrant individuals, regardless of the merit of their contributions.
At one point in his demo, he uploads a file but terminates the upload more or less halfway. Then he begins downloading the file - which only progresses to the point it had been uploaded, and subsequently stalls indefinitely. And, finally, he finishes uploading the file (which gracefully resumes) and the file download (which is still running) seamlessly completes.
I wish Gary was one of the people that the average joe associated with "people who are known for doing computer things", instead of only people such as Bill Gates and Steve Jobs.