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.
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:
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).
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?
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.
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?
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.
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.
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" :)
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.
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."
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?
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.
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.
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.
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!
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.
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.
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].
Aw man, you are going to be so mad when you find out the % of software developer effort that goes into adtech and entertainment.
Because I guarantee you, for every developer working on a sex toy there a thousand working on selling lootboxes to 12 year olds, and ten thousand working on showing adverts to people who'd rather not see them.
I think the reason you’re getting downvoted is pretty much that you’re trying to impose your ideals on others. Some people likely benefit from this library. Some people benefit from the latest video game. If we were all working on curing cancer, the sad truth is that there wouldn’t be very many fun things in life.
If we all worked on things as important as curing cancer, we could build god and live happily forever. Whichever generation manages this will 'win'.
(Or they build a paperclipper and ruin the lightcone.)
I imagine they said the same thing about trying to find something to kill scary things that get into our bodies and kill us from easy-to-die-to diseases.
I see the world has not built god and lived happily, forever, after antibiotics were discovered and used. Something else that's horrible will come along and human tendencies will still prevail and exploit others.
Modus tollens, modus ponens; my quality of life is vastly improved by not dying of smallpox and equivalent improvements to the world would be very valuable. I think going back to a situation with smallpox would be a big decrease, so that argues against things not really getting better.
Building god's just the end-example, even if you never get there you can keep making things better.
(I should say that by "build god" I just mean build a friendly AI, i.e. automate science. If that's impossible, just try and do what it would do.)
(Hard to enjoy your sex toys when you're coughing your lungs out!)
I have no real opinion on the project in question but devotion is not a fungible, generically applicable resource you decide to apply to one issue or another. Run a test for whatever "IQ/g-factor/ability" handwave you're referencing on someone that loves their work and someone that doesn't.
I can not help but detect a condescending tone in your comments (if such is not the case, my apologies – Poe's Law and all) and find it interesting that you have not provided sources to the "research" which your claims are based on.
I think it would benefit everybody if you could share a couple of links to some "research".
Are sex toys alone actually fulfilling to most people? Given the number of people on thw internet complaining about misery from sexual loneliness, it clearly isn't enough.
Sex toys, porn, and enculturing cowardice stave off the war, I guess. You just get Elliot Roger instead.
Did you know that couples can and do use sex toys? There's a whole industry for it!
And, with long-distance relationships, smart sex-toys can facilitate the more intimate times in a more fulfilling way than standard phone or type-sex.
A loving and committed couple could, while apart due to, perhaps, a conference or business trip or anything else, enjoy the company of one-another in that way perfectly well.
And what do you think about people who develop their own AI anime girlfriend? Even sharing their work as free software libraries?
In your wording it only looks like it is the exploitation of people by businessmen selling the happiness as a product, whereas it can actually be the user themselves developing it for their purposes (like when it's opensource, hackable, or even DIY, etc).
I'm a lot more sympathetic to someone who manufactures their own drugs for personal consumption, yes, but only because the difficulty involved means you need a minimum of discipline to get there which would hopefully meliorate the negative effects of the habit. It's in the same vein as writing games being more virtuous (to yourself) than playing them.
Anyway, my vision of the future is hundreds of millions of obese NEETS who spend their entire monthly UBI check on overpriced insect-protein food, clothing, video, porn and AI girlfriend-as-a-service products. Pigs at the trough, given just enough slop that they don't kill themselves, while the people who can resist temptation (say, helped along by their upbringing) get to be human.
I think that all your objections boil down to "instant gratification does not harness the brain's reward system as a motivation to achieve difficult things and improve general intellectual/physical/social abilities".
It is true, but somewhat orthogonal to other problems such as how to reach happiness. As an intellectual leaning person, I tend (like you) to link my own happiness to greater ability of my mind, but that is absolutely not generalizable. For some other people, the notion is true but only regarding "to improve physical abilities", and they don't care about the other parameters. etc.
Moreover, the highlighted problem of instant gratification thus applies not only to sexual needs, but also to feeding needs, for example. It would be interesting to compare foraging/hunting societies with ours in this regard.
The connectedness of the new generation of toys, combined with worlds such as VRChat, are contributing to make the loneliness of "not skin-to-skin sex" a thing of the past.
Also you start to see (unmanned) virtual characters sophisticated enough to trigger emotions of love, and in some case commitment. It is clearly still extreme and a bit too early, but in the near future I can see people becoming really in fond of their virtual AI character partner.
We agree that not only immediate endorphins levels, but also mid and long term serotonin levels, are important for happiness, and I think that this connected tech is helping in the right way.
And, I'm not personally building any of this, it just already exists, and some people are enjoying it.
Heck, it is even being developed and hacked by the users themselves, when it is hackable, like in this very HN post.
Sounds like you just want everybody to be happy only your way...
Even without this kind of tech, the paths for happiness are probably beyond everything your little window of a mind can imagine.
PS: it looks like somebody has called their local church's friends to retaliate on this how unholly HN thread, and they come up here and create new accounts and answer my comments without even realizing that I am not the OP...
I know someone who takes it on a daily basis. You would not be able to tell that he uses. It makes him productive (he works in IT), he takes it to combat anxiety and depression. It works for him. He voluntarily goes through withdrawal occasionally so he will not have to increase the dose. He is in a healthy relationship, and so forth. He might be an exception, I do not know.
All the side-effects are a result from the War on Drugs: not knowing the purity of the batch, adultered products, and so forth. This is why accidental overdoses happen. This is why it is bad for your health for the most part, because God knows with what it is mixed. Intentional overdoses happen too, but that happens with OTC medications, too, so heroin is not so special in that regard.
Thanks, yes that's true that if the {legal, moral, medical} context was better most of the problem would be gone. People able to workaround the difficulties of this drug may well be fine.
My point was that, in the current context, the use or heroin is hazardous -- in our current society, for most people -- which is not the case for virtual sex and related toys (if not horribly dysfunctional).
Yeah, he does not use it for recreational purposes or escapism, so I believe that changes a lot. He has been doing it for years without any side-effects. He had MRI, blood tests, and so on. Everything's good.
I do not know much about virtual sex. What are the possibilities and limitations of virtual sex today?
You mention "horribly dysfunctional" further down. That's what I have a problem with.
I see these cardboard sex-simulacra trapping, for example, young men in local optima where they never go and talk to a real girl- even young men who could, if they tried, and who'd be happier in the end for it.
Anything that increases the number of incels in the world is a bad thing, for everyone.
