Comment by eternityforest

you should read more about it here, it's fascinating stuff: https://reticulum.network/manual/understanding.html

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.

konsumer a day ago

No DHT. it seems to work fine for 1000s of nodes without it, though. The TCP testnets, for example, are pretty highly populated.

Reply View 2 replies

eternityforest a day ago

That's pretty impressive, I wonder how it handles LoRa or Bluetooth?
I assume every packet is probably at least 32 bytes, if 1000 people send one every ten minutes, that's going to be 700 bits per second or so, right?

Reply View | 1 reply
- konsumer 15 hours ago
  
  you should read more about it here, it's fascinating stuff: https://reticulum.network/manual/understanding.html
  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.
  
  Reply View | 0 replies