Let me be perfectly blunt. This idea won't work, because Bluetooth is an atrocious protocol. If it would work, a native app would have successfully implemented it, and taken the world by storm.

The problem isn't accessibility to JavaScript developers. The problem is a crummy radio protocol. Putting it inside Firefox doesn't solve bad design issues.

Thank you, that's valid criticism.

While bandwidth for Bluetooth is not great, it'll work for small amount of information exchange and at the very least discovery of other methods for communication like ad-hoc wifi.

I'd be happy to hear about more details why Bluetooth is crummy as well.

1. You need exact timing between devices for the freq hopping to get to the right freq

If for some reason the OFDM ack isn't gotten, then neither side can understand the timings to actually communicate. So you end up with non-pairing hell. This especially happens between different "specs" of BT.

2. Raises noise floor for whole BT carveout

If they had 2 control channels, and then moved the comms to an agreed upon channel, this would never be an issue. Look at how Simplex ham radio works - do announce on a channel, and move elsewhere when agreed upon. But whatever you do, don't just blanket the whole channel (or all of 2m) for 'reasons'. And heavier bandwidth BT can take over multiple channels. This isn't easy, but nowhere near as difficult/stupid as what it is now.

3. Multiple incompatible BT specs

BT used to be a IEEE spec. Not any more. And there's more than 7 or so major versions. Oh, and many are incompatible with each other. What's that XKCD about "Standards"? :(

4. arcane pairing sequences

Again, pairing is crazy complex. I'll have to post the actual IQ data and show a comparison between FM (88MHz-108MHz), 2m amateur radio (144MHz-148MHz), analog TV, 802.11BGN wifi, and what BT looks like in various states.

To sum it up, "They're doing it wrong".

Actually, from 1.0 and on, bt specwriters did everything to balance the complexity of implementing bt in silicon with protocol's performance.

Fragile OFDM? Any other rock solid narrowband interference mitigation techniques that are not electronically complex?

No dedicated control channel? Remember, BT just like wifi implies operation along non-cooperative 3rd parties.

> This idea won't work, because Bluetooth is an atrocious protocol.

I would agree.

I was at our hackerspace last night working with a SDR transceiver ADALM-Pluto and tuned in to the 2.4 802.11bgn spectrum. Its a clean swath of radio for comms. Its easy to establish a connection. And the bandwidth graph is cleanly edged.

Then I look at the Bluetooth part of 2.4GHz... Holy crap. Each device frequency hops like a rabid rabbit. And when you look for a device, over the radio it looks like its just dumping beacons everywhere in the hopes that something responds.

Just viewing a device with bt connected, and looking for a device makes it clear that their scheme of BT is -bad-. Its a bad protocol, bad detection strategy, and bad usage of spectrum (yay raise noise floor for everyone).

>> In fact, no one has ever said "I wish I could use Bluetooth in my browser"

> I literally just wrote above that I do want that. I also don't care about collecting any data.

I believe you, but frankly, most of the society doesn't want to build mesh apps and (hopefully...) finally started to care about their privacy and data, and that's the point.

I'm not sure which society you are referring to specifically. The one I'm most familiar with (Catalunya) don't really care how things happen, as long as they can get communication access to each other that is not controlled by a government entity. Mesh networks is just one way to achieve this.

But in the end, always good to have choices so the ones that happy with what they have, can always stay that way.