Okay, so from my understanding the limit on 6 “hops” is a firmware problem, in that it becomes unstable going much further due to congestion and the way in which the network decides how to route messages from one device to another to reach a final destination. So, would it be frowned upon to utilize a separate device to relay messages from one GTM to another GTM to bridge from one max set of 6 hops to another set of 6 hops, thus enabling a hypothetical 12 (or 11 I suppose since 2 units are basically 1 unit in the setup)? Obviously in order to use this with the built in messaging system rather than a custom application that merely uses the same network to relay messages, we’d need to direct messages to the bridge device so that that receives it, rather than the linked receiving GTM just trying to relay it along, so basically I’m proposing (early concept)…
Android device, 2 GTMs. 2 instances of the app. 2 remote users out of range of each other. In range with the bridge.
User A sends messages formatted something like “TARGET:USER_B\Hello from afar!” With BRIDGE as the recipient. Upon receipt, BRIDGE reads, parses the message, and sends a new message “ORIGIN:USER_A\Hello from afar!” With User B as the recipient. User B gets the message “Hello from afar!” from User A in the custom interface.
Personally, I think it’s a great idea. In order to circumvent the instability issues, and to extend relay range, only potential issue is the fact that bridge units would be able to see anything that passes through them and potentially alter it. However I’m not entirely convinced that it’s impossible for any existing relay in a chain to see the contents of a message. I’m not familiar with what sort of encryption the system uses though. Anyone have knowledge of that?
Anyone with objections to my idea or other thoughts or anything? My android device relay is just a first idea because I think it would be easiest to implement, long term a setup would probably be better suited with a traditional desktop Linux or (maybe) Windows setup.