MOModernMech·Sep 21, 2025
Oh so you're the reason we got btleplug!:P
https://github.com/deviceplug/btleplug
fwiw the downloads are probably automated crates.io indexers.
In The bloat of edge-case first librariesdeviceplug
btleplug
Rust2020–2025
deviceplug / btleplug
btleplug
Rust Cross-Platform Host-Side Bluetooth LE Access Library
4Distinct people
7Mentions
1Explicit recommenders
1.2KGitHub stars
What to know before exploring
What it is
Rust Cross-Platform Host-Side Bluetooth LE Access Library
GitHub
Where it is used
No documented product use has been verified yet.
What people are saying
I've always been annoyed at the cross-platform story for Bluetooth. GATT is one of my favorite protocols because it is so simple, but writing simple code against this simple…
conradev used a recommendation phrase. One indexed comment matches. This is a phrase match, not a verdict.
No classified warning is attached to this page. Read the discussions before treating silence as approval.
Also in these discussions
No other repository is repeatedly linked in the same discussions.
This week on Hacker News
Nov 7–Nov 14 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/14/2026, 11:56:56 AM UTC.
No direct repository links were found in the indexed HN discussions over the past seven days. Older discussions are available below.
Mentions over time
HN mentions by year7 dated mentions
Observed mentions: 2020-05-06 19:59:25 UTC to 2025-09-21 15:27:44 UTC.
Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.
View mention counts and date ranges
| Period | Start (UTC) | End (exclusive, UTC) | Mentions | Submissions | Comments |
|---|---|---|---|---|---|
| 2020 | 2020-01-01 00:00:00 UTC | 2021-01-01 00:00:00 UTC | 2 | 0 | 2 |
| 2021 | 2021-01-01 00:00:00 UTC | 2022-01-01 00:00:00 UTC | 2 | 0 | 2 |
| 2022 | 2022-01-01 00:00:00 UTC | 2023-01-01 00:00:00 UTC | 1 | 0 | 1 |
| 2023 | 2023-01-01 00:00:00 UTC | 2024-01-01 00:00:00 UTC | 0 | 0 | 0 |
| 2024 | 2024-01-01 00:00:00 UTC | 2025-01-01 00:00:00 UTC | 1 | 0 | 1 |
| 2025 | 2025-01-01 00:00:00 UTC | 2026-01-01 00:00:00 UTC | 1 | 0 | 1 |
What Hacker News says
7 sourcesYou're absolutely correct! I mention this elsewhere in the documentation even. Buttplug really is just a userland HID manager at its core. The only specialized part is the context of commands we send to devices.
The original plan (and it may still happen, who knows) was to figure out a way to chop off that top message layer and create a generalized system for doing exactly what you've said. That was going to be called 'deviceplug', and it's why btleplug is under the 'deviceplug' org on github (https://github.com/deviceplug/btleplug). I've just never gotten around to it because I'm not quite ready for the additional support burden yet.
All that said, Buttplug is also a haptics experimentation project aimed at finding out what it's like to create a way to communicate about a very specific type of touch via technology and programming. There
Read the rest
are specific goals within the project related to that, but the amount of tech required to actually pull that off means I end up with what basically amounts of a fleet management framework. :)
I'm currently writing Rust for my bachelor thesis using bluez_async[1].
btleplug[2] is great, but at least on Linux I prefer using bluez_async directly, which btleplug is just an interface for there[3], to avoid one more layer of dependencies.
bluez_async is quite similar to btleplug, and, from my experience, if you know one you can use the other just fine.
[1]: https://docs.rs/bluez-async/0.6.0/bluez_async/index.html
[2]: https://docs.rs/btleplug/0.10.4/btleplug/index.html
[3]: https://github.com/deviceplug/btleplug/blob/d6d8ba5486eba5d7...
In Show HN: Hacking Bluetooth to brew coffee in GitHub actionsOne of the worst/best parts of buttplug is that I ended up needed to maintain my own Bluetooth LE library: btleplug (https://github.com/deviceplug/btleplug).
Worst because working with bluetooth is always THE WORST, best because of the submissions and community that've grown around it.
There's 2 types of PRs to btleplug:
- People going "here's a PR but uh, why is the library named btleplWAIT WHAT"
- People going "here is a PR specifically to fix something in Buttplug thank you"
In Deldo is a sex toy control and teledildonics mode for EmacsI've always been annoyed at the cross-platform story for Bluetooth. GATT is one of my favorite protocols because it is so simple, but writing simple code against this simple protocol is _not_ portable:
iOS and macOS have CoreBluetooth, Linux has BlueZ, Windows has Windows.Devices.Bluetooth and Android has android.bluetooth.
I've seen a few projects trying to fix this, like https://github.com/deviceplug/btleplug, and I hope one of them becomes production ready.
In Android's new Bluetooth stack rewrite (Gabeldorsh) is written with RustProtocol 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 bla
Read the rest
dder 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 have been a few (tried Trello and ZenHub), and they've all turned into a mess, so I recently hit the reset button again and am just trying a github project now:
https://github.com/orgs/buttplugio/projects/1
tl;dr - Right now I'm trying to standardize our logic on Rust (I'm also the ex-device interfaces lead on firefox at Mozilla, so I love some rust :) ), then extend back out to other languages and platforms through FFI to the Rust base.
The Rust work has also ended up creating other libraries, including:
- systray, a library for building simple systray apps with rust: https://github.com/qdot/systray-rs
- btleplug, a cross-platform host side Bluetooth LE library in Rust, mostly via copypasta but hoping to unify soon: https://github.com/deviceplug/btleplug
In the end, Buttplug is just a hardware abstraction layer, think of it like th
Read the rest
e USB HID or Bluetooth Profile model, except outside of the protocol specification space. I'd like to abstract the back end a bit more and allow other projects to use it, so you could have, say, a library that abstracts health device protocols or something.