Meshtastic: An open source, off-grid, decentralized, mesh network | Hacker News Reader

Meshtastic: An open source, off-grid, decentralized, mesh network

meshtastic.org

Disclaimer: I'm the author. The concept is similar to Meshtastic, but the goal was to make more documented and clear choices at protocol level, to have a much simpler to hack and adapt implementation, and so forth.

If you happen to understand Italian, I gave a talk about it here: https://talks.codemotion.com/introduzione-alla-tecnologia-rf...

https://www.robots-everywhere.com/cellsol/ magari si collabora?

Oh very cool! Do you have any stats on distance and other things you can achieve? I can't believe you have a Mesh WAN project!!

Hey! With the maximum spreading, and the stock (very poor) omni antennas in the Lilygo devices, you get this:

~ 500 - 1km: urban landscape, tons of buildings in the middle. Like opposite sides of a very crowded block.

~ 5 km: open landscape, some small hills in the middle, no good optical contact.

~ 50 / 80 km: direct optical contact, especially if CRC is disabled.

Any views/comparison regarding freakwan versus reticulum https://github.com/markqvist/Reticulum ?

We used it at Burning Man in 2023. Burning Man is hard on gear and a surprisingly busy RF environment. It was reliable and has a good user experience. I really liked it.

I used it at EDC this past year and it similarly worked quite well.

My understanding is that LoRA isn't high bandwidth -- so just out of curiosity, what kinds of things did you use this for?

The official meshtastic app can only transmit text messages (max ~230 characters) plus location data (GPS). Optionally it can also transmit sensor data (see RAK WisBlock devices, where you can add sensors for temperature, humidity, air quality).

Can the mesh control plane be orchestrated/monitored/bridged by out of band comms like cellular IP or StarLink?

Yes to all of these, there is a managed mode where nodes are controlled via commands from a command channel. Bridging networks is done via MQTT so you can use virtually any transport.

Thank you!

Any articles to read about it?

I've also used it then, it worked fairly well but it seems that I might need to tweak it to update my position faster.

I also made a fork of a modified firmware that gives you your playa location

https://github.com/exadeci/Meshtastic-device-bm

I bought a pile of LoRa/Meshtastic stuff and tried to research it and figure out if I could easily use something like APRS to log my location and plot it on a map.

Seemed much harder than the process of setting up an APRS iGate and viewing my location on aprs.fi

I'd like to try again sometime though, but feel like I need a good getting started guide to motivate me!

I've got a stack of meshtastic lora hardware. I found it to be way harder to get something operating functionally than it should have been.

Never ask a woman her age, a man his salary, and a LoRA transceiver what its throughput rate is.

At double digit bits per second, it has to be like a few characters per second at best or even less with packet headers, error correction, etc.

> Never ask a woman her age, a man his salary

Wee bit sexist...

EDIT: Yes I know it's a proverb, I'm not blaming the parent post.

EDIT: 4 downvotes? Nice.

It’s a saying

Some sayings are sexist.

That actively reaffirms sexist beliefs and worldviews. Has no place in a public forum where it can and does get interpreted as such.

You're taking things out of context and commenting on the newly created problem. HN's not the right place for this

Reading the datasheet for one of the most common radios used for meshtastic devices (Semtech SX1262) the lowest bitrate is pretty slow: 18bps. But, with larger channel sizes and lower spreading factors, it goes up to 62.5kbps. I cant tell exactly which mode meshtastic uses by default, but it looks like there are 8 presets.

Before anyone gets too excited about this - half duplex/TDD-like mesh radio systems with omnidirectional antennas are one of the LEAST efficient possible ways of building a wireless village/town scale IP network. The thing about an omni antenna talking to another omni is that an omnidirectional antenna is also a 360 degree noise gatherer, and gathers traffic/timeslot occuyping stuff that might be coming from other, slightly further away, mesh nodes it can hear that your radio is not immediately engaged in tx/rx with...

Similarly, for everything that you transmit packets towards another specific node, 99% of your RF signal is going in azimuth directions that you don't want and don't need, but because it's an omni it goes everywhere. Raising the noise floor for all other nearby nodes of similar hardware configuration.

