Reticulum gets around a lot of these problems, as the (better) encryption is app-level (or even more fine-grained.) Its also not tied to lora, so you can interop easily with other transports. I made a websocket transport for it, and there is already TCP and UDP, and a couple non-lora radio transports. I also made a (works on web) js and Arduino client lib, and it has a few native client libs, so it can sort of be used on anything, even over traditional networks, or web clients. Meshcore and meshtastic are way more popular, but reticulum seems so much better, to me, for most things. It can still have overload problems, like any radio network, but no client is required to forward, so you can build a different kind of network ("only forward messages that are for my peeps" and marked correctly.) It also has "it costs compute PoW to send to me" which can greatly cut down on spam.

I only recently discovered Reticulum, only to then learn that the developer has retired from working on it. Do you know if there's still any community members carrying the torch?

The discord is still very active, and there are still commits from original developer, so I am not sure. Its a simple enough protocol, though, and it's been reimplemented a few times. I made my own no-class python version, js, C, etc. Someone made a rust version.

He has not retired from working on it. He just got fed up with the community and is now pushing changes without allowing github issues and discussions.

Great for small networks. Once bad actors find it, it will be attacked. See gnutella as the case study on unsupervised peer to peer networks

I just read gnutella page on Wikipedia, no mention of bad actors

I take it you never got a mislabeled mp3 of Bill Clinton advertising online poker.

The crypto is bad and the networks are extremely low bandwidth and quite unreliable and are vulnerable to jamming or spam/overload.

I’ve deployed lots of nodes, and the technology reminds me of ipfs: people who don’t use it much vastly oversell its capabilities.

I really want to get into these Lora based mesh tools but the range in my experience is terrible. Maybe I'm doing something wrong, maybe it's a lack of nodes in my area.

I just tested the other day. I'm in the midwest US so it's winter, no leaves. I managed to get about a quarter mile before my two portable nodes couldn't talk to each other. T-Echo with muziworks whip antenna.

Without a bunch of solidly placed, high elevation, high gain antenna nodes, this just isn't really that usable.

Plus, all the other issues others have highlighted.

Height is might.

I couldn't get ANYTHING on my first/test ESP32 (Heltec v2).

Anything. I didn't see any packets. Then I finally heard one station later when I held it high on the upper floor.

The I hanged it at the top of my roof and I currently have almost 130 repeaters and room servers.

In your scenario a couple of 5W handhelds woukd work better.

But I agree the usabity is very limited. This is why I think of hanging a couple of guerilla solar repeaters in my neighborhood :)

> In your scenario a couple of 5W handhelds woukd work better.

Exactly, in nearly every “off-grid”/no cell service scenario where I’ve needed comms, the GMRS radios > Lora.

Its an interesting idea but I can’t go site prep 100s of miles of snowmobile trail before I go just to be able to send a text to someone a mile away.

Meshcore and -tastic have the huge problem that the encryption keys are bound to the device and not the app.

I've been using the T-Deck Pro and T-Lora Pager, so the device is the app.

I agree, there's way too much going on in the firmware, just make a dumb Lora-bluetooth bridge. Hell, just integrate a Lora radio in a phone.

The base software is open, you could potentially do it!

:)

Honestly: MC and MT are classical bloated Arduino projects with a giant single big-loop and an interrupt coming from the LoRa modem.

Both projects are hitting their limits because of this. Every new feature and every bug fix causes endless amount of pain and breakage.

I was involved in both - and gave up because of this.

IMHO both projects need some kind of thin-client which delegates most of the functionality into the client. Only keep some basic LoRa/Message Buffer/Routing/Battery Saving functionality in the hardware itself.

> This community should be talking about meshcore more imho.

The fundamental problem of distributed networks is that you can either have centralized control of the endpoints, or your network becomes vulnerable to denial-of-service attacks. So meshcore/meshtastic are great because they are used only by well-meaning people. If they become more popular, we'll start getting tons of spam :(

