Cleeyv

Freedom for all ways of life 🧬🌿🏳️‍🌈 against domination 🏴Ⓐ💜 abolish the global colonial system 🌍🌎🌏 technology is always political. Settler, he/him 👨‍💻

Avatar image: Map of the northeastern corner of so-called North America, with different colours for each watershed region, on a black ocean background.

Header image: Photo of a city skyline with only the very tops of a few buildings visible at the bottom, in front of a beautiful sky colour gradient from raspberry, to pink, to topaz.

Last Notes

2026-08-21 17:07:43 UTC

- reply

@nprofile…35vy somehow this bug looks so much like you lol

2026-08-08 19:24:26 UTC

Security and Privacy Comparison of #Meshtastic, #MeshCore, and #Reticulum for LoRa Messaging
This is a public draft. Feedback is welcome.
Meshtastic and MeshCore are the two most widely known messaging platforms for LoRa radio communication. LoRa messaging over the Reticulum networking stack (RNS) is a less widely known third option that offers much better security and privacy. Portable LoRa radios running Reticulum's RNode firmware (paired with client software on a phone or computer) have been usable for years, but standalone LoRa repeaters with microReticulum firmware have only started becoming usable within the past six months.
The lack of easily deployed repeater firmware prior to this year seems to be a major reason why Reticulum has not thus far been a viable alternative for building LoRa mesh networks. With the increasing usability of microReticulum firmware, it becomes more relevant to consider Reticulum as an alternative to Meshtastic and MeshCore for LoRa messaging, especially for use cases that prioritize security and privacy. It is worth noting that Reticulum is a more general networking stack with many uses outside of messaging, and also that it is not limited to LoRa and can create links that hop seamlessly between the internet, local WiFi networks such as HaLow, and even long range HF radio.
The messaging protocol built on top of Reticulum is called LXMF, and one of its significant limitations compared to Meshtastic and Meshcore is that it does not offer group communications as a built-in feature. This will hopefully be added at some point in the future. Until then, groups can only be implemented using additional software that would have to be further evaluated for how it affects security and privacy, such as a server that does a mailing list style forwarding of LXMF messages to subscribed contacts, or posting messages to a Reticulum-hosted forum or chat room. These options are all much less convenient than the default group functionality offered by Meshtastic and MeshCore.
ENCRYPTION SECURITY
The encryption offered by Meshtastic is very limited and does not even attempt to offer most of the protections that have been expected from encrypted messaging systems in recent decades: https://meshtastic.org/docs/overview/encryption/ MeshCore attempts to improve on this in some ways, but uses AES-ECB encryption that was known to be flawed long before they started using it, and has a number of other protections that are either not implemented, or implemented in flawed ways: https://github.com/meshcore-dev/MeshCore/issues/259#issuecomment-4060765626 There are ongoing discussions and proposals for improving the MeshCore encryption and fixing some of these problems, but the timelines for implementing these are unclear.
The encryption systems of both Meshtastic and MeshCore lack perfect forward secrecy, which means that if someone gets access to the private or pre-shared keys on any side of an encrypted conversation (such as through physical access to a LoRa client node) they can decrypt both past and future messages from that conversation until the keys are manually changed. In other words, there is no automatic key rotation built into the encryption system.
Reticulum uses strong, well-implemented encryption. From what I have seen, the only significant feature it lacks is quantum resistance using new asymmetric cryptography that started becoming usable a few years ago. This quantum resistant crypto involves much larger keys that would be a problem for key exchanges over limited-bandwidth radio links that are a primary use case for Reticulum.
METADATA PRIVACY
Every Meshtastic packet, including the telemetry that is sent automatically, includes a publicly-visible device ID based on the unique MAC address of the LoRa hardware sending the message. This ID cannot be changed, not even by reflashing the device. This makes surveillance of Meshtastic devices (and therefore users) much easier over time, and makes anonymity much more difficult. Discussion of this issue has been ongoing for nearly two years and the developers say it might be fixed in a future release but there is no specific timeline: https://github.com/meshtastic/firmware/discussions/5007
Every MeshCore packet has a routing path field in its publicly-visible metadata that shows which repeaters the packets has passed through on route to its destination: https://docs.meshcore.io/packet_format/ This provides at least some information about the geolocation of the sender, with the precision of a location estimate depending on the density of repeaters and radio propagation dynamics in the area. These repeater hops are provided in the MeshCore client interface to recipients of messages, and also publicly recordable by anyone listening to MeshCore traffic over the air.
The design of Reticulum prioritizes user privacy and keeps packet metadata to a minimum. For example, the unencrypted packet header includes only the recipient address of the packet, but not the sender. There is also an optional feature called Interface Access Codes (IFACs) that allow for a network name and password to be shared out of band to all nodes in a network (including repeaters) and used to fully encrypt all traffic, including packet metadata. When an internet connection is available, Reticulum traffic can also optionally be routed through more metadata-resistant and secure anonymization networks, such as I2P or Tor.
DEVICE SECURITY
Both Meshtastic and MeshCore client devices store all their sensitive information, such as message contents and encryption private keys, on the LoRa radio device. These are minimal embedded devices without encrypted storage or any other device security features. This means that anyone with physical access to one of these devices can easily extract all of the sensitive information and potentially use it to decrypt both past and future communications due to the lack of perfect forward secrecy.
For Reticulum communication over LoRa, all of the sensitive information is stored on the phone or computer running the Reticulum client software, not on the LoRa radio device flashed with RNode firmware. Therefore, this information can be much better protected by the encrypted storage and other substantial security features of the phone or computer's operating system and hardware.
On LoRa devices without a screen, both Meshtastic and MeshCore use a default pairing code for bluetooth. If this pairing code is not manually changed, anyone within bluetooth range of an unpaired device (such as in an adjacent room) can connect to the device and get access to messages and pre-shared group keys stored on it. The RNode firmware always uses a randomized pin for bluetooth pairing, even when the device has no screen. This is a small thing, but it also an example of how at all levels Reticulum development has made design choices that prioritize privacy and security, even when it is not convenient.
CONCLUSION
The points of comparison above are just a few of the major security and privacy issues with Meshtastic and MeshCore that stand out when comparing them to Reticulum. These specific issues point to a more general pattern: privacy and security have not been consistent design priorities of Meshtastic or MeshCore in the way they have been for Reticulum. Therefore, there are likely other aspects of these platforms that are not included above, or not yet publicly known, that are also problems from security and privacy perspective.
For example, in April of 2026 a software security researcher published a blog post titled "MeshCore's problem with security" in which they explained a significant vulnerability they found that allowed a remote user to wipe a node: https://alainx277.com/posts/meshcores-problem-with-security/ In addition to problems with how the MeshCore developers silently fixed the vulnerability without disclosing it, the researcher also noted that the code was written in a way that very likely contained many similar vulnerabilities, concluding "I cannot recommend using MeshCore for private or sensitive communication, due to both the handling of security problems and the general state of the codebase."
Reticulum software has had security vulnerabilities in the past, and will inevitably have more in the future. A design that prioritizes security and privacy does not eliminate these kinds of vulnerabilities, but it does mean they are usually more limited in scope, and increases the likelihood that they are taken seriously with quick patching and proper disclosure. For use cases that require greater security and privacy of LoRa radio communications, Reticulum/LXMF messaging provides a substantial improvement over both Meshtastic and MeshCore.
Edit 1 - Clarify LoRa messaging scope in title and intro.

