Skip to content

Conversation

@contra-bit
Copy link

@contra-bit contra-bit commented Jan 12, 2026

This PR adds daemon functionality to reticulum-rs, making it possible to run a standalone Reticulum node configured through standard TOML files. I've been running this as my transport node for the past three weeks without issues.

What works right now

The daemon reads Python Reticulum-style configuration files (after conversion) and initializes TCP and UDP interfaces. I can confirm TCPClient, TCPServer, and UDPInterface all work reliably in production. The other interface types (AutoInterface, I2PInterface, RNodeInterface, etc.) parse correctly but log warnings since they're not implemented yet.

The configuration format problem

Python Reticulum's config format isn't actually valid TOML, even though it looks like it should be. It uses syntax like [[Interface Name]] with spaces, writes Yes/No instead of true/false, and leaves string values unquoted. Standard TOML parsers reject this, which is why I've included a converter tool.

If you have an existing .reticulum/config file, you'll need to convert it first:

cargo run --example convert_config -- ~/.reticulum/config

This creates a backup and rewrites your config in valid TOML. It preserves all your settings and comments, just fixes the syntax. The converted format looks like:

[[interfaces]]
name = "TCP Server Interface"
type = "TCPServerInterface"
interface_enabled = true
bind_host = "0.0.0.0"
bind_port = 4242

How it finds your config

The daemon searches in this order: ~/.config/reticulum, ~/.reticulum, /etc/reticulum. This follows XDG conventions and makes it easier for distro packagers to provide system-wide defaults in /etc while users can override with their own configs.

If no config exists, it creates a minimal one at ~/.config/reticulum/config.toml with a TCP server on localhost:4242.

Open questions

Which options should the Kanoic Interface have?

Several design decisions came up during implementation that would benefit from community input. I've opened separate issues to keep discussion focused:

None of these block the current functionality, but feedback would help guide future work.

Testing

Beyond my own three-week run as a transport node, I've verified the conversion works with configs from rnsd --exampleconfig and tested that all three implemented interface types work as expected. The daemon handles interface failures gracefully and logs at appropriate levels.

This is a significant milestone since it makes reticulum-rs usable as a drop-in replacement for the Python daemon in real deployments. Looking forward to feedback and suggestions.

@squidink7
Copy link

When I tried using the config converter it replaced No with false however for whatever reason my old config had None which was replaced to falsene which then threw an error.
Also the official rnsd also has a flag to allow providing a custom config path (--config) which could also be useful here.

…onversion

The regex crate is needed, it would be very hard to match all edge
cases, such as `falsene` bug. I have decided against clap until further
arguments become necessary in order to not further add more crates.
@contra-bit
Copy link
Author

When I tried using the config converter it replaced No with false however for whatever reason my old config had None which was replaced to falsene which then threw an error. Also the official rnsd also has a flag to allow providing a custom config path (--config) which could also be useful here.

I have added a config path parser and now correctly detect the use of None.

The TOML specification does not allow for None values. This is why I have decided to comment out None values. Does this make sense for your use-case? Can you think of any example where setting the value None to a key has a semantic meaning?

@squidink7
Copy link

Nice! I think that should be fine, I wasn't exactly sure what the None values were doing in my config, it was just one that had been recently generated so I didn't mess with it until converting but commenting out should be fine.
Also the config path option is great, though a --help flag would also be useful for documenting the program usage/options.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants