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.
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 I wrote and manage our Bluetooth le library! It’s been one of the bigger regrets of my life, but it had to happen and at least it works and I don’t have to touch it much now. :)
>If I'm REALLY turned on, how long does it take for me to go from "I wanna use this" to "I am using this"?
I'm glad this is a concern. I maintain software to the effect of buttplug.io and a particular inspiration to start the project was how difficult alternatives were to get going with. I don't want to install anything, or register anywhere, I just want to get my rocks off!
And thank you for buttplug.io. It's super easy to integrate!
I'm laughing so hard because the guidelines in that section track very closely with things that I'm constantly reminding people about with unmanned aviation software. You just need to s/turned on/in an emergency/.
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 :) )
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".
I tried to use buttplug years ago but I found it to be difficult to work with and introduce too much latency into play. My partner and I have replaced it with 37 lines of javascript that give us more realtime control of our toys (albeit only Lovense, by just spamming .writeValueWithoutResponse()).
I'm curious what your background is that you approached the problem in the way that you did? I appreciate that you're covering all the edge cases for a lot of different toys, but it also really feels like you use 1000 lines of code where 10 will do.
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.
I love your ethics statement. TBH, this mindset ought to be the bottom line for any serious software (non-demoscene / non-fun-and-games type). Without pervasive empathy for the user, it's kind of hard to do the right thing in the first place. Especially within the strange organisms that are organisations.
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.
1000s at least. We don’t have any detailed metrics because the data privacy issues there are… a lot, but going by download numbers and knowledge of platforms and some of the larger applications, it’s a decent number.
Yup, you are completely correct on the sensor side. I try to be fairly choosy in what we support, but yeah some strokers and machines definitely do not have the safety features I’d like.
Many years ago, there was another device that relied on a lubrication pump, but the pump never worked very well (building a pump for unspecified body safe lubricants is difficult on several levels).
The term “degloving” got used in relation to the hardware a couple of times.
This is actually a think that Oculus / Meta feels like they didn't consider and still don't, even tho by their own statics it's the number one use for VR
Some of this I'm sure is my particular usage but still...
Examples: When the controller batteries are low I get a warning in the middle of my session and it sticks around way too long. If a battery dies in a controller the message is undismissible. The software I use works fine with one controller but instead I have to stop what I'm doing, remove the headset, find a battery, install it, put the headset back on, resume the software, and often reset the view because anytime you take the headset off it resets it's orientation.
There are also times where it just says "Fatal Error" and exits when the battery dies.
Another issue is I have 2d software I use in VR because having a giant screen is nice. But, Oculus insists on playing some annoying hum sound in the home screen with the built in desktop viewer. Note: I'm not using the 3D environments as my home screen because that ads more time to get stated. So, in any case, I have to launch something to get rid of the sound. I usually pick a video viewer app because it's very small and then pop up the desktop over it without selecting a video. But, Oculus is apparently unaware of this use case because they break this in some new way every few releases.
The latest is, if you bring up the desktop in the middle of an app, after about 5 seconds it automatically takes you back to the VR app. It's almost like they forgot the feature exists. Other issues in this area are it went from a fairly rock solid feature to one out of 3 times entering into some bug loop where it flips between paused mode (desktop) and VR app mode. Being able to get out of this loop bug has about a 1 in 4 chance. Fixing it removing the headset and restarting the Oculus software on the PC. Then starting whatever apps you were in.
Note that I'm using a Rift-S. I tried using a Quest 3 with Link which tries to give you the same experience but the Link was way way too flaky, crashing 1 of 3 times, when I pulled up the desktop.
Another feature that broke, which I used frequently, was pulling up the desktop and pinning it so it stays visible while a VR app is running. It was a great way to goon.
And, all of this is using porn software which makes it hard to make bug report that will be taken seriously.
I really wish more headsets had eye tracking available, I've wanted to play with UX for multi-video/image gooning interfaces with gaze direction. Unfortunately headsets with that available built-in aren't cheap and the DIY solutions are still somewhat tedious.
Would love to discuss these use cases more though, feel free to contact me via one of the methods in my HN bio!
I’ve loved the Buttplug project. I was hitting an issue with their Bluetooth library controlling a we-vibe, and someone offered to drive over from the other side of the bay to help debug it. Bluetooth sniffer, and all.
Readit News
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!
Here’s how that came together: https://nonpolynomial.com/2023/10/30/how-to-beg-borrow-steal...
Hilarious and impressive; I’d love to hear more, do you have more details, context or source?
I'm glad this is a concern. I maintain software to the effect of buttplug.io and a particular inspiration to start the project was how difficult alternatives were to get going with. I don't want to install anything, or register anywhere, I just want to get my rocks off!
And thank you for buttplug.io. It's super easy to integrate!
I realise this isn't much of a question, sorry :)
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".
I'm curious what your background is that you approached the problem in the way that you did? I appreciate that you're covering all the edge cases for a lot of different toys, but 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 the double entendre of "plug" in technology contexts, subtly brilliant.
The thing is a pinch hazard and a user could get their scrotum sucked into the slit of the machine, or get pinched as it vigorously slides back down.
Just look up the reports of what can go wrong --it's not pretty. ("do not press it on your scrotum" is the frequent community refrain.)
AFAIK, most of these devices do not have pressure sensors and feedback mechanisms. They're output only.
No amount of software develpper empathy will help as when things go wrong it will happily slice your genitals off and keep chugging away.
Many years ago, there was another device that relied on a lubrication pump, but the pump never worked very well (building a pump for unspecified body safe lubricants is difficult on several levels).
The term “degloving” got used in relation to the hardware a couple of times.
I see what you did there.
As for which CoC to use (if looking for a prewritten one), you can check out ours as an example."
Haha, not sure if intentional.
:3
Some of this I'm sure is my particular usage but still...
Examples: When the controller batteries are low I get a warning in the middle of my session and it sticks around way too long. If a battery dies in a controller the message is undismissible. The software I use works fine with one controller but instead I have to stop what I'm doing, remove the headset, find a battery, install it, put the headset back on, resume the software, and often reset the view because anytime you take the headset off it resets it's orientation.
There are also times where it just says "Fatal Error" and exits when the battery dies.
Another issue is I have 2d software I use in VR because having a giant screen is nice. But, Oculus insists on playing some annoying hum sound in the home screen with the built in desktop viewer. Note: I'm not using the 3D environments as my home screen because that ads more time to get stated. So, in any case, I have to launch something to get rid of the sound. I usually pick a video viewer app because it's very small and then pop up the desktop over it without selecting a video. But, Oculus is apparently unaware of this use case because they break this in some new way every few releases.
The latest is, if you bring up the desktop in the middle of an app, after about 5 seconds it automatically takes you back to the VR app. It's almost like they forgot the feature exists. Other issues in this area are it went from a fairly rock solid feature to one out of 3 times entering into some bug loop where it flips between paused mode (desktop) and VR app mode. Being able to get out of this loop bug has about a 1 in 4 chance. Fixing it removing the headset and restarting the Oculus software on the PC. Then starting whatever apps you were in.
Note that I'm using a Rift-S. I tried using a Quest 3 with Link which tries to give you the same experience but the Link was way way too flaky, crashing 1 of 3 times, when I pulled up the desktop.
Another feature that broke, which I used frequently, was pulling up the desktop and pinning it so it stays visible while a VR app is running. It was a great way to goon.
And, all of this is using porn software which makes it hard to make bug report that will be taken seriously.
Would love to discuss these use cases more though, feel free to contact me via one of the methods in my HN bio!
Tech, caring and humor in butt one in and out
And there's even an acceptable self-plug!