2026-07-10 15:02:52 UTC

- reply

@nprofile…v6fw check out this project! https://github.com/rfjakob/earlyoom I use it on nixos and it seems to improve things (though still no notifications).

2026-06-26 03:57:08 UTC

- reply

@nprofile…klgm If you're looking for pre-built firmware images for the T114, this is a microReticulum-based firmware project that offers them. I tested its RAK4631 image a couple weeks ago and it seemed to work well: https://github.com/thatSFguy/reticulum-lora-repeater/

2026-05-26 22:57:41 UTC

- reply

@nprofile…35vy @nprofile…xehw I agree that currently Signal has substantial advantages over DeltaChat, which is why the proposal is to prepare it as a fallback if Signal is unavailable or compromised but not to switch to it proactively. However, DeltaChat developers are working on closing the gap. In recent months they greatly minimized the amount of message metadata available to servers: https://delta.chat/en/2026-03-31-zero and they are actively working towards implementation of Autocrypt2 which would include key cycling (which they call Reliable Deletion and is more often known as Forward Secrecy), as well as post-quantum crypto.
I also agree that in order for DeltaChat to actually be useful in that no-Signal scenario, especially on short notice, a lot of work has to go into preparing for it in advance. Kudos for the people behind Signal Contingency Plan for their work on this.
I've been working a lot lately on Reticulum, and talking with people about how it has the potential to become an anarchist comms fallback of last resort, especially in ecological and political emergency scenarios in which the internet is sufficiently disrupted/censored that even use of DeltaChat is less possible. Also, I think it has a lot of potential for more secure/private comms in remote ares where there is no mobile internet service without relying on satellite services. From a technical security and privacy perspective, Reticulum is already quite good (metadata is very minimal and there is key cycling). However, there are not yet any client apps with automatic message deletion, and it is unlikely that post-quantum asymmetric crypto will be implemented anytime soon because the keys of currently available protocols are very heavy and therefore incompatible with Reticulum's target use case of low-bandwidth/radio.
However, the main limitation of Reticulum is that is that it is much more technically involved to use, and the UX of both the client apps, and the software ecosystem as a whole, is of very mixed quality (open source problems!), so it is still unclear to me how practical it is for more widespread use outside of more technical networks. Also, there is still not support for group comms integrated into the core of the protocol. Group comms can still be setup via a server that resends messages to a list of contacts (like mailing lists), but this is kind of a third-party workaround. These are all things that can be improved on though, and some important work is happening recently in that direction. I'm actively in the process of testing it out with more people so we'll see how that goes.

