![]() |
|
![]() |
| Wow, that's awesome! Super curious what project it is you run. (If you don't want to link it to your HN account, feel free to poke me directly, my contact info is in my HN account bio :) ) |
![]() |
| I have heard that your project has one of the fastest bluetooth libraries in the industry, its so good DOD devs have tried to have the namespaces renamed or something to that effect. |
![]() |
| Yeah, my iPhone 13 hasn't worked reliably with the Bluetooth in my 2009 Prius for a year or longer. The Prius software is just too old, I think, and I'm not sure there's a way to upgrade. |
![]() |
| > its so good DOD devs have tried to have the namespaces renamed or something to that effect.
Hilarious and impressive; I’d love to hear more, do you have more details, context or source? |
![]() |
| > it also really feels like you use 1000 lines of code where 10 will do.
Ok. Let's break this down. The library currently handles support for 523 different devices from at least 40-50 manufacturers. (https://iostindex.com/?filter0Availability=Available,DIY&fil...). These devices can connect over bluetooth le, usb (both raw and HID), serial, or one of several network protocols. We support windows, mac, linux, android, iOS, and WASM/web, each having their own HW APIs (or in the case of the mac/iOS crossover, specializations within the API). On several of these platforms there are also massive variations in bluetooth radios, which can cause a huge array of issues. Each device may have variable actuators, or may also have sensors to take input. They may also require their own keepalives or other specializations specific to their protocol or brand to manage connections. We then have to generalize commands to make life easier on developers. They send us those generalized commands, from whatever language they like since we abstract into an IPC system and provide a language-agnostic protocol spec, from whatever interconnect they want to use because our connector system is also violently flexible, and we have to convert them into the correct protocol and ship that over the correct bus. So, since you're curious about why your solution for one device from one brand running through a web browser differs from my library, there you go. It's just a matter of different goals. Now, if you can do all that in 10 lines, fantastic, I look forward to your library as competition in the future. :3 While I'm glad you've found a solution that works for your case, I can't tell you why you were seeing latency in our library that wasn't also in the browser. I'm well aware of the JS-to-IPC-to-hardware chain in the browser (I'm the ex-device interfaces lead on firefox, worked with some of the chrome engineers on the development of the hardware focused WebAPIs too) and it's even more complicated than ours. |
![]() |
| Also, if you're curious about web focused solutions to these issues, this is the perfect time to bring up a friend of our project, XToys: https://xtoys.app.
It's a fully web based (though closed source) toy control application that supports about as many devices as I do, plus a bunch of others that I don't, and has Blockly scripting and WebRTC for remote sessions. It's neat as hell. |
![]() |
| Best: Funny enough, it's for a (set of) device(s) that constantly causes me issues, the OSR-2/SR-6/SSR-1.
Here's a background video I did on the hardware: https://www.youtube.com/watch?v=MFcrNk33_io It's DIY, 3d-printed hardware that's incredibly extensible, and has a decently designed abstract communication protocol that I've ended up pointing other DIY creators at. Keeping up with everything the hardware can do while also trying to make it work with our generalized commands is a challenge, but it's a good challenge, because we don't see a ton of innovation from the large commercial manufacturers. Least enjoy: We support over 500 devices now, so this is just a whole classes of devices at this point heh. There's a lot of hardware we support that's just not very good to begin with, and users can't tell whether it's our library or the hardware hardware that sucks. Then there's the hardware that makes very... odd decisions about how to do things. For instance, there was a brand known as MuSE or Lovespouse that's been popular for the past couple of years. Instead of creating a bluetooth connection to the device, the device acts as a host and listens for advertisements w/ specialized data in order to set vibrator power. Not only is this easily hackable (there was a bunch of articles about someone doing exactly that with a flipper zero last year), it's damn near impossible for us to implement cross platform support for, as advertisement creation in BLE is wildly different across platforms, and doesn't even exist on iOS (the company themselves only shipped on android, where buttplug works on win/mac/linux/android/iOS). On top of that, the Lovespouse devices were extremely cheap ($10-30US sometimes), so we had users buying them then asking if we supported them, and all we could say was "nope". |
![]() |
| Oh lord do I have some stories there. Way back in the nascent Quantified Self days, I ran http://openyou.org, which was basically "Buttplug for consumer health devices" (I mean I guess Buttplug is Buttplug for a specific type of consumer health device but, well, you get the idea).
There's a god damned heart rate profile standard in the bluetooth spec AND YET I'm not sure I ever actually worked on a device that used it. :| |
![]() |
| Cool to see someone quoting Cex 20+ years later. I listened to his stuff a ton back in the day and actually revisited only just a few months ago. Holds up just fine. |
![]() |
| One of the best posts of the year!
Tech, caring and humor in butt one in and out And there's even an acceptable self-plug! |
![]() |
| You're absolutely correct! I mention this elsewhere in the documentation even. Buttplug really is just a userland HID manager at its core. The only specialized part is the context of commands we send to devices.
The original plan (and it may still happen, who knows) was to figure out a way to chop off that top message layer and create a generalized system for doing exactly what you've said. That was going to be called 'deviceplug', and it's why btleplug is under the 'deviceplug' org on github (https://github.com/deviceplug/btleplug). I've just never gotten around to it because I'm not quite ready for the additional support burden yet. All that said, Buttplug is also a haptics experimentation project aimed at finding out what it's like to create a way to communicate about a very specific type of touch via technology and programming. There are specific goals within the project related to that, but the amount of tech required to actually pull that off means I end up with what basically amounts of a fleet management framework. :) |
![]() |
| Hear hear.
The fact that (for the most part) 2 American credit card companies determine what porn people can and cannot watch on-line world-wide is an embodiment of this very problem. |
Hi, I'm qdot, founder of buttplug.io and author of Butts Are Difficult, the ethics page in the buttplug.io docs.
I also wrote the rest of the buttplug.io docs but this is the part that I'm proudest of, both because I was really happy how it turned out and also because unlike the parts of the docs involving the API, this one doesn't go out of date as quickly.
Ask me anything!