I would encourage people who want to do something like this on a very tight budget to look into the designed for purpose point-to-point (primarily parabolic reflector based) 802.11ac/ax based radio systems that exist to form L2 ethernet bridges between two locations. And some newer very low cost 24 GHz and 60 GHz based stuff also designed for exclusively line-of-sight (and line-of-fresnel-zone-clearance) point-to-point bridges.

LoRA stuff is also much better if have fixed-link needs between two spots in bands far below the typical 2.4 or 5.x GHz, working in VHF/UHF-like bands (or generally anywhere below 1300 MHz), and can point a few yagi-uda or dipole type antennas at each other instead of having two omnidirectional antennas talk to each other.

If you have sites which are not mobile and do not move around or change location relative to each other, and you want better link reliability and data rates, I would strongly encourage people to look into using just about anything else that isn't an omni to form network links between nodes.

randomly chosen example in 5 seconds of googling, note gain pattern in one specific direction:

https://www.elprocus.com/design-of-yagi-uda-antenna/

One of the cool things being done with LoRA-type chipsets and RF modules these days is ExpressLRS, which implements a serial UART bridge between remote controller and UAV (or unmanned boat, ground vehicle, etc) for link between human and onboard flight controller. Evolution of the same general idea as TBS Crossfire for RC applications.

https://www.google.com/search?client=firefox-b-d&q=expresslr...

We could even slap these on drones in a rotation to keep boosting signal for a sector.

There's so much possibility to bypass ISPs...

This is why stuff like smart antennas and beamforming were invented. But for a system like LoRA that has a very low thoughput (AKA slow in the time domain), it's not an easy concept to apply in mobility.

That's a whole lot of commenting from someone who clearly doesn't know what meshtastic is.

It's text messaging with channels, some provisions for nodes transmitting sensor data, and some location data.

It's not intended to provide TCP/IP networking.

Almost inevitably, people building "mesh" networks do try to run IP over them, because the most common and popular applications and services are all TCP/IP based.

DIY things capable of a few hundred kbps and text only are a very niche application. "Mesh" at very low data rates and duty cycles has very good purposes when purchased in a fully packaged single purpose industrial/embedded system from a vendor with support, such as how electrical grid operators implement some forms of smart meters.

I think your comment is based on something that LoRa is not.

> building a wireless village/town scale IP network

This was never its goal. You can build a simple messaging network for text that has a pretty good range and low bandwidth. That is all.

LoRA , capital A for LLM training, LoRa for wireless

Some real-life experience using the Android app, showing e.g. traceroute functionality from a very enthusiastic Brit: https://www.youtube.com/watch?v=LmGr1pGJ4sM

It says it only scales to 80 nodes, so sounds like you won't find a mesh to join unless you make it yourself and it can only be people you know.

I want a global mesh network to replace the internet

> I want a global mesh network to replace the internet

What are your design criteria you have in mind? There are tough tradeoffs around discoverability, latency, availability, security.

Me too. I think the way forward--at least for now--is not large meshes, but partition tolerant apps.

A search for "Is Taco Express open right now?" should not resolve a globally unique name to a globally unique address and then ask some distant server which will then ask for your location info so that it can figure out which taco express you mean. That's so fragile.

Instead the search should propagate through whichever meshes happen to be in range until it encounters a node which is authoritative on Taco Express hours (which is probably a raspberry pi at the Taco Express). You get local results because they're local to the query.

The problem of bridging these meshes is interesting, but it's just not that useful until we have an app ecosystem that doesn't rely on stable addresses for individual nodes.

We need context addressing and pub/sub, not server addressing and request/response. It's going to require a pretty big conceptual shift. Sadly, I don't see that shift happening until some disaster convinces us that it's necessary.

honestly i think the main obstacle to global mesh is the lack of a good business case, which is pretty intrinsic to the format. mesh makes it possible to remove almost all intermediaries, so its difficult to position a company in a place where they can capture a significant portion of the generated value. even though a global self-organizing comms network can clearly be seen as a net good. which is basically an echo of the funding issues present in many critical open source components. there are some arguments to be made for cryptocurrency in this space, but for a nascent physical network the value proposition at first will be very small. a VC/startup could try to get into this space, but once the cat is out of the bag it would be very easy to bypass the artificial billing mechanism to create a rogue free mesh using a similar protocol.

of course, this doesn't include the very real technical challenges of building a scalable mesh protocol. which are nontrivial in themselves.

