Hacker News new | past | comments | ask | show | jobs | submit login
Buttplug (Sex Toy Control Library) Hits v1 Milestone (nonpolynomial.com)
319 points by qdot76367 11 months ago | hide | past | favorite | 128 comments

How's the security of this? Do you do penetration tests?

Groan, take an upvote.

In all seriousness, many of the devices in this space are woefully insecure - this is just a library to control them using whatever native protocols they expose.

This is something I could get behind

Always a good idea to check it out for any back door access issues.at least we haven’t gotten to hot code loading being a problem yet.

I suspect that engineering of any kind has more perverse or pervertible terms than any sex toy industry.

Not saying that I take constant advantage of that on twitter, but...


This extends to physical security as well. Just a forewarning, video is three minutes of build up for only six seconds of action:


yet not something you can get on top of or ?

This is what she/he said.

Edit to add: a thread of sequential puns and then..

Related: https://internetofdon.gs/

(It's as sfw as a sex toy hacking site can be)

Yup, render has been doing amazing work for years, really helping the industry reform their security practices!

actually theres been a video from some hacking channel ,i think blackhat , where they review these and the security is ridiculously lax

on the other hand the potential damage is not that high (unless the motors could be overheated quickly)

Don't worry, it's just a plug-in

It's only a toy library.

Possibly a few wide open backdoors...

Off topic, I love that the good jokes still get upvoted on HN and it's not a bro-aehaeh-land like Reddit is.

I wonder what the difference is, maybe just a more mature audience? Nerdier jokes?

Joking on HN without being teared to pieces is AI-hard.

It's human-hard level

Speaking of sex toy security, this reminds me of one of my favorite recent posts here:

Blowjob Injection Attack - https://news.ycombinator.com/item?id=24702282

Sarah Jamie Lewis's work on privacy has been massively influential on the work I'm trying to do. I also highly recommend checking out her Oniondildonics post about metadata obfuscation in anonymous teledildonics interactions:


She's now running the Open Privacy project, which is doing great work on general anonymized communication:


That was awesome. Security is often an afterthought for many companies. Anyway, it's good that they fixed it in the end.

> When working on Buttplug applications, something that should be at the forefront of your design thinking is:

> Someone is going to fuck this.

I love this project.

Buttplug Project lead here! AMA.

Would you say that collecting all protocol specs from each individual device is where most of the work lays behind this library?

Otherwise, could you tell us about where is/was the 80% effort to build what the library does, and what would be the next 20% / last mile to consider it "done"?

Protocol specs are actually pretty easy. The protocols aren't that complicated, and there's some pretty simple ways to figure them out. It's usually an hour or two per new device, at most.

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).

"There are only two hard things in Computer Science: cache invalidation and naming things."

- Phil Karlton

I very much appreciate STPIHKAL helping me get started exploring this stuff. I'll admit that the library itself was a bit intimidating. I ended up not using it and just wrapping the protocol for the particular toys that were of interest to me in about 40 lines of JS in order to implement chrome's experimental `writeValueWithoutResponse`. I'm pleased to report has a dramatic effect on latency. I wish I could contribute back but the code is just over-my-head complicated.

This is something I'm trying to figure out how to better communicate about the project, and there will be another blog post on this soon. Buttplug is both a floor cleaner AND a dessert topping, and that can really be detrimental to the initial developer experience.

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.

Do you feel the progress of the project is hindered / benefitted / not effected by any stigmatism in western society? Do you ever find it hard to talk to friends / family / colleagues / strangers about this project?

Oh, definitely hindered, but it's kind of a network effect deal. Sex education isn't a high priority, so most people barely know sex, much less sex + tech, which is very much its own thing. That makes building technology like this extra fraught, because of the amount of thinking I have to do up front in order to try and guide things in as safe-ish a direction as possible.

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.

What you are doing is important work, not because of butt plugs, but because it is helping normalize talking about sex, and "niche sex," in the tech community (also YouPorn engineering!). Having engineers in the west be open about sex is far better than having nobody open about it.

Openness about sex really is one way to improve the health of the societal zeitgeist.

Thanks! This is why I say the project is as much social as it is technical. The technical topics are definitely important, but the project as a whole invites scrutiny not just from developers, security engineers, etc, but also from those interested in or critical of how consent and control work in technical means, what it means to be intimate over remote mediums, etc...

As an example, one of the things I was working on right before COVID-19 hit was a book chapter on digital proxemics, i.e. how we map and relate personal space in digital realms. This project and how it's been utilized to augment online intimacy was a big part of that, and I turned in the book chapter to the publisher the week COVID-19 lockdowns started to hit in the US (still no pub date tho :( ), so it's been a lot of seeing how those ideas play out in large scale since.

