rns.recipes

My plan is to create software, interacting with Reticulum. A remote control for an art project. A standalone, custom network visualizer. And more.

I already have my Python rns daemon running. I don't need a separate node.

So I want to create rns "clients" / shared instances?

The problem is, my language of choice is Rust and there are a "couple of" crates. But I have good reasons against all I have found so far.
BeeChat and FreeTAKteam are to kill humans. I don't want to be part of that. I respect the right of Ukraine to fight against an invasion. And I can understand, they don't care about us and just use any advantage they can get. But I don't want to be part of that.

Then the vibe-coded AI slop. Doesn't matter, how good they say, they can handle it. I don't want to be part of that either.

And there are projects, which suffer from burnout or will soon.

I don't need a core. I just want to have a "micron page in memory instead of the ssd" / Rust interacting with simple python code. Would that be a LXMF client? Or even simpler?

Or a passive listener to incoming announces. Which would be something completely different? Or quite the same, because both need to interact with the rns daemon?
The encryption is happening in the daemon? Or is it such an essential part, it needs to be handled outside already?

Are there existing projects, where I can see some examples?
How difficult would it be to write such from scratch? Which parts are necessary?

Sounds like a good amount of work. Going to read a lot of Python code. A couple of good hints could reduce time needed. It might be months or years nonetheless.

You could just make a rust port, where all it does is call the python impl with the rust code only acting as a glue or binding layer to the python api. It would be the easiest thing to do plus you'd get 100% parity by default. And unless you are doing some truly disgusting things on the network, it'd be fast enough.

If that's actually a useful or good idea I'll leave as an exercise to the reader but I do think it would, at the very least, be ironic given the prns situation.

Decided to read source code of utilities first.
Aleph Git -> reticulum -> reticulum -> Files -> RNS -> Utilities
a8d24177d946de4f1f0a0fe1af9a1338:/page/tree.mu`g=reticulum|r=reticulum|ref=HEAD|path=RNS%2FUtilities

rnstatus is small and clear.

rngit covers a lot of examples.

PyO3 are the usual Rust bindings for Python as I learned. May experiment with it afterwards.

adept: I've started on a small Rust version of rns, but it's not ready yet. There is still a lot to do.

So far, I have a config parser implemented using serde and serini, structs/traits for interfaces, packets and transport. I was going for a roughly 1:1 implementation of Python rns

I was also considering developing my applications with pyo3 instead, before diving into making a Rust implementation. At the very least, using pyo3 would be a good idea for testing a Rust implementation.

Can I send you what I have over rngit? If you want I'll host the repository and send the destination.

h: Nice!

What you describe feels like the natural way to go. Would be interested in a look into the sources. And I suppose a lot of other beings, too.

Share whenever you want. Don't feel pressured, if you are not there yet. I know from my projects, how stressful a release can be.

Rngit is perfect. I love, how easy we can share projects without creating any account.

Like most in Reticulum. It is there, when it is there. And sometimes, it is not there. ;-)

Thanks

adept: I've been setting up rngit and having a lot of fun doing so. I'll send the destination when it's up, thank you for your patience

Another solution to one of my problems is unix sockets. Useful for the video mixer in Rust interacting with the Python code on my nomadnetwork node.

No files to write constantly or whatsoever. The micron page will just ask for an update and receive the current state of the video filter graph. Or push the updated variables.

After two decades of Linux, I will finally learn more about sockets. \o/
First tests are going well.

My node is up now: 0ff996e06ed8297fb199ed95e706d540:/page/repo.muʼg=h|r=reticulum_rs

The config parsing works and is mostly complete, but a few entries do not get parsed into the correct types yet. The rest of the code is mostly a skeleton. I've implemented some small bits and pieces.

anon wrote:

You could just make a rust port, where all it does is call the python impl with the rust code only acting as a glue or binding layer to the python api. It would be the easiest thing to do plus you'd get 100% parity by default. And unless you are doing some truly disgusting things on the network, it'd be fast enough.

If that's actually a useful or good idea I'll leave as an exercise to the reader but I do think it would, at the very least, be ironic given the prns situation.

I haven't touched or updated it in a while, but I did actually write a small rust -> python rns wrapper using PyO3: https://codeberg.org/kujeger/reticulum-pyrs

Might be of some use!

e: for something that uses it, there's this (also not updated in a while, heh): https://codeberg.org/kujeger/retichat

Thanks for all your hints and recommendations! There are quite a few solutions for one of my projects, a control panel for a video filter application.

I slowly close in on the correct terms. One of the things I am looking for is called inter process communication (IPC).

For now, I decided for two simple files. One of each for incoming and outgoing traffic.
On opening the page, the Python side sends/writes a reload request 'r'. Rust checks when the file has been modified and answers with writing the current filter graph to the other file.

Python in an .mu then loads the content and nomadnet displays the printed micron code.

The current filter graph data will still be accessible and useable for other subpages of the project until it is overwritten by a newer one again.

But also values can be changed and sent back from the nomadnetwork node to the video filter application. Just writing all the details into the outgoing file, which will be interpreted on the Rust side.

One problem is syncronization. But it could be handled separately.

1/2

But I don't even need Python for that.

You can add any executable file to your pages folder, rename it with a .mu extension and use its output for your nomadnetwork page.

When the page is visited, it will be processed and its output be sent to the viewer. And that does not need to be a script. ANY BINARY FILE ALSO WORKS.

'cargo new nn-test'
'cd nn-test'
'cargo build --release'

'cp target/release/nn-test ~/.nomadnetwork/storage/pages/nn-test.mu'

Add '°[Rust test°:/page/nn-test.mu]' to your index.mu (replace ° with the accent grave control character). Reload nomadnet, in case it is needed.

Done. \o/

May actually set up unix sockets for IPC now.

@h: Thanks. Great! Will look at it, once I can create a link to your node.

@kujeger: Interesting! I love how many beings started with their own projects. Will need a while but I will definitely check this out.