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 flo

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