Hi, I commented on the last YCombinator post you did. I had created an Ethereum based library on Github for the Lovense and created the now defunct Porntoken on the Ethereum blockchain. I find that the industry is being steered away from UGC. If you look at how Visa/Mastercard cracked down on Pornhub recently, it's a big example of this. https://www.nytimes.com/2020/12/10/business/visa-mastercard-... How do you see this succeeding where UGC for adult content is headed in the other direction at this time? OnlyFans?

There's way worse stuff than being "The Buttplug Guy"! [0]

[0] https://m.youtube.com/watch?v=A85ipUgy5B4

What's the security model? Are there multiuser devices?

This is a really difficult to answer question because of the place in the stack this library inhabits. Buttplug only cares about accessing hardware, so while it may sound like a cop-out, our security model is "whatever the hardware gives us". Multi-user control systems would be built on top of the library, and that's where a good bit of the security work would happen.

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.

Technical question, why not C?

For a library that deals with hardware and aims for compatibility, C seems like the obvious choice. Most languages have C bindings, and most hardware-oriented libraries have a C interface. Rust looks like a nice language and could be used for all the internal logic, but expose C interfaces to the outside world for compatibility (I think Rust can do that).

It's not really a technical reason as much as it is personal.

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.

As someone who's working in haptics, not in the adult industry, but in VR: What are most actuators like? Are they ERM's or LRA's or even VCA's?

Your interface is pretty generic. Vibrating and rotating at a certain amplitude it seems? Are there toys out there where you can also set both amplitude and frequency?

First off, since you’re working in haptics, time to pitch the Haptics Industry Forum!


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.

What motivated you to do this? Is there some financial gain to be had? How is adoption?

I'm motivated because it's a really novel set of things to work on with the tools of technology.

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.

What are some of your dream ideas for how this one day might be used?

Seeing the uptake in VRChat has been pretty awesome. For the record, I grew up on MU*s, built the first Second Life sex toy interface in 2005, which ended up with me working at Linden, so I have a special place in my heart for virtual worlds.

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" :)

Any plans to do a panel on sex toy development at post-covid furry cons?

God, it's been a while, hasn't it?

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

Favorite toy? :)

How much good sex has this project lead to you having? :)

Damnit Egypt, stop embarrassing me in front of the VCs!

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

Or for getting drunk at a con. If those ever happen again.

This reminds me of a story an industrial designer told me: he worked on a dildo with a scripting system, so the ladies could set the number of milliseconds for each waveform profile on the haptic motor. The product was not a success.

Yup! Interfaces have been a problem in the industry going back decades. See me getting excited about a similar product that catastrophically failed back in 2006 (when I was a young, far less experienced engineer :D ):


Presenting something like this library directly to the user will end up in product death. What I'm building is a tool for developers to refine that end product interface specifically so the user (who is usually horny and does not care about technological details) can have something they can work while in that state.

But it's gonna take a while to get there.

I looked into doing something like in the early 2000s, bit found that my idea would take more power I was comfortable to be able to provide in such spaces.

Reminds me of an episode of MST3K where they played a '50s beer documentary that went in depth into all the science and engineering behind keeping the beer cold between the brewery and the store. Then one of the robots pops up and says - "Meanwhile, the Soviets were developing Sputnik."

Are you thinking of "As You Like It"? If so it's also available from rifftrax.com.

I played a bit last year building my own sex toy controller, using a lightweight RPi Zero, an Erlang server, and a nanoKONTROL2 controller. It was quite fun and I hope to find some time soon to resume working on it :-) Bluetooth isn't a fun protocol to deal with, tho.

Oh that's awesome! Sounds like a real cool setup. :D

We do have our CLI server compiling for RPi0W if you're interested, though I need to update that soon. This is well into the "no so documented" part of the project tho, so it's not super easy to use yet.


I decided to go custom because I love writing code, but thanks a lot for buttplug and its documentation: it's how I managed to get my code to work with Lovense's products. I'll surely try to give a shot at using Buttplug one of theses days :).

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.

Great to hear you got something working, and glad I could at least provide some implementations to follow. :D

Yeah, 4-5 toys sounds about right. I've managed to get 6 running simultaneously on one radio (BTLE spec I believe says 2 at most?), but there was massive dropout.

I checked the webpage and i must say that i am totally confused. First, it says buttplug is a library. Then, in architecture overview there are 'protocol' and 'client/server', which does not make sense for a library. So it is not a library, but a deamon handling these devices? Wh then call it library? If it is a deamon, is there any user configuration? Am i only one who is totally confused?

Perhaps some picture with components and relations between them would be helpful?

Hold on, someone wrote a general library for sex toys, of many different types, and named it after a specific type of sex toy? This seems unhelpful.

Never let engineers do their own branding.

But there's some explanation too:


...I don't know, might be fun if they ran a stripped down Pop! Distro.

> This list will also continue to grow over time, as I try and convince myself this was a good branding choice.


Hackernews always implodes at the mention of sex

We never got desktop Linux, but 2021 will be the year of open source kinkware.

> 2013 - First Python implementation, known as “Fuck Everything”.

