rns.recipes

I'm trying to operate an LXMF Propagation Node primarily as an offline inbox for members of an internal Reticulum network, while keeping it accessible through the global Reticulum network.

Network setup

Node A: Low-power, solar-powered Linux device running Reticulum. Its connection to the global backbone uses a boundary interface; LoRa and all private connections use internal.

Node B: Second Reticulum transport node connected to Node A over Yggdrasil using internal interfaces.

All other nodes in the private network use internal interfaces.

Both nodes run LXMF Propagation Nodes, configured as static peers with autopeer = no.

The problem

With from_static_only = no, the Propagation Node receives and stores thousands of unrelated messages from unpeered nodes on the global network.

Approximately 99.9% of the messages are irrelevant to our internal users. One node accumulated nearly 29,000 messages, although only a very small number were actually intended for our network.

This creates unnecessary storage, CPU, and memory load on a resource-constrained, solar-powered Linux device.

Even relatively high stamp costs do not seem to prevent this. It appears that a remote propagation node can generate a single peering stamp/key and subsequently transfer large batches containing hundreds of messages without performing new proof-of-work for every message in the batch.

With from_static_only = yes, the unwanted unpeered traffic stops. However, the Propagation Node then appears to become unavailable to all clients, including local clients on the internal network, despite the service running and its static peer remaining available.

Questions

Does from_static_only = yes affect only incoming propagation transfers from non-static peers, or can it also affect client access, message deposits, retrieval, or node discovery?

What is the recommended way to provide an offline inbox primarily for members of an internal/city Reticulum network, while allowing those same users to access it through the global network when outside local coverage?

How can we prevent the node from receiving and storing thousands of unrelated messages from unpeered propagation nodes without making it unavailable to legitimate clients?

Is it correct that a remote propagation node can transfer hundreds of messages in a single synchronisation batch using an already established peering key, without requiring separate proof-of-work for each message? If so, how should a resource-constrained node protect itself against excessive incoming batches?

What configuration or architecture would you recommend, considering the boundary/internal separation in Reticulum?

In short: How can I provide a globally accessible LXMF offline inbox for members of a private Reticulum network without continuously receiving and storing thousands of unrelated messages from unpeered propagation nodes?

Current LXMF configuration (Node A)

[propagation]
node_name = XXXXXX [LoRa/Ygg] LXMF PN
enable_node = yes
announce_interval = 60
announce_at_start = yes
autopeer = no
from_static_only = yes (no)
autopeer_maxdepth = 0
propagation_stamp_cost_target = 14
propagation_stamp_cost_flexibility = 0
peering_cost = 20
remote_peering_cost_max = 20
static_peers = xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
sequential_pn_stamp_validation = yes
auth_required = no
message_storage_limit = 4
propagation_message_max_accepted_size = 32
propagation_sync_max_accepted_size = 64
max_peers = 2
max_inbound_syncs = 1

[lxmf]
display_name = XXXXXX [LoRa/Ygg] LXMF
announce_at_start = yes
announce_interval = 60
delivery_transfer_max_accepted_size = 32

[logging]
loglevel = 3

Sorry for the long post. Thanks a lot.

That is a concern we have as well, with a propagation node running on the sailboat. Solar powered insofar the boat itself is solar powered, but bigger concern is data volume.

We're quite often on metered connections (LTE, Starlink ocean data) and then propagating thousands of messages irrelevant for the boat users is costly.

Problem is, the LXMF propagation protocol operates on message hashes, so there's no way to actually limit it to "I want only messages from/to this set of destination hashes".

The good part of this is that every propagation node is useful for everybody, but it does indeed become problematic in scenarios where resources are limited.

Right now we adjust stamp costs and retention limits when going on metered data, but as you noted, that doesn't help immensely.

At the same time, having a local on-boat LXMF propagation node is super useful as you can write messages whenever, and they'll propagate onwards when boat connects the next time.

In it's default configuration, LXMF will provide a setup that tries to help everyone on the network, and allow anyone to download messages from any node that has the resources to provide that service. The intention, though, is that it can also be configured for private/closed systems, if that is required.

With from_static_only = yes, the unwanted unpeered traffic stops. However, the Propagation Node then appears to become unavailable to all clients, including local clients on the internal network

Can you expand on this? Specifically what you mean by "become unavailable to all clients". Does message sync not work? There is nothing in the code that would disallow clients trying to download or put message if from_static_only = yes.

What does the logfile say when a client attempts to sync or send via the PN?

There definitely shouldn't be any problem with this, but if there actually is, I'm very curious to know what's going on.

But I'll need more data. The logs, and details on what clients you're using. Last time I tested a setup like that, it worked perfectly (lxmd instances, Sideband and nomadnet clients). I'm not saying that there couldn't be a bug or regression that broke something, but I did give the code a look-over, and I'm not seeing anything obvious.

So, more data please ;)

