# LXMF 1.2.1 – from_static_only rejects client Resource uploads _General · started by OK2UFO on Wed, Nov 4, 2026 8:14 PM_ Tags: LXMF --- ## Original post **OK2UFO** · Wed, Nov 4, 2026 8:14 PM Hi Mark, I'm running two LXMF Propagation Nodes (LXMF 1.2.1, Reticulum 1.5.7/1.6.0) Both nodes use: ``` - `autopeer = no` - `from_static_only = yes` - `static_peers` configured to include only the other PN - Message size limit: **32 KB** - Synchronisation limit: **64 KB** ``` I've noticed that short LXMF messages can be submitted successfully, but larger messages and image attachments fail when regular clients upload them to a propagation node. For testing, I used: - Short text messages – generally successful. - Longer text messages (approximately 5 sentences, well below 32 KB) – failed. - Small image attachments (approximately 10 KB, also below the configured limits) – failed. I've reproduced the issue using different clients, including Columba and Ratspeak, against the two propagation nodes. The server logs show: ```text Rejecting propagation resource from unidentified peer ``` And, when testing with Ratspeak: ```text Incoming link request ... accepted Rejecting propagation resource from <9446b5fc8962f93640adfa8e260f236a> not in static peers list ``` I also verified that the rejected hash belongs to my regular Ratspeak client, not to another Propagation Node. The client's identifiers are: - RNS identity hash: `65e307219b1a20197a72086ca958148e` - LXMF delivery destination: `607f5249256c52c8780d1e043046d914` - Calculated LXMF propagation destination: `9446b5fc8962f93640adfa8e260f236a` I calculated the propagation destination hash using `RNS.Destination.hash_from_name_and_identity("lxmf.propagation", identity)`, and it matches the rejected hash exactly. The client does not operate a Propagation Node. The hash is simply derived from its existing identity. The RNS links are successfully established before the Resource uploads are rejected. Ratspeak subsequently reports `Transport failed`. Looking at `LXMRouter.py`, the `propagation_resource_advertised()` callback appears to apply the `from_static_only` restriction to incoming Resources from regular LXMF clients, not just propagation peers. **Is this intentional behaviour?** My goal is to restrict PN-to-PN peering to explicitly configured static peers while still allowing regular LXMF clients to upload larger messages and attachments. **Is there a supported way to achieve this without disabling `from_static_only`?** Thanks --- ## Reply 1 **Mark** · Wed, Nov 4, 2026 11:14 PM It's a known bug (a regression that was introduced in an earlier updaet) and it's already fixed in the upcoming 1.3.0. If you're daring, you can grab RNS 1.6.0 and LXMF 1.3.0 from Aleph and try it out. But you *will* need the new RNS 1.6.0 also - don't try and run it without, it will crash, burn and explode in sparks. Also, these releases will migrate the old file-based storage to a new managed, SQLite-based store, so probably a good idea to take a backup of your config dirs if you try it out before the release ;) I'm laying the finishing touches on the releases now. It will probably run on the staging nodes for a few days before I'm completely satisfied, caus this has been an absolutely *massive* piece of work. --- ## Reply 2 **OK2UFO** · Thu, Nov 5, 2026 1:27 AM Hi Mark, I've deployed the latest development versions of Reticulum 1.6.0 and LXMF 1.3.0, but the issue with larger messages/images persists. I noticed that LXMF recently introduced the app_flag check for propagation resources. Could the problem be that existing clients haven't implemented this flag yet, causing the PN to reject their transfers when from_static_only=yes? Performance-wise, Reticulum 1.6.0 has been excellent so far! I haven't been able to fully evaluate the performance improvements in LXMF 1.3.0 yet, as I'm intentionally keeping `from_static_only=yes` to limit peering to trusted nodes. So far, everything else looks promising! --- ## Reply 3 **Mark** · Thu, Nov 5, 2026 10:51 AM Yeah, should have explained that a bit better. Clients will also have to be on LXMF 1.3.0 for it to work, it's exactly related to the `app_flag` being necessary for this to work. There's nothing additional required in the client applications themself, though. They just need to use LXMF 1.3.0, and it should work automatically. Currently, the only way to really test in clients is to install the source LXMF version, and run nomadnet, Sideband or MeshChatX with that specific local LXMF version. There'll be proper releases soon. I'm currently in the final testing phase, so we're almost there, and things are looking good. But if I find anything semi-strange that postpones release for additional testing, I may put out a pre-release build of the clients I'm responsible for so it can be tried out fully a bit earlier. Regarding ratspeak; it's an entirely vibecoded mess, don't expect it to work in any reliable way. The idiot "responsible" basically cloned RNS using LLMs, launched a crypto token around it, broke the open source license of RNS, and then triumphantly claimed copyright and release under his own "license". The person making it basically stole more than a decade of my work, wrapped it in flashy websites and GUIs (again, all LLM-generated), while trying as much as possible to hide the fact and not even *linking* to the *actual* Reticulum and RNS resources. He owns (much less understands) none of that system. It's a disaster, and I don't have much good to say about crap like that, other than I'd personally recommend you to stay far away from it, if you value security and reliability. ---