Hello Lemmy,
I am the author of bluetuith, an open-source TUI-based bluetooth manager for Linux only. I have been working on this project for over 2 years on and off, and I was wondering about extending support to other platforms as well.
To begin with, the Bluetooth Classic (BR/EDR) implementation on Linux is fairly standardized (via bluez APIs), but on other platforms, especially windows, Bluetooth APIs are finicky, and tricky to deal with, and also there is no standardized management in general.
I would like to start creating a centralized Bluetooth server or a daemon for other platforms (natively maybe), mainly Windows and Linux, which can expose relevant APIs so that clients can use them to handle Bluetooth-based operations. I know this is quite an uphill task, but I would like suggestions on how to implement it, or if anyone has a better idea, please do suggest that as well.
To summarize, my current plan is this:
- Create bluetooth servers natively for each platform, utilizing the platform’s proven APIs to handle bluetooth-based functions and expose a standard API to clients
- Adapt clients to use said APIs provided by the daemons to allow the user to control bluetooth in general.
For the server implementation (mainly to other platforms), I will require contributors, so contributors are highly welcome to be involved in the project. I am in the process of securing an NLnet grant to invest into this project and mainly pay contributors to implement this platform-wise (the proposal has been accepted, and the negotiation call will be hosted in a few weeks, more details about this can be further published if anyone has questions about this. If contributors are confirmed, maybe the budget could be adjusted as well).
I apologize if the post is naive or does not fit this community’s guidelines, and if it doesn’t, a comment on where to redirect this question would be great.
Constructive feedback is appreciated. Thank you.
Note: By Bluetooth operations, I mainly mean Bluetooth Classic based operations.
I currently use and love bluetuith! I hope you are able to secure funding and contributors, as this sounds like it could be a great development.
Chiming in, pinephone homies love this ish. Thanks homie
Better go with cross-platform in the sense of other unixes and maybe mac.
Windows is a different beast.
Windows is indeed a different beast, which is why I am looking for contributors. For Linux it can be done, but since I don’t have a macOS based device, I cannot work on a macOS based implementation.
There is nothing preventing you from BSDs , tho
While contributing is great, the BSDs are kinda dying and it’s probably better to spend that effort elsewhere. Even TrueNAS is leaving the BSD space. The fact that most applications are shipping via docker/Flatpak/snap etc. and that BSD does not have a good solution for those does not bode well for BSD.
There just really isn’t that much development for BSD anymore. Everyone who wasn’t on Linux is moving over to it.
I have been looking for some client tool to interact with Bluetooth on windows. After a lot of searching, I came up empty so I bit the bullet and decided to code one myself and managed to create a small command line utility using C# .Net and it was surprisingly easy. It would have been so awesome if something like bluetuith had existed for windows so I’d be happy to contribute. I should point out though that I have not written any windows based app/tool ever and this was the first one so I would definitely have some learning and research to do. I mainly use a Mac for work and personal stuff so I can contribute for the Mac portion of it as well if required. As to the implementation itself, would it be viable to use something like rust which already has cross platform support so that the server component can just be a single codebase instead of platform specific?
I would like to be involved in the development as much as I can, but I cannot work on rust since I have no experience with it, unlike with Go and Java (a little). Also, cross-platform libraries tend to have more limitations and caveats as to what is implemented and usable. But please, do link the rust library here so I can check it out.
I think platform specific binaries is the way due to more flexibility, although we can debate about that. My objectives are to provide a standard API for any bluetooth client to use, and to retain bluetuith’s existing features. If you are willing to contribute to the MacOS part of it, it would be great, and we can have further discussions via DM.
I just mentioned rust as that was the first thing that came to my mind. I’ve not worked with it either. I am ok to take whatever direction you think is appropriate for the product. I just want to contribute to the tool since I was also looking for something like this in the past and I can see this tool being useful for me for my own personal projects. I can definitely help with the macos part if that’s what you need help in. Please feel free to DM me.
Absolutely love the name.
I’ve been looking for a TUI application. Ma man!
Do you already known about https://doc.qt.io/qt-6/qtbluetooth-index.html? That should give you cross-platform Bluetooth access with a single API.
Yes, I am already considering it, but it has various limitations, which I would like to avoid.
Is it true the Bluetooth network stack is larger than the WiFi network stack? If so, why? I don’t know much about BT besides pairing, allowing calls and audio in/out, transferring files, and… is there more? It takes a day of reading documentation to understand all the advanced options on my ASUS router interface, and that’s without anything proprietary.
I’m just surprised and curious and never got a satisfying answer.
It’s not about the size of the stacks IMO, the Bluetooth stack is notoriously difficult to interact with since the implementation varies wildly across different platforms and maybe architectures, and communicating with those different stacks is difficult, in a way. And within each stack you may find many features that are sparsely or not documented at all.
Just saying, but if it were easy, cross-platform libraries would have been developed long ago, but to this day most libraries have implementations where some functions are either finicky or not implemented. In no way am I trying to criticize the authors of those libraries, IMO it is a commendable achievement that they have understood the standard and the different stacks and have attempted make it cross-platform friendly and easy-to-use, but that’s just the state of Bluetooth these days.
That does go a long way towards explaining why there are so many Bluetooth vulnerabilities, thanks for the info. Looking at the list of Bluetooth protocols wiki page gives me a headache. Surely there is a better standard, and I see things like HaLow, ZigBee, Z-Wave and other custom protocols, but it seems like there should be a very cleanly well-documented alternative to do the basics that everyone expects BT to do. This, coming from a total noob, speaking completely out of my anus. I just know that as a BT user, it’s a crapshoot whether there will be major audio delay, and pause/play actually worked, that’s if pairing works in the first place. But if something did come along I wonder if there would even be adoption among consumer devices.
