r/reticulum

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?

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

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

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!

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 🙏

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!