# 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. --- ## Reply 4 **OK2UFO** · Thu, Nov 5, 2026 12:26 PM Thank you so much for the explanation! I'm still relatively new to Reticulum, but I think it's an amazing project, and I'm really rooting for it. I'll wait for the official release. I've tested as much as I could and shared the issues I've encountered in real-world use. I use and experiment with almost all the available clients. Some are great for testing, while others are more user-friendly. Personally, my favourite is MeshChatX, so it's a shame that its development is coming to an end. What matters most to me is having multiple functions in one application: LXMF, NomadNet, RRC, the ability to send messages via opportunistic, direct and propagation node delivery, and other useful features. As for Ratspeak, I had no idea about the background and philosophy behind the project. Unfortunately, things like this seem to happen quite often with larger open-source projects — MeshCore comes to mind as another example. What really matters is that you've dedicated more than ten years of your life to developing Reticulum, and we recognise and appreciate that. You've created an amazing network with enormous potential. If someone chooses to exploit that work, that's their karma. Thank you again for everything you do, and I wish you all the best! --- ## Reply 5 **NONGKHAEM_BKK_TH** · Thu, Nov 5, 2026 12:50 PM > 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. For those not aware, Ratspeak is even worse than that - they literally TAG their packets so they can provide 'privileged access to the RNS network' for 'token holders'. It's a promise they made to the fools who dumped 6 whole million dollars in this. This is literally black on white on a hidden link on their [website](https://ratspeak.org/portal.html#identity\). But it gets even worse: they have convinced at least one client builder, Colorado MeshClient and their whole community to LOCK their client software to ONLY be able to use the ratspeak vibecoded clone of RNS. That's right - on every other client (MCX,sideband, whatever), you can opt to run RNSD under the hood to handle the protocol layer - but not for Colorado MeshClient, which is hardlocked to Ratshit, i mean Ratspeak. And wait, it gets even worse! They are purposely holding back their implementation of the protocol to an older version, so that over time, they can break off clean with the 'mainline' RNS, so that they execute the fork they fervently dream off on their Telegram. By having 'better' marketing, flashy websites, and paid shills to advertise ratspeak, they hope to simply 'become' the protocol. No need to innovate: just hold back and wait for the inevitable backwards incompatibility then claim victory by having more users - hence the tagged packets. If this reminds you of crypto, that's because it is, and the author of this mess, "DefiDude" (a wannabe cryptobro from Twitter) was very open about it during launch, calling for 'Community Takeover' and other niceties while using multiple alts of course. I did my research, brought to the MeshClient authors, and they claimed it's totally innocent, and Defidude himself replied to me, making the claim he donated "money to Mark" and "radios to the community" (not-so-subtly hinting he thereby 'bought' the rights to do all this), and that he was 'forced' to do this by the evil crypto people, of which he totally isn't one of them, pinky promise, he swears. Absolute insanity. It's crazy to me that we get to see a VERY dark side of human beings when involving ourselves in what should just be a fun tech project, but here we are. --- ## Reply 6 **dude.eth** · Fri, Nov 6, 2026 6:21 PM **NONGKHAEM_BKK_TH** wrote: > > 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. > > For those not aware, Ratspeak is even worse than that - they literally TAG their packets so they can provide 'privileged access to the RNS network' for 'token holders'. It's a promise they made to the fools who dumped 6 whole million dollars in this. This is literally black on white on a hidden link on their [website](https://ratspeak.org/portal.html#identity\). > > But it gets even worse: they have convinced at least one client builder, Colorado MeshClient and their whole community to LOCK their client software to ONLY be able to use the ratspeak vibecoded clone of RNS. That's right - on every other client (MCX,sideband, whatever), you can opt to run RNSD under the hood to handle the protocol layer - but not for Colorado MeshClient, which is hardlocked to Ratshit, i mean Ratspeak. > > And wait, it gets even worse! They are purposely holding back their implementation of the protocol to an older version, so that over time, they can break off clean with the 'mainline' RNS, so that they execute the fork they fervently dream off on their Telegram. By having 'better' marketing, flashy websites, and paid shills to advertise ratspeak, they hope to simply 'become' the protocol. No need to innovate: just hold back and wait for the inevitable backwards incompatibility then claim victory by having more users - hence the tagged packets. > > If this reminds you of crypto, that's because it is, and the author of this mess, "DefiDude" (a wannabe cryptobro from Twitter) was very open about it during launch, calling for 'Community Takeover' and other niceties while using multiple alts of course. > > I did my research, brought to the MeshClient authors, and they claimed it's totally innocent, and Defidude himself replied to me, making the claim he donated "money to Mark" and "radios to the community" (not-so-subtly hinting he thereby 'bought' the rights to do all this), and that he was 'forced' to do this by the evil crypto people, of which he totally isn't one of them, pinky promise, he swears. > > Absolute insanity. It's crazy to me that we get to see a VERY dark side of human beings when involving ourselves in what should just be a fun tech project, but here we are. I don't think it's all that deep. Not to mention, a good amount of this is literal misinformation. I mean, tagged packets? That's just... not how it works. And you are going on about "community takeover" again which perhaps you didn't understand the context, and suggesting claims like "purposefully hold back [the implementation]", and "convinced [Colorado Mesh]", even that we want to "become" the protocol? Excuse me, what? I mean these claims are all false and just assume ill-intention while ignoring reality. It's hard to engage with, I tend to operate on facts/logic. Even the token, I didn't launch it, but that's hardly a point that matters (the person who did launch it, is public, and has said so, by the way). By "embracing" the token, it was a matter of taking "free" money which was already on the table to claim, of which yes, has also been used to donate to support upstream. And no, it does not pay for the right for anything like you've suggested. I've known where Mark stands on Ratspeak, even before his post above. It doesn't change my willingness to donate to support upstream. If Mark wants to have a serious conversation with me about Ratspeak, he can reach me by the e-mail he has. If he would like something that makes it easy to evaluate interoperability between Ratspeak/rs* and Python, more outbound links to Reticulum rather than just docs explaining Reticulum - I'm happy to do that. But I'm under the assumption that hearing anything from me is met with a sour reaction, so I haven't bothered trying to soothe. I have been compared to Voldemort here (lol), and told to "fuck off already", so yeah, I'm not exactly keen to jump on here and talk about Ratspeak or defend myself from misinformation or vitriol-fueled trolls like today, but I'm making an exception because of licensing. I am not asking you to use Ratspeak, I don't post here to talk about it, and I spend 12+ hours behind my screen a day on this "vibe coded mess", full time, going on a year+, but yet somehow this makes me a "VERY dark" human. I implore you to come talk to me, instead of running from me to whatever circle to spread lies. I am very accepting of receiving shit, just not when it's based off logical fallacies. I didn't talk to Colorado Mesh or tell them to use anything. They do what they want (which, is part of the problem, there is another community building off an old version of Ratspeak and not being reciprocal to me suggesting they need to make security updates/stop). In fact, since you mentioned the Telegram, you'll know that in cases where it's raised, I always suggest upstream Python/Mark's implementation as being the source of truth and what to rely on/dev on. As for licensing, which is the reason I'm deciding to actually reply: that is something I will engage with - I don't take the idea or accusations copyright infringement lightly, nor ripping OSS, so obviously the intention is always compliance. I will be making license adjustments ASAP, and in the future, would invite Mark to reach out via e-mail if he has a concern or an issue. He is not shy to speak out, so I'm surprised it took this long to hear from him. I'm a reasonable person, but if you don't approach me, and then paint me to be someone I'm not, of course you'll only have that picture. You can always just ask me things, you know. Anyway, that's all, I will not be replying to this thread further. Those that need or want to reach me can figure out how (ask Malfoy maybe). Licenses should be adjusted by EOD, but I'm horrible at timelines, so hopefully by Sunday the latest. And Mark, if there's anything further I can do to make it feel like your decade of efforts aren't being stolen, besides the snarky idea of outright quitting, then I'd be happy to receive your e-mail about it. I'm not here to be agreed with or get along, but I do care about compliance and respect. --- ## Reply 7 **Mark** · Fri, Nov 6, 2026 7:28 PM The only "stand" I have in regards to ratspeak is the license violations and copyright infringement, anything else, I have not (yet) personally researched or gathered enough detail to say anything meaningful about. The license violations though, as they stand, are severe enough. When I have not reached out to you personally yet, it is because I am still considering whether to do so through the legal system directly, or through an initial attempted personal dialogue. I have a lot of actual work to do, and tend to prioritise that which actually benefits the community, and let the legal squabbles wait their due time. If you actually "know where I stand", I'm quite suprised that *you* have not contacted me, or at least just attempted to fix the license problems on practically all of your repositories relating to ratspeak. If this is all really just a blunder on your part and missing knowledge about how open source licensing actually works, I'd suggest you read Void Grants: https://github.com/markqvist/Reticulum/blob/master/docs/history/2026_09_21_Void_Grants.md And from there consider what the best course of action would be for you now. You have my contact details, ball's in your court. I'm a relatively relaxed and patient guy, but not forever. --- ## Reply 8 **Mark** · Fri, Nov 6, 2026 7:34 PM And in case it wasn't clear from the above, I mean that honestly, of course. I'd be happy to help you understand how to actually comply with the licenses, if things are confusing. I do suggest you read the linked text about the legal foundations, though. It's pretty essential to know, and it's not too boring, actually. --- ## Reply 9 **Mark** · Sun, Nov 8, 2026 11:56 AM For the record of anyone reading this in the future, @dude.eth immediately contacted me after understanding that there was actually a problem with the licensing, and corrected everything very swiftly and efficiently. As a result, all of the Ratspeak repositories and software are now in compliance with the source licenses, and we have worked out a solution for the LXST derivatives as well, which means that Ratspeak is now using LXST under a proper license, specifically granted for that purpose. After speaking with @dude.eth, I also understand his motivations and approach better, and my "entirely vibecoded mess" and "idiot" comments were an overreach that came from extreme fatigue with the entire situation in general, not actual knowledge of the Ratspeak project. I retract those comments, and apologize. Seeing how @dude.eth handled this, it becomes much less of a "disaster", and much more of a good example on how to correct a mistake, that others can learn from. We all make mistakes, myself included. Correcting them honestly is what matters. --- ## Reply 10 **OK2UFO** · Mon, Nov 9, 2026 10:31 AM I'm really glad to hear that you've reached an amicable resolution! By the way, I've just been testing Sideband 2.3.0, and everything seems to be working as expected now, even with "from_static_only=yes" enabled on the LXMF Propagation Node. Longer messages and images are now successfully stored on the propagation node and can be retrieved without any issues. Thanks so much for your hard work! ---