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.