For sure. Do we know what the wheel currently looks like, and if it fits the potential use-case? It would be cool to see an example without having to build a node. The scope of CATAN is not 100% clear to me, and this 2015 paper linked from their github hints that one-to-one communications isn’t an objective:
II. NEEDS ANDASSUMPTIONS
Disasters that require HADR response often experience infrastructure outages that destabilize the communication environment. These outages hinder collaborative command and control across all participating response agencies and impair the ability to collect, process, and distribute accurate information from disparate systems and platforms [16] in a timely manner. Understanding and designing for these conditions is paramount to the success of any technology.
[…]
The implementation of existing standards and technologies to support interoperability has enabled multi-organization collaboration and the support for diverse CONOPS. We emphasize that communication interoperability is critical for HADR because of the large number of organizations that are often involved in disaster response.
One of the things about the disaster.radio project which looked incomplete was the web-based chat. If I remember correctly, the implementation was one-to-many. I don’t want to incorrectly assume the CATAN vision is identical, but disaster-focused projects tend to be structured in a way that they wouldn’t get used outside of disaster scenarios. That makes sense for their use-case, but it limits the potential of GTM.
Not sure the exact state of the CATAN project’s web app today, but it would be good to know if this has progressed since 2015:
VI. FUTUREWORK
While CATAN fulfills our initial design goals, we have since identified some potential directions for future development. For example, photographs have been shown to be invaluable for data sharing applications. We hope to add more photograph functionality to our system (e.g., Snapshot [43],image recognition), while remaining cognizant of both our computational and bandwidth constraints. Similarly, our web-based interface only offers limited access to the user (i.e.users only “pull” information). We are advocating for an application store that will enable users to download native applications, capable of providing a more seamless and responsive experience (e.g., “push” notifications). Finally, we hope to continue maturing our network protocols to simplify the mesh network configuration and minimize the interaction required when bootstrapping a new node.
If that’s where they left it, there may be a lot more dev to this than plugging in GTM on the backhaul.
At first glance, CATAN and disaster.radio both use WiFi for local connections. CATAN uses WiFi for the backhaul mesh, whereas disaster.radio uses LoRa for the mesh. CATAN uses RPi for the controller, and I think disaster.radio was using ESP8266. The plus for CATAN would seem to be that Python, and therefore the current GTM SDK, plays more nicely with RPi than Python on Arduino. Disaster.radio would probably get the check mark as far as lower power consumption. Of course it’s not a CATAN vs. disaster.radio question if the latter won’t fly with the SDK. The main reason I brought it up was because the disaster.radio YouTube channel shows the web interface of their prototype.
I realize my guarded optimism will probably read as negativity. Hopefully it’s just pragmatic skepticism after seeing nearly all open-source mesh projects orphaned before they get solid traction. I really do like the concept, and think it would be cool to see it move forward. While a web app is great for a number of reasons, I also like that they’ve started work on an Android app.