Connect to meshtastic nodes

[RubenKelevra]

Detailed Description

Meshtastic is a long range mesh network via LoRa which is self-organizing and completely off grid. The Meshtastic app on the smartphone connects via BLE to an ESP32, which has a LoRa-radio to bridge the communication to the mesh network.

Berty could make use of this low power, long range communication platform by connecting to a local Meshtastic node if available and use the mesh-network as a transport.

Context

Why is this change important to you?

Internet connectivity is a premium in many parts of the world and in case of natural disaster infrastructure which runs the internet is often not available or not reliable. Using just BLE/Bluetooth won't be enough to cover large areas of communication, since the cells will brake up and only allow short range communications.

Using LoRa would allow to seamlessly bridge the gap by extending the network beyond the reach of internet-connectivity, by having some devices with internet-connectivity and Meshtastic nodes to route messages into the LoRa-meshnetwork if necessary while also allowing communication between nodes inside the network.

The LoRa-Meshtastic nodes usually also run with a battery backup, since there are boards available where you just put an 18650 into a battery holder, making it very convenient to power without interruptions while on the go.

How would you use it?

If implemented, I would like to setup multiple nodes with internet access and battery backup to allow communications without having internet access in my local area.

More Info

Here's a short introduction into the technology and the hardware used to do this:

https://www.youtube.com/watch?v=TY6m6fS8bxU

---

@geeksville what do you think about that? Is that feasible?

[jefft0]

Hello @RubenKelevra. The concern with LoRa is that it is not built into smart phones (like local wifi) and that it is low bandwidth which makes it difficult to be an active IPFS node and to send pictures. Do you have any comments about these concerns?

[RubenKelevra]

Hey @jefft0,

tcp should actually work fine with these bandwidths, as long as the window size gets restricted and the timeouts are long enough to recover from interruptions in the network route. And the used noise framework is designed for very low bandwidths as well.

The used batman-adv protocol is pretty efficient with sending multicasts, as they are just added to the regular originator messages and thus doesn't have any overhead.

Running a "full" node on these networks could therefore be improved by reducing the bandwidth needs for IPFS:

The first idea would eliminate the need for:

• knowing the available network peers in advance
• establish connections
• doing handshakes
• keep connections alive
• send negative responses back
• update a DHT-database, while most of the data may never be used

1) instead of creating a (local) DHT and do unicast queries ipfs could do cheap multicast queries in the network, and get only positive responses back via unicast: https://github.com/ipfs/go-bitswap/issues/563

The second idea cuts down on the spend bandwidth on open connections if they cannot supply the wanted data, while still allowing to recover from this state. The result is more latency for fetching data from nodes which haven't provided any data in the recent history - but as the bandwidth is so tiny anyway, that's probably hardly an issue.

2) Once ipfs found a peer which can provide a block it would be asked via unicast to provide more blocks from the want list. This process could be optimized to use less bandwidth sending only some of the CIDs with varied probability based on the recent history of hits: https://github.com/ipfs/go-libipfs/issues/81

[RubenKelevra]

By the way, as batman-adv is a layer 2 network mesh which creates a L2 network there's no need for an IP/TCP header. In theory (and if the OS allows) you could just L2 communication after asking everyone with a L2 broadcast and a custom header which tells everyone via a join message what's the public key and they can store the public key to MAC-Address relation.

They can just respond with the same message back and tell the new node which public key they have and thus filling up the new node's public key to MAC-Address relationships table.

This would avoid that the IP traffic is maybe routed to other networks or some end devices responding initiate IP broadcast, as each of the Meshtastic nodes can be configured to just allow this custom L3 Header to be accepted.

Also this would remove the issue with 1500 MTU packages by the clients.

You could instead use QUIC directly on top of the L2 package header for managing the transfer/resubmission/reordering etc.

While lowering the package size if the connection is very bad and you observe a lot of package drop.

If you lower the package size it would normally lead to a massive overhead, which is reduced by dropping the TCP/IP header.

QUIC can also do secure 0 round-trip transfers, as you can already have the public key in the table, which QUIC can be instructed to use.

[eyoxin]

This is a great idea! I hope the fact this makes less need for IPFS doesnt prevent Berty from implementing it since it would be a great innovation to include meshtastic support. @jefft0

The worry people have from investment coming from web3 is that innovation might be stifled if it require the use of "web3" networks.

Helium was a catastrophe due to them trying to push their blockchain when it made no sense to be involved and I really hope Berty doesnt go down the same route.

I love the Berty project and I hope to continue seeing the team innovate and improve mesh communication.

[jefft0]

There have been many proposals for network enhancements. Keep this in the backlog until we have some time to review.