Amazing. Nice to see people dedicated to the fine arts of buttplug manipulation.

Just FYI:

> August 2017 - Kyle incorperates Nonpolynomial

Someday I will learn to spell incorporates.

But yes I do run a startup on this software! Mostly for consulting for larger product manufacturers, though there may be some services work happening in the future. I've been poking at some ideas around containerizing teledildonics services, but there's a whole host of social and legal issues around the idea that will take a while to iron out.

If you have the time, mind detailing some of the legal issues?

The biggest one for me is information storage and transmission. People want repeatable interfaces, which means it'd be nice if they have an account, but how much information should I hold about that user in relation to their usage of a teledildonics service? My work exists in a very odd gray area that's not quite porn, so under SESTA/FOSTA and the upcoming SISEA, I'd have to figure out what I am/am not liable for.

Being a single developer project that's open source but also a company and yet I already have multiple lawyers, I really can't afford to be a test case for that.

What happened with python support? Is it coming back or just dropped?

> 2013 - First Python implementation, known as “Fuck Everything”.

> Buttplug v1.0.0 is available in the following flavors:

> Rust – Crates.io, Github

> C# – Nuget, Github

> JS/Typescript (via WASM, Web-only currently) – NPM, Github

Oh sorry yeah that’s not super clear in that explanation. There’s a “buttplug” package on pypi (see also https://github.com/buttplugio/buttplug-py) now that can be used to access an external server (like intiface desktop: https://intiface.com/desktop) but the plan is to make direct links to the rust library to give things more flexibility. That’ll hopefully be done in the next month or two.

Is manual fallback the only option in the case of a unrecoverable exception?

Turns out that rust's "panic" has a completely different context when applied to this context. :|

The equivalent of a safe word, I'd suppose.

Looks like the Github is here: https://github.com/buttplugio

I expect we'll see some interesting issues posted there eventually

A sixteen year quest! Amazing!

Will there be support for iOS?

Working on it!

Technically I think btleplug might already work for iOS (I haven't tested this but I've heard the corebluetooth calls stay the same?), and I've gotten the library to compile for iPhone, but I still need to build Swift FFI bindings.

The web version currently "works" via the WebBLE browser that's a available in the app store, which is just the webview polyfilled for WebBluetooth: https://apps.apple.com/us/app/webble/id1193531073

But I wouldn't call that a great experience.

The hope is to support both android and iOS for apps soon though!

Would Apple allow it in the App Store?

Sure. Lovense, kiiroo, and other major toy manufacturers all host apps in the store. Xtoys is on there too.

Just don’t call the app “buttplug”. :)


I was curious and tried working with this an a device about a year ago and the whole thing felt like a mess. There are browser components, electron cancer, web-to-bluetooth pieces. I think I could get my device to register/pair but couldn't get anything past that.

I was looking through the docs and the only useful thing seemed to be the low-level code if I wanted o make my own applications on top of it.

The reverse engineering work is important, but the tooling/UI needed work. I actually want to contribute to this to help, but it's a bit far down on the backlog of life.

Yup, the way I'm trying to do things definitely may not be right for everyone, and that's fine! That's why the reverse engineering work is documented (https://stpihkal.docs.buttplug.io, but also check the github repo because I am years behind on updates based on issues now), so if people want to pick up protocols and try their own thing, they absolutely can. I want to learn from other people approaches to this too.

In fact, that's exactly what xtoys has done:


They're just using the reversed protocols my project documented, while building outside of my admittedly complicated library interface. It's been a great project to watch grow, because while I'm kinda hyperfocused on platform and hardware support, they're going breadth-first with user focused features on a WebRTC platform.

What's wrong with web to bluetooth or web browser components? Electron is pretty standard for user facing cross platform UI. This is a sort of application that has the right to use more resources - because if you're 'vibin' I don't imagine you're really needing that other 150MB to run minecraft modpacks. Perhaps if you're in VR and only have 8GB of ram.

You have to hone your expectations for free projects. Native or native-like UI toolkits are expensive on time. Time is the biggest problem with making free software for people. Now if this were a commercial product - yes I agree with the criticism. There's no reason at that point that they couldn't do GTK3, QT, flutter, etc.

Depends on the minecraft modpack ( ͡° ͜ʖ ͡°)


But I don't want to cure cancer.

I want to turn people into dinosaurs.


Damn the preparation is astounding! Hats off to you sir, your work is banging

Hashtag #Scalies?

You might want to read up on 'Fallacy of Relative Privation' to see why this point of view is likely to not be helpful. A good starting point is this[0].

[0] https://academy4sc.org/topic/fallacy-of-relative-privation-a...

You think 'The Fallacy of Relative Privation' is bad? What about the 'tu quoque' fallacy. Wouldn't you consider that a bigger problem?

Brings a whole new meaning to the term “plug-and-play”. Sorry, couldn’t resist.

I want to submit bad code to the open source project just so I can say to someone "What's the matter with you, got a bug up your ass?!"

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact