There are various 6-to-4 technologies and tunnels, presumably they use one of those in conjunction with 6lowpan or similar. I'm guessing the radio side uses the old analogue TV bands, because the whole thing sounds very similar to the "Weightless" whitespace radio system.

Not using 6low. All frequencies we use are unlicensed spectrum.

api. all good questions.

1) The IPv6 ends at helium's routing network. So, to and from the bridge can be ipv6 or ipv4. The devices ipv6 addresses live on the helium edge routers themselves. I think on our website it's a graphic that says "platform".

2) You are close. The devices are a custom protocol (no tcp/ip or udp at the device). 802.15.4 frames.

3) replace cloud-db with a distributed system that your programs and helium's programs can subscribe to, and send and receive data to helium devices or groups of device.. You will be able to communicate to the helium network, the same way our fusion application does.

Does your protocol do any NAT traversal if the bridge is stuck on an IPv4 network or behind a firewall that doesn't allow inbound? Like if I have two bridges, will traffic go point to point between them or does it have to visit Helium's servers?

Also I'm curious about this distributed system. Is it based on a DHT, a meshnet protocol, some kind of distributed database, or something else? Or is it something simpler than that that lives in the cloud?

I guess I'm wondering if you've gone into the realm of truly decentralized networking or whether this is a cloud-based service.