Hey! I was hoping to create a Raspberry Pi Zero or some such that can serve as a gateway from the GoTenna app. Assuming we got reasonable coverage of a city like Seattle with mesh nodes, such a gateway node could allow simple interactions over text to get information. A simple example to illustrate utility:
Gateway node is connected to Iridium line and can download weather data and cache it periodically.
User using the GoTenna app can add a contact “Weather Gateway” and then use simple queries like “Weather 7 day 98102” and the gateway could reply with a text forecast.
There are a large number of potentially uses for such gateways that could bridge a variety of data sources over redundant and varied data links and provide a simple interface that could be used by a large number of individuals. It seems like this is a key user journey that could dramatically improve the utility of these nodes in a disaster scenario. I was really hoping to set something like this up, but then I read this line in the readme for the SDK:
goTenna uses an App Token to differentiate between different apps on the network. Apps can only communicate with other apps that use the same App Token. This allows an app to coexist with the goTenna app, but not intermix the messages being received.
which makes it sound like every single use of the SDK creates a totally walled garden requiring a totally independent set of nodes and we won’t have the capability to interoperate between the GoTenna app that everyone uses and any SDK implementation to try and add additional features to the existing GoTenna network.
Is that correct? Would be exceedingly sad, as it suggests that this platform won’t support more heterogeneous use cases. There are plenty of off the shelf components that provide long range low power networking, but I was hoping GoTenna would provide that value add of turn-key interface for novice users.
The very first prototype goTenna hardware was built on Raspberry Pi devices, so it will definitely work as the basis for building interesting mesh devices.
Yes, that token difference has come up before. I am not a SDK user, but I suspect the difference is in part a protective feature for those who use GTMs to communicate, so that these other devices can’t affect mesh users already present.
I suspect these devices still relay over the standard mesh network, but they only talk with similar devices generating the same token. Or maybe I’m wrong about this?
Correct, when I connected to a node via the SDK and tried to send it to my other node connected to the GoTenna app, the receiving node blinked but the message wasn’t surfaced in the app.
It’s for “security” apparently. Much security. Less useful.
I wouldn’t dismiss security too lightly here, as I doubt that they’d want to make it too easy to create a jammer in this fashion.
I suspect you can build some sort of bridge between the two flavors of mesh.
Plus if it does propagate over the standard mesh network overhead, that’s still a good accomplishment in utilizing the appropriate existing infrastructure.
The constraint seems totally orthogonal to jamming concerns. It would appear (though I haven’t confirmed) that nodes relay messages even if they’re not on the same API key.
The only way to accomplish what I’ve suggested given the constraints is to share a single API key with a large number of individual developers and publish a totally independent app to the app store to support messaging on the standardized third party API key (and it didn’t necessarily sound like that was a supported use?). The result would be trying to convince everyone in Seattle to switch to a third party app full time to interact with the Seattle mesh network and a net reduction in apparent usage of GoTenna’s first party app. Just seems like a rather big todo.
Yea. The SDK seems prohibitive. A bit disheartening. Especially when seemingly a startup would want to give as many people as possible reasons to use their products.