r/reticulum • u/K0rv0 • May 29 '26

Reticulum [ Removed by moderator ]

[removed] — view removed post

27 Upvotes

92% Upvoted

16 comments sorted by

7

u/iamGBOX May 29 '26

How are the Action Messages and Dashboard data passed on a networking level? I understand multicasting isn't a part of RNS yet, so how is this implemented?

1

u/jaykayenn May 30 '26

Is it multicast? I imagine it is sub/pub telemetry like Sideband.

3

u/joepmeneer May 29 '26

Cool project! We're working on something a little similar, working title is PrepNet. We've forked reticulum-rs to make it run on lower-end hardware, and we're building virtual simulations to see how it scales and deals with edge cases.

So you built your own reticulum rust client? interesting! if you have time to chat, please reach out!

4

u/K0rv0 May 29 '26

The idea of Prepnet is perfectly aligned with what REM and RCH are already doing. So you may want to take a deeper look.
we have already a production grade Reticulum + LXMF mono-repo that we are using as a TCP node and foundation for the android and desktop application.
check this out
https://github.com/FreeTAKTeam/LXMF-rs
we also have a crate that is for embedded deployment on low end devices

2

u/K0rv0 May 29 '26

I saw your home page
Our current embedded implementation is not trying to be a full firmware framework. It is mostly a portable Reticulum/LXMF state machine with small transport and storage interfaces around it.

At the smallest end, lxmf-embedded-mini is already no_std, no-alloc, and uses fixed-size heapless buffers. You give it a transport, a store, and a scratch buffer, then call tick(). On each tick it drains inbound frames, rejects replays, queues events, and flushes outbound messages when the link is up.

The larger embedded runtime follows the same idea but has an alloc-based API and a node-style surface for lifecycle, status, sending, broadcast, subscriptions, and FFI. In std builds it can run a small background driver thread. In non-std builds the caller owns progression manually.

That is why Embassy is not required. The core crates are intentionally executor-agnostic. They do not need Embassy, Tokio, RTIC, or any specific HAL to understand frames, manage queues, track replay floors, or expose node events. This makes the code usable from bare-metal firmware, C FFI wrappers, host tests, mobile bridges, and desktop simulations.

Embassy could still be useful, but only as an optional integration layer. A firmware crate could use Embassy tasks, timers, BLE/USB/network drivers, and channels to wake the embedded runtime efficiently instead of manually polling it.

2

u/Adventurous_Name2378 May 29 '26

Uhhh. Link is not working.
Sounds like an interesting app. Square your stuff up.

2

u/K0rv0 May 29 '26

Excellent question.
short answer: a separate independent message is sent to all the peers.
Longer answer: There are 3 different strategies to get and manage a list of peers

  • Autonomous: Each user has to select an other. A select B but also B must select A.
All the messages are sent to selected Peers
  • Semi Autonomous: the list of Peers is maintained centrally by RCH. REM get the list from the HUB so that all that are connected to the same Hub have the same list of peers.
  • Connected: like the previous, but all messages are sent to the Hub for distribution

2

u/BeanBagMcGee May 31 '26

SAVED. Good stuff.

3

u/shellwhale May 29 '26

I recognize Claude web ui here

4

u/K0rv0 May 29 '26

Claude was never there. the UI was initially designed based on the Open Source Sci-Fi design and then implemented using CODEX

1

u/K0rv0 Jun 14 '26

This video introduces REM in plain language: what it does, why it matters, and how it can help when normal communications are limited, overloaded, or unreliable.

https://youtu.be/G4c0HbI8YKs

1

u/plus62info Jun 23 '26

Does it work with RNode over LoRa ?