What is the recommended way to provide an offline inbox primarily for members of an internal/city Reticulum network, while allowing those same users to access it through the global network when outside local coverage?

More or less exactly what you've been doing.

Even relatively high stamp costs do not seem to prevent this

Looking at your config, a PN stamp cost of 14 is not very high. To avoid a lot of the spammy traffic, I'd set it to at least 17 or 18. That's going to cut out most of the chaff.

That being said, a number of broken nodes have started appearing on the network recently, most of them LLM-generated slopware, that don't respect the stamp requirements at all, or are simply so fundamentally broken that they don't even know what they are doing.

I've observed this as well, where "propagation nodes" connect, deliver 10K messages, and 80% of them will have invalid or insufficient value stamps. The real lxmd node will then signal to the broken node that it's throttled. All actual lxmd nodes will respect this, and not try to connect for the remaining throttle time, but these junkware things completely ignore it, and hey presto, twenty seconds later you have the same node connecting again, trying to deliver yet more meaningless messages. Of course, once the peer is throttled, lxmd will ignore such attempts - the link just gets cut if it isn't respecting the throttle timeout. But after it expires, it can try again.

Currently, the throttle time is not user configurable, unfortunately. I'll add it in the next release. Since all real LXMF PNs behave well and respect both stamp requirements and throttle times, even setting a several-hour throttle would be no problem, and keeps the junkware a bit more at bay.

Is it correct that a remote propagation node can transfer hundreds of messages in a single synchronisation batch using an already established peering key, without requiring separate proof-of-work for each message?

Yes, absolutely. That is intended design. Some nodes process tens of thousands of messages per day. If PoW had to be done per message, that would simply be impossible. LXMF is designed to be able to handle many millions of messages. The PN stamp system gates ingress into the distribution network, by requiring a work burden on the message emitter, while being as lightweight for the handling nodes as possible. That's the only design that can realistically work and scale.

For severly misbehaving nodes, you can blackhole their identities (remember, use the identity hash, not the destination hash). With a high peering key requirement, it gets expensive for malicious nodes to just create new identities and try again.

Now, I don't know how constrained your hardware is, but in your situation, I'd probably raise the peering cost to 26 or thereabouts, and the PN stamp cost to 18, if you even want random peering from the outside world. If you just want a closed system, that's not really necessary, of course. Just go with PN stamp cost 14-16, and set up the static peers you need.

Also, the upcoming RNS 1.6.x transition to network stamps will most likely improve all of this a lot, since stamps will soon be enforced on both destination creation, path requests and link requests.

Just ran a full test setup for your scenario. There is a regression, introduced during earlier performance optimisations.

I should have this fixed in the next LXMF release.

By the way, what hardware are you running it on @OK2UFO?

Thanks a lot for looking into this and reproducing the regression! Glad we found the problem.

I'm running two Reticulum transport nodes in different cities:

Node A – Brno: Milk-V Duo S running Armbian (Debian 13), Reticulum 1.5.7 and LXMF 1.2.1. It's a small solar-powered gateway with a RAK4631 RNode on 869.587 MHz (125Khz/SF8/CR5), a global TCP boundary connection, and Yggdrasil(+ifac) connecting it to the second city.

Node B – Bohumín: Debian Linux running in a virtual on my home server, connected to Brno over Yggdrasil using internal interfaces. I'm planning to add another RNode LoRa gateway here as well.

Both nodes currently run LXMF PNs as static peers, with autopeer = no and from_static_only = yes - static_peer.

Just to clarify, I don't mind people from the global Reticulum network using my PNs to store and retrieve messages. The problem is receiving thousands of unrelated messages from unpeered PNs. So far, from_static_only = yes seems to be the only way I've found to stop that.

I'm also having some trouble with missing public keys. I have three clients at the moment, two on the internal network and one outside. The boundary interface doesn't forward announces from the global network into the internal network, which is fine and intentional. But this also means that internal clients may not know the recipient's public key, and then they can't even submit a message to the PN in the usual way. Some clients don't seem to handle requesting the missing identity very well either. Or maybe I'm misunderstanding something here?

One more thing I noticed: sometimes even clients on the internal network couldn't properly upload messages to the PN. Restarting LXMF usually fixed it. Unfortunately, I didn't debug it at the time, but maybe it's related to the regression you found.

I'm testing with MeshChatX, Mesh Client and RatSpeak. RatSpeak has a few issues of its own – QR contact exchange doesn't seem to work reliably between clients, and sometimes it reports that uploading a message to the PN failed, even though the message actually arrives.

I'll give Sideband a try too. Not sure why I didn't think of that earlier :)

Thanks again for your work on Reticulum and LXMF!

Amazing. Great that the regression was found. Thanks for this report and for the work on the fix! I was also stuck wondering why my staticly peer'd pnode was not managing to transfer my messages. I can test the fix also with my setup.