Oh hey it's been a while.
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!
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. :)
Here’s how that came together: https://nonpolynomial.com/2023/10/30/how-to-beg-borrow-steal...
i'd think it would be fine to touch it if you wash it with soap and water first and maybe a few swipes with an antibacterial wipe?
Bluetooth is bad at a spiritual level
your kink is ok
I was telling my gf this yesterday as my car refused to pair with her phone (she had to unpaid it so that it wouldn't try to connect when we were driving both our cars nearby) which I guess is a necessary step of connecting (I am not sure I've ever successfully connected two Bluetooth things without pairing them) before the traffic light turned green and the car locked up the Bluetooth UI, so that the driver couldn't operate it, which meant that both the driver and the passenger spent loads of extra time fucking with it until giving up and playing the song directly from her phone's internal speaker
I have never ever seen Bluetooth work as intended
You are either speaking hyperbolicly or lying. Bluetooth is very stable these days.
You must live in some alternate reality. Bluetooth is hardly stable for me.
> You are either speaking hyperbolicly or lying. Bluetooth is very stable these days.
Bluetooth as a network protocol, that might be stable. Bluetooth interactivity is not stable or even usable in many cases.
It's not just in cars and other non-computer interfaces, good luck trying to pair a non-Apple device with an Apple device. If you say "it works on my computer", congrats, you're the only one. And also speaking hyperbolically.
The Bluetooth experience varies wildly. The Bluetooth stack is pretty enormous and complicated these days, so there's a lot of space for software and hardware vendors to screw things up.
Apple-to-Apple seems to be dead reliable from everything I've heard. Samsung-to-Samsung seems almost as good. Apple or Android to random, Chinese car stereo might be a connectivity nightmare. Connecting to an OEM stereo with whatever implementation was poorly specified by the car company might also be a nightmare.
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.
i'd think the prius software being old and not upgradable would guarantee that it would work; apple can't have possibly tested their iphone 13 with the models tesla brings out next year, but a 2009 prius ought to be an extremely well characterized platform for their compatibility testing
Well, whether it should be or not, with the iPhone 13 my phone and car simply no longer communicate well. I experience failure to complete calls after repeated attempts, slow connections between phone and car, and other difficulties that I didn't experience with my iPhone 11. I don't have other Bluetooth related difficulties, only with the car.
i didn't mean to suggest that i doubted your veracity; i just think you're letting apple off too easy
I had a Prius of that vintage; and as I recall, the onboard infotainment system could be upgraded (both for software and navigation data, IIRC), but it was a something you had to take it into a dealer and pay several hundred dollars for, and there was no proactive notification when there were updates available or what they addressed. I doubt they are still rolling out new updates (but maybe), but even if not it may be possible (though possibly not useful for your problem) to still get whatever the last one was.
The problem with most automakers (good example, General Motors) and their electronics divisions (i.e ACDelco) is their centuries of experience with getting sued, so everything innovative gets reworked to satisfy the demands of the legal department, specifically as far as cars sold in the United States is concerned.
There's a difference between being stable (robust once connected), and connecting aggressively.
We have two cars from the same manufacturer, each paired with two iPhones. Start either car or drive by, and the car will take over an existing Bluetooth connection from one of the iPhones. And by take over, I mean: disconnect an active connection streaming to Airpods/Beats/Airplay soundbars, and grab that stream of music/video/conference call into the car.
The driver in the car then has to pause playback or hang up on someone else's call, because there's no way to pass it back.
Sadly, the most prevailing standards are rarely the best ones. But we're stuck with it until corporations decide to throw money at the successor.
That's funny, I had to write a dual mode host library for an embedded project a while back, and feel exactly the same way.
What do you regret?
I don’t really have a ton of interest in maintaining a ble library, it’s just required for my main library. Theres a lot of weirdness around Bluetooth implementations between platforms and now I’m on the hook to either support them or tell users nope. I’d rather be doing neither and just be the user or someone else’s nice cross platform Bluetooth rust library. (Luckily we do have some fantastic contributors)
I have no interest in BPs but your post is very informative, and your writing is insightful and funny. I wish I wrote that well!
Are you aware of any uses of your software in other domains, e.g., health?
> 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?
Source was me, from some friends that were trying to use the library and the name was causing issues with contracts. Btleplug was named the way it is because I am horrible, and the name alone has caused it to have to be wrapped or just not used at least a few times.
Which hey, less support for me.
Hilarious! That's a fantastic name and an and an awesome side effect.
This vindicates my latest project where I named the components after anime characters
Otherwise I couldn't keep track of them, see..
>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 realise this isn't much of a question, sorry :)
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/.
I used to work in self-driving cars waaaay back when (2008-2011, the early days of the current era) and I did pick up some of these ideas from there. :)
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 :) )
Sure; I have a Walltaker[0] (hi Gray) client with Buttplug support[1], it buzzes when your wallpaper updates! But my magnum opus was software akin to Edgeware[2] - basically, based on a Yaml config, it'll show you local or remote porn in various ways. That would have Buttplug support had Github not nuked the repo and ignored my reinstatement request for 4 months. I chucked it on Codeberg[3] if you're curious.
[0] https://github.com/pupgray/walltaker
[1] https://github.com/dogkisser/walltaker-engine/blob/8bc374162...
[2] https://github.com/araten10/EdgewarePlusPlus
[3] https://codeberg.org/rocketcookie/goonto
Oh my god this is amazing. There is so much to dig through here. Thanks!
Also fantastic github account names.
Which toy did you enjoy the process of testing and supporting the most? And the least?
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".
I used to work in the Group Fitness (gym electronics) space and this is exactly how some BLE heart rate monitors get around the problems with otherwise requiring the host to connect to 20+ devices to capture their data. Put heart rate into the Manufacturer-Specific region of the advertising packet and boom, no one needs a connection.
Problem is that it's non-standard, so every device packages the data a different way.
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. :|
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.
> 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.
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.
Now realizing it's been... 23 years since I saw Cex open for Kid606 and I'm gonna go crumble to dust now.
I suspect you folks are not talking about this Cex:
https://uk.webuy.com/
Which isn't a "he" as far as I can tell. There's a shop near were I live. I always pronounced them "sex" and everyone always told me that's not how it's pronounced, but never told me how else it's pronounced.
I’ve got a few friends who worked at CeX in their teens, and “sex” is the correct pronunciation. Reinforced by their open guest WiFi being called “Unprotected CeX” and the staff calling themselves “CeX workers”.
How many BPD do you estimate your software is supporting nowadays ?
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.