2026-05-19 12:32:14 UTC

- reply

@nprofile…35vy there has been a proposal circulating since last year to use Delta Chat as a fallback if Signal goes down or is unavailable: https://signal-contingency-plan.info/ and there is also a podcast interview with people who worked on this: https://thefinalstrawradio.noblogs.org/post/2025/12/07/signal-contingency-plan-delta-chat-with-fanny-and-mary/

2026-05-06 19:40:15 UTC

- reply

@nprofile…red6 @nprofile…kknf @nprofile…h0ux Yes, the software exists and preliminary testing shows that it works. Practical deployment testing is the next step.

2026-05-04 15:06:07 UTC

A comprehensive guide on how to install and test the RTNode firmware on a Heltec v4: https://rns.recipes/forum/build-guides/how-to-install-and-test-the-rtnode-firmware
Firmware based on microReticulum, like RTNode, are now making it more practical to use #Reticulum for building a local #LoRa mesh. It can run autonomously on inexpensive, solar-powered hardware, just like #Meshtastic and #MeshCore have already been doing, but with an overall design that is much more focused on privacy and security compared to the other LoRa platforms.

2025-06-11 15:11:29 UTC

- reply

@nprofile…m8mr when you say "to continue supporting pixels" do you mean continue supporting newer pixel models beyond the 9a (which will probably require Android 16) or do you mean to continue supporting existing models (9a and older)?

2025-06-11 14:14:13 UTC

- reply

@nprofile…m8mr Even if a port of Android 16 weren't possible at all, Graphene on existing pixels with Android 15 should continue to be supported until at least April 2032 (for the pixel 9a)?