Interview with an Intiface Haptics Engineer

I was recently re-reading my Interview with a PornHub Web Developer and one bit I started thinking about was the VR question and the idea of making users not just see but feel` something. The haptic feedback of VR games is what really sets them apart from your standard PC or console game. So when it comes to sex tech, what's it like to create experiences you feel instead of see? I had the opportunity to interview Kyle Machulis, aka qDot, about coding haptic experiences that give people good vibes. Enjoy!

Warning: This blog post details coding for sex toys and other adult conversation.  Please discontinue reading if these topics could offend you.

What was the original inspiration of the buttplug.io project?  

The original inspiration continues to be the main inspiration today: To let people with the capabilities build whatever it is they want for the computer controlled sex hardware they own.

I didn’t really have a specific niche or community that I was aiming for with this, rather I just wanted to get the boring programming stuff out of the way for people so they could just get to building what they were interested in without having to learn the eccentricities of cross-platform Bluetooth/USB/etc, making sure it connected to the network correctly, and all that…

Were there any hesitations in giving it such a blunt name?  Has the name been a net positive or negative for the project?

Funny enough, the original name of the project was Fuck Everything. I had multiple people talk me down from that particular ledge, mostly with the reasoning of “you’ll never be able to easily talk about this in media or have it referenced.”

With that in mind, I still wanted something fittingly ribald, so Buttplug is what I went with (I made a video on that reasoning too: https://youtu.be/c6bghuCy6d8). It was and still is definitely a risk, but what are my alternatives? I could go with something benign, which would work but would be kinda boring (and this is what I did with Intiface, the name of the application line that sits on top of Buttplug, in order to be able to use it in app stores). Since Buttplug is the name of the library, and will mostly be used by developers (“embedded” in their programs, as it were), it felt like a safe place to be a bit silly.

What was the goal at the start of the project and how has the project reached where it is today?

I stated the goal up in the inspiration question, so I’ll stick with that. In terms of measuring the project reach, I feel like that’s best shown by our “Awesome” list: https://awesome.buttplug.io. 

This is where I try to keep up with our community in listing everything they’ve built using the library. Most of the concentration tends to be around either Games or Movie sync, but there’s all sorts of projects that’ve sprung up around it, and we hear of new ones every month. The spread of project types alone there is what keeps be going.

From a technical standpoint, what are some of the hallmark technologies and ideas behind the project?

Trying to come up with a sort of “common technical language” for intimate haptics is a big part of the technical focus. This is SUPER difficult to do and we’ve already gone down multiple wrong paths, but I knew it was going to be a long course of refinements and I wouldn’t say we’ve tracked too far off, especially given the amount of projects implemented using the library already.

We’ve also ended up having to implement most of our own Bluetooth LE library (https://github.com/deviceplug/btleplug), though I’m lucky that the Rust ecosystem provides us what we need too.

Finally, being able to present the project to people on their turf (programming language/platform)  instead of ours is a constant ongoing challenge. We currently ship the main library in Rust, with bindings in C#, Javascript/WASM, Java, and Python, and people have made bindings for languages like Haskell and Go. It’s super important that people be able to approach this work from however they’re comfortable versus having to learn another language, so the design has to stay flexible enough to work across multiple technical contexts.

What are some of the key engineering terms that are important to know?

• Haptics - The study of touch
• Haptic Feedback - Using the sense of touch to notify users of events or other situations
• Rumble - How we normally discuss video game feedback, with motors in gamepad
• “HD” Rumble/Haptics - A recent development in consumer haptics, mostly in newer game controllers (Switch Joycon, PS5 DualSense, VR Controllers) that uses small actuators that can quickly change speeds, extending the haptic vocabulary beyond rumble to things like taps, knocks, etc…
• Teledildonics - The original term (as coined by Rheingold) refers to remote sex between two people, but these days the term is used loosely to refer to sex toys that can communicate with/be controlled by computers in general.

How has your technological approach changed from the start of the project to now?  How has each language (JavaScript, Rust, etc.) improved over the course of time to make the project better?

Here’s a quick timeline of the implementations:

• 2013: Tried a simple implementation in Python, didn’t make it very far because there wasn’t a lot of hardware available and bluetooth support was iffy everywhere.
• 2016: Tried Rust, but it was a little too early and I was going to have to implement too much from the ground up. Tokio was the async choice at the time but it was rather complicated to use, and I was used to async structures in other languages (JS/C#) so it just didn’t go well.
• 2017: Moved to trying an implementation in C#, so we’d at least be able to support windows with its new UWP Bluetooth APIs (which came out in April 2017). This worked out really well, but also tied us to Windows and C#, and even then I was really more comfortable in Rust and wanted the system fully cross platform.
• Later in 2017: Added Buttplug JS, because we had WebBluetooth/WebUSB/WebGamepad available. This was a completely separate implementation from C#, because WASM wasn’t really a thing quite yet.
• 2019: Finally got sick of maintaining side-by-side implementation of C# and JS, Rust was about to release async and WASM was starting to look good, so started development on a 3rd version of Buttplug in Rust, while still maintaining C#/JS.
• 2020: Suddenly I had a LOT of free time at home, so the Rust implementation continued over the year. By the end of the year, not only did we have a Rust implementation, but the C# was working with basically the same API on top of Rust, and the Rust could also compile almost directly to WASM, meaning we had about 95% of the same code backing all of the different language implementations
• 2021: Moved completely to Rust, which is where we still are today.
  
  

How does your code make it from raw source, to compilation, and then onto devices?  What is the testing and debugging process like?

First off, there isn’t really an “onto devices” here. The library isn’t firmware, it’s software, built for applications to communicate with or integrate. Our job is to interface with whatever firmware might be on the device already, but we don’t specify that a certain firmware has to be there. We implement protocols for many different brands, as well as a few open source/DIY systems (like T-Code, a g-code like derivation for toys made by another DIY community project: https://stpihkal.docs.buttplug.io/protocols/tcode.html).

In terms of compilation/distribution, this is just software, like any other, so there’s not much special there. All of our libraries and applications go through CI (a mix of Azure or Github Actions at this point), all of our applications are signed (so people can at least somewhat trust it came from us), etc… 

We do support multiple platforms (Win/Mac/Linux/iOS and hopefully Android soon) and languages (the core system is Rust, but there are support libraries in C#, Javascript/Typescript (via WASM), Python, Java, Haskell, Lua, and the list goes on, either written by me or the community), so packaging of those also takes place on CI.

Debugging and testing is… difficult because at this point, we support like 20+ brands of toys plus the DIY projects, and each of those brands may have 10+ toys. All in all (going by IOSTIndex, a website listing all known computer controlled toys: https://iostindex.com/?filter0Availability=Available,DIY&filter1Connection=Digital&filter2ButtplugSupport=4), the library supports 247 toys right now.

I’d love to have a more robust testing system for hardware, as I think as lot of even the hardware testing could be automated in really interesting ways by building mock devices that still use the actual Bluetooth/USB/etc communication busses, but that’s been a project that’s eluded me having the time to put it together.

Obviously we can’t test ALL of those 247 or so toys on every release because the library is mostly me developing it and maybe 1-2 other people helping with a bit of code or QA. We try to test the most popular brands, like Lovense and Kiiroo, and depend on user reports for bugs and updates on breakage. The discord server (https://discord.buttplug.io) has been a fantastic resource for that, as a very engaged community has built up around the library. We often have people show up with toys we haven’t been able to get yet, and can work with them remotely on getting support integrated on the library, sometimes even before any library dev receives one.

What could each programming language add to make buttplug.io better?

• Rust gives us the basis in safety I need to feel ok releasing a project that actually works in a multithreaded way while being in people’s bodies.
• JS/WASM makes it easy to prototype VERY quickly and ephermally, as people can play with Buttplug completely in the browser. This means if they don’t want to check out git repos or have other things that could be seen as incriminating (for lack of a better term) on their machine, they can just do something in glitch or jsfiddle or whatever, and still have full hardware control
• C# is now our gateway to games, specifically for Unity. We have a Unity plugin as well as a full C# library, and there’s just way more developers there than there are for Rust, so it expands usage.
• Same with Python. Quick and easy for people to prototype things, and more people know it.
• The only reason I plan on doing C++ is to support Unreal at the moment. :)

Who are some of the organizations that use your project?  Has your work broken into the mainstream adult film industry?

• https://xtoys.app uses our library for some of its hardware integration (though they support more types of hardware than we do!)
• ViRo Playspace uses our library for hardware access, and is distributed on Steam!
• We’re also in quite a few Patreon funded games like Heat and FarmD

In terms of the film industry, our library is used a lot for “movie sync”, which is a community run effort to create scripts that sync hardware to movies. The main place for that is https://eroscripts.com, though there are also companies like SexLikeReal that do hardware sync.

One struggle of most open source project is funding and monetization – how has monetization factored into the project over the years?

I spent close to a year evaluating and trying out different strategies to go full time on the library, but in the end, while some of those seemed viable, I ended up figuring out that it’s not really something I wanted to do. I’m happy keeping Buttplug as a side project. It’s still an expensive side project though, so I try to keep some cash coming in to fund machines and research hardware.

Most of the funding comes from 3 sources:

• Crowdfunding: I use patreon (https://patreon.com/qdot) and github sponsors (https://github.com/sponsors/qdot), though patreon has been 90%+ of that side of income. I offer tiers where donors can get weekly updates, stickers, 1-on-1 video conferencing, etc… It’s been a really good way to engage with the community
• Affiliates: Turns out, sex toy companies will pay you to sell toys for them, and since the library doesn’t really exist without other company’s toys, this ends up being a pretty good monetization strategy for the project too. It also allows me to establish partnerships with companies, which wasn’t really something I’ve been able to do much before, as a lot of companies saw Buttplug as something that took away revenue rather than brought new users on-board. 
• Consulting: Thanks to all of the experience I’ve gotten with Buttplug and working with sex tech for all of these years, I can now consult on engineering, UX, etc in sex tech for companies in the field. What the library does and what our community builds is still far ahead of what most companies are seeing their users ask for, so working with me allows them to plan for what the future may look like.

I see a variety of video game controllers on your list of soon to be supported devices.  I have to ask ... what's the demand for support in these types of devices?

It’s not really so much demand as it is acknowledgement of availability. Gamepads with rumble are easily the most widely owned type of computer controlled vibrators. Supporting game controllers that vibrate means that:

• Developers can just have something on their desk that’s not a toy to test with
• Users can see what programs that use Buttplug do before actually spending money on a toy

So it’s a win for both sides of the community

Are there any health liabilities that you need to consider with your project?  Could a bug cause physical harm to someone?

Certainly, and it’s something I try to stay aware of. I try to only support toys that don’t present a clear danger to users, so while we’re fine with vibrators and strokers, we try to stay away from things like shock collars, electrostimulation, etc. I’m also working on settings that allow users to set maximums for toy output, so they can scale features to their own needs.

That’s also why the library is open source, so if people don’t feel they can trust something on its face, they’re more than welcome to look at the insides or ask me. Even with the project being open source though, I’m also extremely careful about accepting any PRs and require massive amounts of vetting first. We have so many people that really want to help on the library but have never used it, or even worse, say “Oh yeah I’d like to learn [insert programming language here] by contributing” and I always have to ask “Do you trust your just learned code to be in people’s bodies”? I really wish more people said “no” to that question, heh.

That said, there’s only so much I can do, because users are going to do what they want with the system, so I add the safeguards I can, have it security audited, and try to make it as configurable as users need so they can feel safe too.

How has the project grown since inception?  What is the community presence?

The project has spawned other projects (https://iostindex.com is run by someone who also works with Buttplug, for instance, and there’s all the stuff on https://awesome.buttplug.io, many with their own communities), it’s got a discord server with thousands of users, and I’ve taught live workshops on it. It’s hard to get an idea of exactly how large it all is these days because there’s just so much breadth, and also because I don’t have visibility into all of it. Since it’s open source and free, and I don’t really do much tracking, sometimes it’ll just pop up in places I don’t expect, or I’ll get tagged into discussions in places I never knew existed.

What is your typical work day like?

Unimaginably boring. The same engineering as most places just with different context. I’m usually tuning data structures or figuring out UX issues or whatever, all while surrounded by sex toys that are collecting dust or only turned on to run smoke tests before releases.

The fun days are the ones where I decide to just do something silly with all the crap I’ve built. For instance, this past week I did a quick Elden Ring mod for making a toy vibrate any time that game makes the controller vibrate. The tech wasn’t too out there (there’s an explanatory article here), but watching the reaction on social media is fun, and I end up in conversations that are surprisingly positive most of the time.

Is there a stigma attached to telling friends, family, and acquaintances you work on adult toy technology? Is there any hesitance in telling people what you work on?

For me personally, not at all. I’ve been working in sex tech since 2004, and I’ve used my real name and identity for that whole time. While this has made for difficulties in some places in the past, overall it’s provided an extra level of trust for me. People know who I am, know where the project is coming from, and I have the privilege of being able to share that, which is rare in this kind of technology. There’s a lot of sex tech software authors out there that are required to stay anonymous due to various reasons, and that’s fine and understandable, but I wanted to actually be out there and available about this topic when I saw I had the chance, and it’s really paid off.
That said, it’s not something that comes for free. I have to spend a massive amount of time “curating my brand”, for lack of a more human term. There’s a ton of thought that goes into presenting the project as ethical and sex-positive, so much so that I have a whole section of our dev guide dedicated to it. Since this is also on my resume/cv/LinkedIn/etc, I have to constantly be thinking about what the external perspective of the project is, and try to keep the shape of that being something I want.

End of interview

There's something really interesting about creating haptic experiences. I've always relied so much on whether something looks good, but knowing when you've created a great haptic experience must be incredibly difficult. Then add the number of devices you want to support, user preferences, the number of vendors, and the stigma the work sometimes brings, it's gotta be a trip. Huge thank you to Kyle for sharing his perspective and experience!