Buttplug (Sex Toy Control Library) Hits v1 Milestone

That said, there are some security/privacy features built into the architecture to reduce metadata dissemination, I'll be outlining those in the developer guide at some point.

As for talking to people about the project, I've been a public face for the field of sex tech since like 2005, so by this point I'm pretty used to it. It's on my resume, I have academic publications and book chapters on the subject, I've spoken about it at all sorts of conferences around the world, so I've kinda settled into being "The Buttplug Guy".

It took a ton of hard work and image building to get here though, so it's a cliff I don't really recommend anyone else try to climb without realizing how much work it is.

There's a dichotomy in this project that's difficult to resolve:

- Community wants sex toy access because there isn't much else out there that does this.

- I wanna learn new stuff and also have a weird "LET'S PUT DOOM ON IT" mentality of having the library support everywhere.

So we end up with support for lots of toys, but it's on top of a complicated, violently async rust library that is in some cases compiled to WASM, which is a whole stack of technologies not a lot of people are familiar with.

To torture another metaphor, I've ended up building the hulking game engine for sex toys, when a lot of people would be fine with some Atari 2600 games that vibrate. Lots of people are going to have 1 toy they want to control with 1 simple interface, where my interest lies in "how does someone release a game on Steam that seamlessly supports whatever the user shows up with".

The updated developer guide (https://buttplug-developer-guide.docs.buttplug.io) is my first crack at trying to cater to all audiences, but it's got a long way to go, and the only way to test documentation is to hopefully wait for feedback from people who read it.

But that's why try to I keep both the protocol and reverse engineering documentation up to date. I don't want people to have to go and reimplement things, but if it has to happen, I want to make it as easy on them as possible.

Everything that v1 rust does right now, our C#/JS versions did before, so the technical work there was mostly fitting it from gc'd runtime'd languages into Rust. I'm much better at Rust now though!

The majority of the work technically AND design-wise (for me at least) is the haptics abstraction. Our protocol is built on a system of "verbs" at the moment, i.e. "vibrate", "rotate", "stroke" (though we call it linear because it only goes one direction at a time), etc... I'm writing a larger blog post on this, but to summarize, it's REALLY hard to build a language around this that's general. For instance, the Lovense Max (a onahole style toy) has an air bladder that inflates/deflates. It's about the only thing that has that. So do I just make a new verb called "inflate"? Do I try to match it to other toys with constriction like systems and call it "constrict"? Does it even matter?

But, that's an ongoing problem. In terms of "done", I think the next big milestone will be mobile app support. We work on mobile web browsers in a couple of different ways, but Buttplug still needs app support, both native and for things like cordova/react native/etc... The biggest issue there at the moment lies in our bluetooth library (btleplug, https://github.com/deviceplug/btleplug), because getting the FFI via JNI to android is going to suck (even though I can crib off Servo's WebBluetooth impl, which worked on Android).

Otherwise, I am always really interested in ways people build for themselves that they're willing to share with others. So the answer to this question tends to be "my dream ideas are the stuff I can't possibly dream of" :)

We'll see if I get any invites. Seems like a very BLFC kinda panel.

There's a TON of financial gain to be had, and I am incredibly bad at actually harnessing that because I'm too obsessed with silly details rather than user wants/needs. But it's a balance of keeping myself happy/learning and having cash, and I'm OK enough on cash that I do this to keep myself happy and learning.

Adoption is... decent? One of the interesting parts of this is that I will really never know how many people are using it because a lot of people will take the project, implement something, but definitely not post it to somewhere like github. And really, that's fine. There are games using the library on Steam right now, a few commercial systems that use it, and I get lots of reports from independent developers doing different things with it, so that'd good enough for me.

You know I leave the in-depth yiff stories for twitter. :|

https://hapticsif.org

It’s a big forum of various companies (mine included) discussing different issues facing haptics companies. Has been around since March 2020, is a really neat place.

As for actuators, it’s either ERMs or incredibly odd things like friction/pressure systems (some with fairly off kinematics, for instance https://patreon.com/tempestvr) and electrostimulation. No LRAs yet, that’s why I’m trying to get to supporting the nintendo joycon and vr controllers, to start thinking about how signal generation should work in that context.

And yeah the top level library is incredibly generic, mostly to just get people using the library at all. I don’t know how long that’ll last, due to the complexity of actuators we’ll be dealing with, but I’ve got some strategies to grow that out a bit. Happy to go into those if you’re interested.

It's not C/C++ because I loathe C/C++, and if I never write C/C++ again, it will be too soon. The reasons for these feelings are borne out of decades of experience with them.

Of course, I'm currently an embedded engineer again at the moment, so "never" is actually "every day" unfortunately. Luckily embedded Rust is really looking good these days, and I've been using it a bit lately.

I don't really care about what other libraries do, and really, Buttplug isn't your normal "hardware driver" library. Either way, other libraries made their choices, I made mine. I hate C/C++ enough that I'd never spend my free time on it, and this is basically my back yard shed project that also happens to be a business, so it gets done with technologies I'm comfortable in.

As for exposing things, I mention that C/C++ FFI is coming in the post, mostly for Unreal Engine support. I currently have Rust exposing cdecl calls for the FFI, but it's bottlenecked to be as few calls as possible, mostly flinging protobufs back and forth because that's easy. The main thing holding up C/C++ FFI is figuring out how to translate some of the async paradigms I use to C/C++ in a way that will be generally useful.

To elaborate on the setup, it could manage four or five toys at the same time; all controlled by the nanoKontrol. I could even record custom loops and patterns for each "track" to have more fun.

:D