Agreed on all points.

> its difficult to position a company in a place where they can capture a significant portion of the generated value

That's why I want to make the change. Companies tend to wane in trustworthiness over time, but maybe not if they were painfully aware that their relevance depends on explicit trust configs which could be altered by the end user at any moment and with minimal pain on the user's part.

Eventually things will get bad enough that a market emerges for businesses that create handcuffs for other businesses... the spiritual successor to VPN's or somesuch. Until then, it's hobbyist stuff.

That, or it'll be the big solar flare which gives first-mover-advantage to whoever can better operate in the aftermath. But until then... still hobbyist stuff.

> We need context addressing and pub/sub, not server addressing and request/response. It's going to require a pretty big conceptual shift. Sadly, I don't see that shift happening until some disaster convinces us that it's necessary.

Just my 0.02$ but I don’t see this happening. One, the content rights of media would preclude meaningful distribution and content addresses of commercial media, which is what most care about. After 2023, I think it’s far more likely that generalized human knowledge is captured in an LLM to (somewhat accurately) spew out. That LLM would be distributed and localized - Google already wants to ship a small LLM on each phone.

I also don’t see global pub/sub - I think that’s just too many trade-offs for real use cases. Latency/partition-ability etc. I do see everyone’s smarthome/phone ecosystem providing a basic and localized event service.

The pendulum does seem to be swinging back to local-first, but I think that will mean personal-scale not web scale.

The internet is already the global mesh network. It turns out one individual contributes nothing, compared to a 1000km 10000Gbps fiber link that costs millions of dollars to lay. But nobody is actually stopping you from getting ports at two DCs or IXes, somehow getting them connected to each other, then charging people to carry traffic between them. I got a price quote for about $800/month to carry 10Gbps 650km in Europe, so that's what you could potentially earn.

If you're interested in large meshes, check out wirepas, though it's based on 802.15.4 rather than LoRa.

I was a Product Manager for a mesh based personnel tracking system on construction sites. We licensed Wirepas's tech for our solution... wound up learning a lot about the nuances of meshes.

Isn't there an open source Android mesh network? Based on Wifi or Bluetooth?

I thought I heard about mesh networks being used in protests years ago...?

Do we still not have something viable?

It's crazy if we don't yet. Hardware decentralization is sorely lacking.

I've heard of Briar and Bridgeify and Serval and Meshenger, what others are there?

There is LibreMesh. There are other distros using OLSR and/or B.A.T.M.A.N. routing too.

Check https://openwrt.org/docs/guide-user/network/wifi/mesh/start

https://berty.tech/messenger

https://hyperboria.net, formerly Project Meshnet

i remember something that was deployed in puerto rico after the hurricane in 2017.. a quick search later: https://techcrunch.com/2017/11/14/a-mesh-network-spontaneous...

... And it looks like the consumer products are all completely unavailable right now. Seems like they're focusing their efforts on rescue, emergency, and tactical products...

Dang it!

Briar for sure, but Android is hostile to mesh networking (unsurprisingly).

yggdrasil can use WiFi on Android, I haven't tried it yet - https://yggdrasil-network.github.io/. yggdrasil gives you the ability to use TCP/IP applications over its mesh network but doesn't offer any end-user functionality itself.

Manyverse can use WiFi for decentralised social networking - https://www.manyver.se/. They're currently in the middle of a rewrite of the backend and a protocol switch away from Secure Scuttlebutt to their own protocol currently named PPPPP.

Reticulum/Sideband offers a P2P messaging system over WiFi or other mediums - https://github.com/markqvist/sideband

You're thinking of this, I think: https://en.m.wikipedia.org/wiki/FireChat

And it was discontinued in 2018 and not open source.

I wanted to be part of the “Decentralized Web” movement that TimBL spoke at but it died down.

I signed up to go to “offline camp” in Oregon (anyone else?) but it was canceled due to a large forest fire (probably related to Camp Fire) so I wound up camping near a river instead.

I’ve spent $1 million and over a decade to build open source community software that can run on any commodity servers — on a plane, on a cruise ship like Norwegian Cruise Lines, in rural villages, etc.

We want to help local education (including Afghan girls, but we are also in touch w the RohingyaProject.com and others to help stateless refugees).

