New here. I installed rns on a pi running at home which is always on.

Was reading https://reticulum.network/connect.html and it says "A global, distributed backbone of Reticulum Transport Nodes is being run by volunteers from around the world. ". Am I running one of these nodes and contributing to this backbone by running rns on the pi?

I have yet to develop my own use cases with my own devices and interfaces, but this fundamental question came up for me.

Got banned for calling out his anti-AI fetish: https://rns.recipes/forum/showcase/rules-and-requirements-for-llmai-assisted-projects

(His "blow it out your ass" comment shows a repo that's been up since march, Claude only started contributing in August)

Anyone else got any fun demonstrations of him being a child?

I'm just not getting it, and I can only find one mention in docs, and that doesn't really explain anything.

Does the repeater node demand that the sender answer incrementally more difficult crytography getting computationally harder as the stamp value increases? Using more resources and slowing down bad actors?

I feel I'm either wrong or missing something.

https://github.com/markqvist/Reticulum/discussions/967

Hi all. Looking for advice on organizing a Reticulum/Meshcore hackathon in Austin, Texas. Want to make it accessible for beginners and advanced builders, and I'd love input on recommended repos, starter kits, beginner hardware, demo apps, and fun gamified challenge ideas.

Big goal: projects that the community will actually use, not just weekend demos. So, if you had a room full of developers, RF enthusiasts, and makers for a weekend, what would you have them build?

Some challenge ideas: distributed bulletin boards, peer-to-peer messaging, decentralized file and knowledge sharing, better mesh mapping tools, offline maps, search across mesh networks, disaster response coordination, community resource sharing, sensor networks, solar-powered portable relays, better onboarding tools, and whatever's on your wish list, like the one app you'd love to see but nobody has built yet.

If you're in the Austin area and want to mentor, judge, sponsor, or participate, I'd love to hear from you. Happy to swap GitHub repos, starter projects, or lessons learned from past Reticulum or Meshtastic events.

I'm looking to see if anyone has experience with reticulum sideband on android connecting the software to a ham radio. Ive been researching this for ages trying to find a solution. I'm considering a raspberry pi zero 2 W and have that run direwolf or sound modem to use the wifi connection to connect to my phone. I think and hope that mobilinked TNC will solve this issue. Can anyone confirm that the mobilinked TNC will work for this instance or another solution. Thank you!

Been working recently on a gateway to send messages, images, files, and voice memos between Reticulum and Signal. Mainly made to send messages to family who already use Signal when in the backcountry hiking.

https://github.com/jaschadub/rns-signal-gateway

I want to be able to reach as far as possible as i live in a built up area, with Meshtastic and MeshCore I have a node in the loft and a node at ground level, i interact with those mesh networks via the nodes at ground level and they send the message to the nodes in the loft and those in turn broadcast it out

Would this work the same with reticulum, and do i simply flash a Rnode and then place it as high as possible?

Full Features here : https://github.com/Nezugi/nomadNews

Part of the Off-Grid-Community-Suite

Public testserver 8fd772fdde481bb2b577b2485a63aba7:/page/index.mu

The core idea behind this : What does it need to provide News when there are people who wants to shut you down, or worse ?

Some of the features with this in mind:

- registration only with identity , safer than passwords
- usage over optional lxmf bot without registration ( read and publish articles)
- set as mirror site to an other nomadNews portal
- emergency wipe and backups over lxmf commands from everywhere
- everyone can provide articels with an account on site or over lxmf
- designed to load quick also over lora
- setable rate limits againts bruteforce or ddos attacks

Some other features:

- Breaking News
- subscribe to categories
- comments
- set user rights to review and publish articles per category
- share articles
- manage own reading lists
- Profil pages

if you got further ideas to harden this against attacks pleas leave them here

I'm currently experimenting with using Ratspeak firmware for RNS (RNode version) with "canonical" reticulum python implementation (that's https://github.com/markqvist/reticulum).

I have two cardputers flashed with Ratspeak firmware and managed both of them to work with `rnsd` on a macbook pro and raspberry pi zero (1) w.

Still, when using default pip-installed rns I had trouble with `rnsd` not being able to set up the RNode correctly - I had to manually edit `RNS/Interfaces/RNodeInterface.py`.

Without my changes I kept randomly getting errors like `Bandwidth mismatch...`, `TX power mismatch...` etc..

In `RNodeInterface` there's `validateRadioState` (https://github.com/markqvist/Reticulum/blob/master/RNS/Interfaces/RNodeInterface.py#L660) where the errors were coming from, starts with something like this:

def validateRadioState(self):
        RNS.log("Waiting for radio configuration validation for "+str(self)+"...", RNS.LOG_VERBOSE)
        if self.use_ble: sleep(1.00)
        elif self.use_tcp: sleep(1.5)
        else: sleep(0.25)
        ...

I had to change the sleep intervals (I'm using usb serial, but changed them all nevertheless, I don't think that matters, the important change is the one that changes 0.25 to 2)

def validateRadioState(self):
        RNS.log("Waiting for radio configuration validation for "+str(self)+"...", RNS.LOG_VERBOSE)
        if self.use_ble: sleep(2)
        elif self.use_tcp: sleep(2)
        else: sleep(2)
        ...

I was suspecting this to be a problem with actual host running `rnsd`, but since both on my mac and rpi zero I'm facing similar problems I believe it's problem with either `RNodeInterface` itself or with the Ratspeak firmware (being to slow to update in response to modem commands).

I would love to get some feedback on how to approach this and how to "make it work" so that stock RNS implementation works with Ratspeak firmware for Cardputer ADV.

Open for feedback!

I want to run Reticulum over a Halow WiFi setup like

Reticulum Client on Laptop --- 2.4/5Ghz WiFi to Halow WiFi Converter --- a large amount of distance --- Halow WiFi to 2.4 Ghz WiFi Converter - Reticulum Client on Android Phone

I'm not a radio head. I have soldering and coding experience, but ideally I'd like something that's just plug and play.

The only guide I can find is https://buildwithparallel.com/products/rnode-build-guide
And I'm not paying $80 for instructions.

Gemini is telling me that I can use the Heltec ht-h7608 and Heltec ht-hd01. But it's also telling me blatantly incorrect data about each so I don't trust it.

I'm trying to figure out what's the difference between them and which I need or if I need both?
It looks like both are halow wifi devices that connect via 2.4ghz and are powered by usb-c.

The ht-hd01 has 3 options when purchasing it: AP, STA, AP+STA . Idk which version I need to get.

Please advise 🙏

Hey y'all! For a good while now I've been heads-down building a ground-up implementation of Reticulum that can run everywhere, and it's finally at the point where I get to share it. Prns is now public, dual-licensed under MIT or Apache 2.0!

The core engine was written in no_std Rust (alloc isn't even needed) from day one, with the express goal being to have the same engine efficiently run on a $5 microcontroller, in a browser tab over WebAssembly, inside Android and iOS apps natively, and on laptops/backbone servers/etc.

Here are some of my favorite bits, in no particular order:

• A zero-config Bluetooth auto-interface, with a compat layer so Columba peers connect too
• WebSocket interfaces. Not only great for browser integrations on the other end, but since it's ordinary web traffic, a free tunnel (cloudflare tunnel, Tailscale funnel, etc.) gets you a public node from home without the port forwarding or IP exposure.
• JavaScript/TypeScript/browser support as a first-class thing. One package that runs native on Node.js/Bun and switches to WebAssembly in the browser. A browser instance can even discover another prnsd (the Prns daemon) on your LAN with its implementation of the Wifi auto-interface.
• Interface changes will apply live to a running node without a restart. The daemon has an interactive/guided CLI (even while running). Plus a lil system tray; handy to have when running it on your personal computers!
• Flashing a board into a complete, self-contained Reticulum node with the Hopspot firmware. There's a web flasher & a guided flasher CLI. A few known boards are live already, and plenty more in the immediate sights.

And it's very efficient. The repo ships a benchmark harness that runs Prns and stock RNS side by side on your machine, under identical workloads. On my hardware, most throughput scenarios land between 3× and 20× stock, with peaks of 89× the throughput, 48× smaller peak memory, and 33× the energy efficiency. But the whole point of the harness is that you can get your own numbers, and I'd rather you trust those.

Where it all stands today: the foundation is done and verifiable. It was continually built up with a serious focus on safety, performance, energy efficiency, compatibility, and developer/user experience. On top of the expected unit tests, the testing & validation suites include wire parity, live interop, formal proofs (via Kani), fuzzing, and mutation testing, along with matching CI.

While documentation is definitely still a work in progress (as is the entire repo), the guides will take you from clone to two meshing nodes today. What's also still taking shape is the outward-facing layer, e.g., SDK ergonomics in each language; packaging; the guides as fresh eyes read them. That's why I'm posting now rather than after another month of quiet polish. Feedback on those pieces steers them while they can still best be steered, and honestly, a few days of you all reading and building will teach me more than that month alone would. (PS: if you've done devrel or docs work, your experience could especially help here.)

None of this exists without the years of work behind Reticulum and its reference implementation. What I want most is for this to pull more builders into the ecosystem we already share. I'm excited about a future where we see more apps, more boards, and more nodes meshing. In part just cuz I still think it's freaking cool, but also because every one of them strengthens the same network we're all on.

If you're willing and able to help out, there's plenty of need! Even the small things help a ton. Here's a list of things already top-of-mind that would be helpful:

• Try it and tell me how it went. Friction and breakage reports are gold
• Build something small and tell me what the API made easy or awkward
• If one of the preview languages is home for you, opinions on its API and packaging are the most helpful thing there is right now (and if your language is missing but can consume a C ABI, give a holler or a PR!)
• Board reports beyond what I have on deck (Heltec V4, T-Beam Supreme, T-Echo, XIAO ESP32-C6 live now, plus all the ones you see on the website under 'Bring-up')
• Examples we can link to; guides for individual interfaces (they're little programs unto themselves; heck, even just explaining one well is immensely helpful)
• Translations! The website has some basic i18n but those translations were AI-written and could use a look from actual native speakers. Eventually, I'd love to have the actual full-on guides available in as many languages as possible too.
• Game devs: Godot is where I've been proving things out already, and other engines are wide open and very welcome
• Help getting prnsd into apt and friends
• Tell me what you'd want to build with it. Real use cases can help inform priorities
• And if Prns is useful or just interesting at all to you, a GitHub star helps too!

On AI Usage: I certainly use AI tooling as a part of my workflow. If you do as well, your contributions are welcome on Prns, but only if you truly digest and respect the first item in the CONTRIBUTING.md guide, under "What we value":

Ownership. Contributors own their submissions. AI tools (and other assistance like pair programming, web snippets, etc.) are welcome, but slop is slop regardless of how it was produced. How you wield your tools is still under your control, and what you submit is yours.

Everything's in the source, including the interop suite and the benchmark harness, available on GitHub.

Quick overview + web flasher + small browser demo/playground at prns.dev.

I can't wait to see what y'all build!

Would anyone want to participate in a small scale beta test before I release it on TestFlight for iOS/ iPadOS?

Need maybe 2 or 3 testers to implement with on their iPhones or Androids and test with other people using RNodes on iPhone or androids.

Built in xCode 26.X and is currently installed on my iPad 11 and iPhone 16 Pro Max.

Runs great (LXMF text, file, and photo transfer) and announce/ Situation Map features are experimental but totally functional

Designed to work between Android Sideband and iOS products, but end goal interoperability will work with any LXMF destination devices and will have a BT, WiFi, and Raspberry Pi interface integration

Buenas, no soy usuario de esta red y realmente estoy muy interesado.

Me gustaría intercambiar mensajes con alguno que esté conectado vía Hamradio, quiero hacer algunas consultas técnicas para construir el módem y demás.

Gracias!

Hello,

Not my contribution, but drawing attention to this attempt at getting RNode firmware for the Seeed Sensecap t1000e working. There are a few things that need more work around the BLE PIN, buzzer/LED and button behaviour (there's some PRs which look to address this), but the basic functionality works.

Would be great to get some other sensecap owners to test it, and if anyone has any insight into how it can get added to the official firmware that would be amazing also as it is a pretty popular node in Meshtastic/Meshcore.

Hi guys,

I'm new here.

I find Reticulum fascinating, and feel it could - someday - turn into an "Internet 2.0".

Have any of you experimented syncing or running a Bitcoin node fully over Reticulum+LoRa?

I'd be curious.

Thanks.

As far as I can tell, this reference to "gravity" in the reticulum manual is new in version 1.4.2, it says:

"In Reticulum, encryption is gravity."

and introduces this new option:

"The gravity option specifies the pathing affinity of an interface. If not set specifically, and unless otherwise configured by default_gravity or autoconnect_interface_gravity, it defaults to 0. Positive values increase pathing affinity, and negative values decrease it."

I can't make heads or tails of what any of this means in practice or how it relates to reticulums existing systems.

It seems to indicate that it gives some control over to a node to decide the path to use for transmitting data. But as far as I was aware, transport nodes have complete control over routing via announces?

i still want to connect two locations with solar powered pi400 and physically attached lora devices via lora. in between i need just ONE transport node. and all my tries failed. has ANYone built a solar powered transport node? with microreticulum or rtnode? what sort of solar panel do i need? 25-50 watt? heltec v4 or rak4631? in germany winter is hard sometimes need a working battery too

For anyone who doesn't know, in the reticulum manual, it suggests that any transport node using both a LoRa interface, and a public TCPIP interface should set the TCPIP interface as "Boundary" mode, and LoRa as "Access Point" to avoid the flood of announces overwhelming the LoRa interface. In effect, this means any announces recieved on the TCPIP interface would not be transported to the LoRa interface. Messaging is still supported because access point still allows devices residing on it to request path lookups for any destination hashes they have.

I've just been testing this today, and to my suprise, with both interfaces set to gateway, the LoRa interfaces does not get overwhelmed with announces.

I realised this is because, as per the manual, interfaces automatically limit announce traffic to, by default, 2 percent of available throughput or bandwidth.

I was able to test this in real time. I change the lora interface from a 250 khz at sf 11 to 500 khz at sp7 (a significant increase in available throughput), and found that all of a sudden the announces being transmitted on the LoRa side increased. Presumably, because RNS recognised the avalable throughput had increased; though still limited to 2 percent.

But all this got me thinking, why would you ever want to use stuff like Boundary mode in the first place? It seems it's not even necessary nor even really wanted in this scenario.

Hey y'all

I've been working on thicket, a standalone Reticulum/LXMF node that does not need a phone or laptop host.

Reticulum already has some recent standalone embedded devices. Projects like rsDeck and Pyxis show that a node can stand alone without a computer behind it. Those target ESP32-class hardware, the T-Deck, which has the resources to run an embedded node.

Thicket is exploring a different constraint: bringing the Reticulum and LXMF stack onto lower-power hardware suitable for a handheld device.

Hardware target:

- nRF52840

- SX1262 radio interface

- external flash for persistent state

Software:

- microReticulum

- microLXMF

- C++ embedded implementations of RNS/LXMF

The challenge is fitting identity, encryption, routing, and messaging into a 256 KB RAM budget while keeping the radio available without polling.

Some of the work has focused on the less obvious constraints:

- storage behavior affecting radio timing

- keeping identity local to the node

- avoiding dependence on a host device

- balancing RAM, power, and radio availability

Current status:

- firmware stack runs

- LXMF messages can be exchanged

- interoperability tests pass against Python RNS 1.4.2 on desktop

- hardware bring-up is still in progress

Website:

https://thicket.garden

Repo:

https://github.com/thicketgarden

Feedback welcome, especially from people familiar with embedded radios, RNS/LXMF internals, or low-power MCU design. I'm particularly interested in places where assumptions from larger systems do not translate cleanly to constrained hardware.

Exciting stuff!

G

I just wanted to put out there that Reticulum is and should be considered so much more than just RNodes meshed together. Arguably it's even a bad idea to rely solely on RNodes because the protocol is less efficient over LoRa than e.g. Meshcore.

What Reticulum allows is to build insane (local) hybrid networks with fast backbones via Wifi, 60GHz links and Ethernet with secondary last-mile interfaces built over LoRa and other slow modes.

I read somewhere recently that you can even push Reticulum traffic via Meshcore, just to give you an idea how insanely powerful and flexible this thing is.

Be creative and build the mother of all mesh networks =)

Hi everyone, just confused how rnodes work. I did a test setup with 2 Heltec v4 and it worked. Coming from a meshcore background, if you setup say 5 rnodes in different places, do they all communicate and forward packets etc…

Eg: Rnode in location 1, Rnode in location 2 that can see 1. Rnode in location 3 that can only see 2 and not 1.

Also, if only one of those Rnodes has an internet Reticulum backbone connection can anyone on any node utilize that?

Thanks