This isn't great advice if it's supposed to be an alternative to text messaging with a carrier (especially if you're using encrypted RCS).

For one, meshcore doesn't do a fantastic job of protecting metadata. Advertisements include your public key, and if I'm reading this[0] right, your GPS coordinates.

Second, the default public channel uses effectively no encryption at all.

Moreover, the network doesn't exhaustively prevent someone who intercepts a packet from identifying who sent it. It's no Signal.

[0] https://deepwiki.com/meshcore-dev/MeshCore/7.1-packet-struct...

All telemetry is off by default, you have to explicitly tune it on and then optionally permit specific contacts to poll it.

The PKI is basic because these networks are tiny and merging. And running on tiny computers ($5 boards with no display)

Public channel is public and it uses the default encryption key because it's a default channel, so by definition everyone is invited to participate. Not sure what your critique is.

And no, it's not trying to be signal. It's also currently less reliable.

But it's still safer than Sms, by a country mile.

It's bad advice because:

1. Telling someone to use one of these devices because their phone carrier might look up their location is silly in the first place, because meshcore doesn't even eliminate the possibility of being tracked geographically.

2. It protects your messages better than SMS but if you care about the privacy of your messages, it's infinitely worse advice than suggesting someone use Signal or another app that actually replaces SMS securely.

You aren’t reading this right. Gps sharing is off by default on meshcore.

Still falls flat when it comes to metadata privacy. Just having multiple nodes distributed geographically that listen for packets would give you the ability to narrow down the location of a specific identity dramatically, even if you're not in range of their device.

What does this have to do with mobile carriers tracking GPS data? If you're implying we should use it instead of mobile phones that's not practical at all.

If you go hiking with friends who aren't total nerds, the proprietary options offer a more consumer-grade experience. (ie, usable by them)

Yeah just get inreach. It works even when you're out of range of anything.

If you go hiking with a bunch of people into the backcountry, you don't want to rely on the cellular network.

Handheld radios, meshtatic (not meshcore), and in 5 minutes you're set up and good to depart. Or ideally inreach indeed.

I’ve been wondering this for a while and maybe someone has a clue.

Based on the very “bursty” nature of LoRA, how much does an adversary need to spend to radiolocate it? What’s the threat model there?

$20? These networks do not try to hide your location and triangulating known frequencies is trivial.

How trivial is it, really? These are spread spectrum devices that could have very sparse duty cycles. If you sending only millisecond bursts a couple of times an hour, for telemetry and whatnot, it would seem pretty hard to get a good fix, especially when moving. I haven't analyzed lora traffic, so just talking out of my ass.

LoRa uses chirping which are much longer than milliseconds. You can clearly see them in a spectrum display. It's a very slow protocol. Not as slow as WISPR or JT8 but still slow. The flip side is that it's robust (the chirping provides a lot of interference protection against fixed-frequency interference for example)

With a couple of GPS-synchronized receivers stationed in an area, child's play. LoRA airtime is extraordinarily long for common spreading factors.

Sdrs are super cheap these days. It wouldn't be hard.

Note: did things in .mil

You could get a rough location for free. Every time you send a message, “observer” nodes connected to the internet publish the packet, and in the packet is the repeater path taken, repeaters have known locations and the first repeater is going to be near you.

If its meshtastic, just keep sending traceroutes until you triangulate the node.

Is it open source?

Meshcore is open source. It’s « some » of the apps that are not.

https://github.com/meshcore-dev/MeshCore

What, protocol? Basic apps? Yes.

Why Meshcore over Meshtastic?

There’s lots of YouTube videos about this but basically: you can specify routing.

Meshtastic has terrible defaults (every node rebroadcasts everything, every node sends telemetry), which makes sense in the backwoods but not anywhere close to civilisation.

This, combined with the 10% duty cycle limitation on the used frequencies is the main issue, I believe. Once the 10% are used up, a node basically has to go dead until it falls below 10% again. And with lots of messages about battery levels and other telemetry being sent and relayed, those 10% get used up fast.

It is surprising that these networks aren't more popular. There are still many places and situation where connectivity isn't available

It's because they aren't very resilient. More of an experiment than a purpose designed tool for the, uh, current environment.

Because they're terrible and fall apart if more than a few score people are on the same freqency at the same time.