Anyway, these mesh networks exist and our cellphone hardware is great, what’s missing is great backend software to wean people off Big Tech (Twitter, Facebook) the way the Web did for AOL, MSN, and the way Wordpress did for Web 1.0

If anyone wants to get involved, or knows a good “decentralized web” or “indieweb” movement that actually thrives, comment below and let me know how to get in touch.

https://qbix.com/blog/2021/01/15/open-source-communities/

Recent article covering the platform:

https://www.laweekly.com/restoring-healthy-communities/

https://www.robots-everywhere.com/cellsol/ We made this in 2020ish and it respects meshtastic and disasterradio packets.

Used to use this but it’s long gone. https://en.m.wikipedia.org/wiki/FireChat

Is it feasible to create a mesh network using Bluetooth on participating smart phones?

In crowded places like college campuses, we could run campus IM on it for instance

I think any wireless mesh like this runs into issues with scaling because you cannot efficiently route messages between a bunch of moving nodes as the network topology is always changing. You have to use a flood network, which is also what Meshtastic does [0]. Flood networking wastes bandwidth with every node repeating itself, and it gets even worse with wireless that's a shared spectrum.

All these mesh networks have a max hop limit, to prevent messages from bouncing around the network repeatably, but also not guaranteeing messages reach their destination. Meshtastic defaults to 3. Gotenna I believe is also Lora and is also 3. Bridgefy is bluetooth and has a 250 max hop limit, but also a 7d TTL, basically not close to real-time.

It could be made better by having statically position nodes that keep track of the nodes it can reach. And then having all these statically positioned nodes communicate with each other on a different wireless spectrum so you don't interfere with regular nodes. Since that topology isn't changing, you can efficiently route message between them. Now that's basically just regular wifi mesh.

[0] https://meshtastic.org/docs/overview/mesh-algo

There are more state-of-the-art routing protocols working to solve this problem for mesh networks. A couple examples of projects I have been involved in:

https://yggdrasil-network.github.io/ https://github.com/matrix-org/pinecone

I don't know if I consider those the same thing as they're not fully wireless meshes. They'll use the internet when possible, so it wouldn't be an off-grid network. And without internet, it won't scale.

So if you're using internet anyways, at high-density locations like a college campus, just deploy more wireless APs in the area instead of building an inefficient wireless mesh network. The wireless mesh part of those protocols is only useful for areas with no internet, but somehow enough people to build a chain to an internet connected device.

Reading Pinecone's documentation: "The only requirements for a peering today are that it is stream-oriented and reliable" [0]. I don't think a phone that's constantly moving around and battery operated (so you want to power-save by transmitting less) is considered reliable.

Pinecone's offline protocol also will not route to devices that haven't been seen in the last 10 seconds [1]. Basically preventing phones from sleeping or going into a low power state. That's also the kind of protocol that only works for small wireless mesh networks. A huge wireless mesh network would quickly be filled with "I'm here" broadcasts if a device is expected to do it every 10 seconds and it has to be repeated for everyone else on the mesh.

[0] https://matrix-org.github.io/pinecone/introduction

[1] https://matrix-org.github.io/pinecone/virtual_snake/maintena...

To be clear, neither Yggdrasil nor Pinecone have any concept of “the Internet”. A peering over the Internet is fundamentally the same as a local peering taking place over something like Wi-Fi or Bluetooth and they are not treated preferentially or handled differently.

Both protocols are also designed with mobility events in mind and measure far better than many other routing protocols on route convergence in highly mobile environments.

Also interpret “stream-oriented and reliable” as link-layer characteristics, i.e. a peering over TCP even if it is link-local satisfies these requirements. Not “reliable” as in “never goes away”.

Do you have any examples of their mobility event handling? I'm reading the documentation for Pinecone and don't see much. Even Pinecone says Yggdrasil's spanning tree isn't good enough: "However, the spanning tree topology alone is not a suitable routing scheme for highly dynamic networks." [0]

I'm reading that as why Pinecone has the virtual snake topology. But they define that as a public key-based routing, which doesn't take into account optimal routing in the network. Nodes are ordered by public key [1]. It's good for P2P mesh, not wireless offgrid meshes.

And their SNEK routing does prefer the internet over Bluetooth [2]:

