6 ms·
Buttplug Project lead here! AMA.
by qdot76367 6y ago
Buttplug Project lead here! AMA.
- lordnacho 6y agoWhat's the security model? Are there multiuser devices?
- qdot76367 6y agoThis 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.
- codefined 6y agoDo 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?
- qdot76367 6y agoOh, 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.
- giantrobot 6y agoThere's way worse stuff than being "The Buttplug Guy"! [0] [0] https://m.youtube.com/watch?v=A85ipUgy5B4 https://m.youtube.com/watch?v=A85ipUgy5B4
- zamalek 6y agoWhat 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.
- qdot76367 6y agoThanks! 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.
- cdnpal 6y agoHi, 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-block-pornhub.html 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?
- deleted 6y ago[deleted]
- errantspark 6y agoI 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.
- qdot76367 6y agoThis 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 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.
- j1elo 6y agoWould 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"?
- qdot76367 6y agoProtocol 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 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).
- Corrado 6y ago"There are only two hard things in Computer Science: cache invalidation and naming things." - Phil Karlton
- raldi 6y agoWhat are some of your dream ideas for how this one day might be used?
- qdot76367 6y agoSeeing 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" :)
- mkr-hn 6y agoAny plans to do a panel on sex toy development at post-covid furry cons?
- qdot76367 6y agoGod, it's been a while, hasn't it? We'll see if I get any invites. Seems like a very BLFC kinda panel.
- joelbluminator 6y agoWhat motivated you to do this? Is there some financial gain to be had? How is adoption?
- qdot76367 6y agoI'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.
- egypturnash 6y agoHow much good sex has this project lead to you having? :)
- qdot76367 6y agoDamnit Egypt, stop embarrassing me in front of the VCs! You know I leave the in-depth yiff stories for twitter. :|
- egypturnash 6y agoOr for getting drunk at a con. If those ever happen again.
- mrwoggle 6y agoAs 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?
- qdot76367 6y agoFirst off, since you’re working in haptics, time to pitch the Haptics Industry Forum! https://hapticsif.org 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 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.
- GuB-42 6y agoTechnical 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).
- qdot76367 6y agoIt'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.
- ghosty-discord 6y agoAre you Australian?
- herbst 6y agoFavorite toy? :)