There comes a time in every software poorly planned open source software project where you have to sit back and say “Wait, am I completely off the mark? Did I totally fuck this up?”.
Of course, these times really shouldn’t happen at a frequency of once a month, but here we are. Unlike prior fuckups, this time I have a blog, so instead of fixing things, I can write about them!
But to be fair, a bit of self reflection is good before starting on the fixings.
Buttplugging So Far
Buttplug is itself an experiment with a general goal but no real focused direction to get there. The idea is to hand developers a way to easily access sex toys (this will come back to haunt us very soon) and then see what they do with this newfound raunchy power.
Thanks to the glorious lack of direction on how to achieve that goal of easy access, it’s also ended up as an exploration of technical niches like hardware drivers, implementation languages, and platform features. Its how we’ve gone from being a single library written in C# to two libraries written in C# and Javascript back to one library written in Rust with C# and Javascript/WASM layers on top of it, while also ending up maintaining a cross-platform Bluetooth LE library along the way. Buttplug at this point is balanced between being a useful sex toy library and a shitpost made of bleeding-edge development technologies, and I wouldn’t have it any other way.
One of the core philosophies of the library is that it should only maintain direct access with the hardware it works with. Currently, it uses only local communications systems like Bluetooth, Serial, or USB to talk to hardware. This means that, even if a company’s services go away, I can still provide users with a way to access their toy across software that works with our library. The library already supports out-of-production toys like the Real Touch, and many toys it can connect to now will suffer this same fate of obsolescence in the future, and we will be there, make sure they vibrate until the heat death of the sun or the usable lifetime of their $0.43 motor. This work has even gotten us to the point where sex toy manufacturers like The Handy actively engage with library development to provide support for their hardware. This strategy also helps preserve the privacy of the user, letting them choose hardware while being free of having to live on whatever ecosystem is provided by that hardware’s manufacturer.
During this time, Buttplug has stayed mostly desktop focused. While there have been web apps that work on Android and some via some alternative iOS web browsers, mobile offerings have been sparse at best, mostly due to lack of development resources. This happened while pretty much every sex toy manufacturer focused solely on mobile.
While all of this has been a mostly successful endeavor, it also assumes a usage model that may not always work for users of certain kinds of toys or in certain situations. Ironically, this includes many situations involving the type of toy from which I took the project name.
Buttplug, Buttplugs, and Social VR Worlds
Up until 2020, most applications for Buttplug assumed that a user was near their computer. Be it media players, single player game interaction, or other interactive applications, I mostly assumed that the user would stay still and near whatever computer was controlling the toy while using it. Even in teledildonics situations or mobile applications, there hadn’t really been any applications built where the device user and the controlling computer were assumed to be all that far away from each other.
Every so often I’d hear about random hardware disconnection issues in Buttplug (my library, not the toy), mostly with insertable toys, and in that niche, mostly with buttplugs (the toy, not my library). These toys use Bluetooth LE, a system that was not really made for fast updates, or butts, or updating things in butts in a fast, reliable way. Bluetooth LE is fine when you have line of sight or not much distance between radios and their hosts, and just need to throw data around in a leisurely way. Since Bluetooth is radio, it also would very much like to not be impeded by things like water. Overall, this means Bluetooth LE is great for things like mobile phones and small IoT devices that will stay near each other, not so much for desktops or gaming laptops, and definitely not for desktops/laptops talking to devices is in one of the deeper, harder to reach parts of a (mostly water based) human body. The past few years have been a lesson in doing this the hard way, as developing cross-platform bluetooth applications for desktop operating systems for body-immersed hardware has been nothing short of an absolute nightmare.
Unfortunately, I just don’t have many options to offer otherwise. No one seems to want a USB cable coming out of their butt (the luddites), and most people want their toy to be able to talk to their phone (as those are considered the most “private”/”intimate” technology accessing device), and phones either need WiFi (which is power hungry and complex to configure and implement) or Bluetooth to talk to the devices.
Doesn’t stop me from yelling into the void though. I’ve groused in the media for years about Bluetooth LE being bad for sex toys, though people that actually manufacture products and are better at this than I am have said otherwise.
“The antennas aren’t good enough!”
“There’s not enough transmit power in the toy!”
“Sex toy manufacturers don’t have the experience to build what’s needed!”
Up until 2020, it wasn’t much of an issue though. A few reports here and there, some recommendations on dongles and buying USB extension cables, and we’d be on our way.
Then Buttplug integration with VR social worlds like Neos and VRChat happened, and suddenly disconnection reports spiked. Thanks to COVID-19, these worlds went from social outliers to life-saving spaces, and as with any and all spaces, people fucked in it. The invariant of people being near their computers while using their toys was broken, thanks to being able to inhabit, walk around in, and hump these new shared virtual spaces instead of just sitting quietly like a good user. Not only do they move more, their sessions are longer, with reports of some users using VR social worlds plus Buttplug related plugins (both hardware and software) for upwards of 6 hours at a time.
The combination of “Room scale” VR plus lengthy sessions plus hiding radios in the meat and water caves we call butts means devices often lose connections as users move around and power levels decrease, and thus cause the support channel on my discord server to see far more traffic.
This is not good.
What now?
Buttplug’s current connection methods aren’t cutting it. It works fine for people being near their machines, but that doesn’t work for VR, nor for those who just want to use their phone for certain situations. The current development strategy also puts the library at odds with toy manufacturers, who develop for and test on mobile and basically ignores desktops.
To fix this, I need to figure out ways to combine phones (or small machines like Raspberry Pis) and desktops/laptops in order to work with more situations. This needs to happen while balancing three considerations:
- Not ceding ground to manufacturers for online services, so the library isn’t just a frontend for a bunch of services we don’t own or can’t replicate.
- Preserving the privacy of the user, making sure that someone who is fine with their local connection setup and doesn’t want to use network/remote control never has to.
- Making sure development ergonomics don’t suffer, while also making sure developers understand and expose features to their users in a way that doesn’t undo the preserving privacy point.
A few solutions to this problem already exist, in the form of the Lovense Connect application, as well as the XToys web based toy control and scripting system. In the next couple of blog posts, I’ll be outlining how these two systems have built their solutions, and what the next iterations of Buttplug can steal from their products. I’ll finish out with a concrete overview of where Buttplug is headed, both in terms of fixing insertable toy connectivity issues as well as thinking ahead to building remote services with the library. Along the way we’ll learn about how to design these kind of services, check out new technologies available to speed development, and most importantly, have ample time to appreciate the selection of clip art images I hastily googled for while writing these posts.
Onward and inward!