konsumer

It works great with lora, but each interface is it's own thing. It's not exactly like meshtastic/meshcore/etc (for better or worse) but also fulfills totally different roles. You can connect 1 interface to another, and only forward messages for particular addresses, if you want, or addresses that have announced on a specific interface, and you can control what you want to propagate/route.

You can set it up tons of different ways, so just imagine this is what you want:

- 20 ESP32 lora devices around my house, that respond with sensor-data or something - a pizero connected to the internet (via a huge TCP testnet) and lora (via a SPI device connected to some GPIO.) - These are not "secret" anyone can ask a sensor for it's data. the messages are encrypted, but they are intentionally public

If any of the 20 lora devices want to to be available to talk to someone on the internet, they can, and their announcements are forwarded, so people on the testnet know the address.

I can set it up so only messages directly to those 20 devices is forwarded, but otherwise announces are recorded (and replayed) on the pi.

Additionally, I can setup propagation for just my 20 devices, so even if they are out of range or turned off, they will get the message (from the pi) when they get back in range or turn on.

In this example, the structure of the network forms a kind of tree-like thing. Each tier of the network is scaled to the amount of traffic it can deal with: pi can deal with a ton, and is connected to internet, the ESP32s only need to deal with 1-to-1 traffic (announces don't really matter to them) and only compete with traffic from 20 devices (on the same lora network.)

These messages are pretty small (an announce is ~160 bytes, message proof is ~115 bytes.) For larger messages, you string them together over a link (a 1-to-1 encrypted tunnel.) I think a key thing though, is that not every tier of the network needs to send all the same packets. For example, not even 1000th of the "testnet firehose" gets sent over the local lora net of 20 devices, based on how it's setup here.

So, the usage-flow of this would like this:

- each sensor announces on lora, pi forwards that to internet ("hey my address/pubkey is X, and I have these cool capabilities as a sensor") - a user on internet sends a data-message to the address "hey give me your sensor data" - the pi routes that from internet to lora, and propagates (replays periodically if the lora is not around) - if the esp32 has not seen that peer, it can request an announce (and the pi will forward that both ways) - the esp32 responds "oh hey internet user with X address, my sensor data is X" - the message is sent over lora to the pi, which forwards on to internet

for very small data, if you don't care about P2P encryption, you could even put the sensor-data directly in the initial announce. "hey I have this address/pubkey and the current temperature is X" since announce "app data" is great for a very small amount of data.

The protocol is fairly simple, encrypted by default, and works over lots of interesting transports.

It has wine and some old windows-only apps. I took a different approach, and used a VNC server. Not quite as fast, but doesn't require the host to have an Xserver. I even include a little web-based VNC client, so no install is needed.