> we can further refine the path to use either the faster or lower latency link type to route to that peer:

> If the Best candidate has a slower peer connection type (Multicast > Remote > Bluetooth) than the connected peer

[0] https://github.com/matrix-org/pinecone#does-pinecone-work-on...

[1] https://matrix-org.github.io/pinecone/snake

[2] https://matrix-org.github.io/pinecone/virtual_snake/nexthop

Most of the mobility testing has been performed either in the meshnet-lab[1] or the pineconesim[2].

As the original author of that documentation, it's quite entertaining to have it quoted back to me. :-) In any case the routing "prefers" links labelled as the internet when there is a tiebreak between two peerings between the same pair of nodes, i.e. you are connected to some other device via Wi-Fi and Bluetooth simultaneously.

And while it is true that Pinecone cannot necessarily always make the best routing decision based on public keys alone, aggressive queue management attempts to provide the best QoS for all flows and it scales very well because nodes maintain only a small amount of state about their position in the spanning tree and their position in the SNEK. Importantly, shortcuts can and often are taken when Pinecone switches to tree-based routing as the geometric distance to the destination on the tree is evaluated at each hop. Routing "by the SNEK" is used primarily to find the remote node and as a fallback in case the tree routing fails.

[1] https://github.com/mwarning/meshnet-lab [2] https://pinecone.matrix.org or https://github.com/matrix-org/pinecone/tree/main/cmd/pinecon...

Thanks, looks interesting for sure, I hope to be proven wrong!

the 'find my shit' networks deployed within the gog and apl ecosystems can be used to piggyback on for low-bw off-grid communication

Interesting! Any further reading you would recommend on this?

Yes it is possible. The P2P Matrix demos worked in this way but they were alpha-quality at best, shoehorning today’s federation protocol on top of Pinecone mesh routing over Bluetooth/Wi-Fi. It still needed a lot of work to adapt the Matrix federation protocol to be properly usable in real-time without full-mesh connectivity.

iOS limits what you can do in the background with Bluetooth. At least one of the iPhones needs to have your mesh app running in the foreground to communicate with another iPhone that has your app. Two locked phones with your mesh app will not be able to communicate over Bluetooth.

See previous discussions https://news.ycombinator.com/from?site=meshtastic.org

I jumped head first into meshtastic. Sadly after setting up and 3d printing a case, mounting an external antenna ... No other users in my area. :(

During summer I played around with this technology and built a simple messaging app (written in Common Lisp), see:

http://cl-repl.org/meshtastic.htm

I just played with it a little bit and my first impression was that the Meshtastic app is exceptionally well made. I only tried iOS, so I can only speak for that, but I was pleasantly surprised.

Has anyone deployed and used a system like this here?

If so, what was its purpose and why this technology over others?

Preppers use it as a backup communication channel.

The scenarios are:

  1. Your country is invaded, and you are building a resistance.
  2. Your government becomes a dictatorship. You want to fight back.
  3. Natural disasters: the grid and mobile network are down. You want to organize and work together to help each other.

Meshtastic nicely blends into the existing IoT LoRa traffic. And give you some sort of invisibility.

Other scenarios are similar to ham radio - asking other dudes about the weather.

Or you are out in the mountains with spotty cell coverage and want to be able to send messages to other friends around you

Not everything prepper-like is for prepper-only usage

It's been a while but I can remember going to sport events where the local cell network could not cope with the traffic. Calls wouldn't connect and SMS were delayed.

These would also be handy in construction when you're deep in the bowels of a new building and can't get any reception whatsoever (cell, CB, etc.)

These are the scenarios I was looking for. Thank you.

The extreme event scenarios have pretty obvious applications but are also very rare.

Yes. We use it to have a backup communication channel when all other networks are down. This is an extremely unlikely scenario. If that happens wireless communication is going to be the least of the problems.

Another Carringron scale event is not only likely, it’s virtually inevitable. Whether it happens in our lifetime remains to be seen, but it would fry much of our communication infrastructure. The status quo is much more fragile than it appears.

We have similar plans.

I just bought two LilyGo TTGO T-Echo devices. My plan is to experiment with them on snowmobiles. The ability to be slightly separated (a few km) but still send location and brief messages will be handy deep in the woods where cell coverage is very spotty.

Reply on news.ycombinator.com