# MeshChatX v4.10+ and beyond _General · started by Ivan (Web) on Mon, Oct 5, 2026 4:49 PM_ --- ## Original post **Ivan (Web)** · Mon, Oct 5, 2026 4:49 PM **Update 14 October**: MeshChatX will reach end of life on January 1st, 2027 see below for further details. MeshChatX v4.10.1 is out if you haven't updated yet. New logo, I have improved the styling to work better with custom themes, and improved UI/UX. Please let me know if you have any suggestions or feedback. The website has been updated as well https://meshchatx.com/ and works with older and no-js browsers by taking you to https://meshchatx.com/legacy. There is also a torrent for MeshChatX releases currently being webseeded by the CDN and GitHub releases; make sure to use a VPN if you don't want your IP being exposed to peers. More improvements and fixes coming for the new translation system, better RNode support, android improvements, and finishing the alpha tools and extension/plugin system. I also found out about https://github.com/dockur/macos so I can test MeshChatX builds on macOS properly now, for the intel side of it at least. The translation system uses Bergamot Translator in WASM, the models are fetched from https://mozilla.github.io/translations/firefox-models/ or you can upload your own. Edit 1: fixed the firefox models link. Edit 2: Removed planned features due to EOL (see below) --- ## Reply 1 **NONGKHAEM_BKK_TH** · Tue, Oct 6, 2026 2:31 AM I really, really hate to be 'that guy' but as you know I raised 20 bugs to date so I have reasons to provide this (hopefully constructive) feedback: You need to: 1. feature freeze for 3 months 2. stop relying on Claude and LLMs so much 3. conduct VERY serious testing as to what MeshchatX actually does on the network 4. stop adding 'features' that extend the protocol indirectly Allow me to elaborate: You maintain what I believe is the of the most popular client/server combo for rns. You therefore have a responsibility to make sure both are very well behaved and **beyond wire-compatibility**, make sure both respect the ethos of the protocol. - As you know I reported some hair raising bugs including https://github.com/Quad4-Software/MeshChatX/issues/125, where MeshchatX was dumping 15 gig of traffic overnight due to aggressive RCC reconnects. The outcome was a fix that was prompt (48h) but this should never have happened in the first place. **Casually DDoSing the network, even indirectly, is not okay**. And if I didn't raise this, we both know it would have gone unnoticed because MeshchatX users are most likely regular folks who assume it works as intended, and not semi-autistic nerds like myself with a penchant for packet sniffers. - MCX feels very vibecoded and very poorly tested, it becomes very evident when users start submitting bugs and an LLM replies on the other end. The bug above, instead of being taken seriously and causing a serious rethink of the approach, was closed with *"Backend fault-injection suite covers malformed RRC wire traffic, reconnect timer storms, hub store corruption, page-node rescan failures, crawler garbage inputs, link-cache teardown errors, and callback exceptions”*. - I can't prove it and I don't want to make accusations, but the above sounds like Claude, not Ivan. The speed at which it was deployed alongside four other fixes leads me to think (without proof, so feel feel to correct me) that you just throw Claude at the issue repo and let it hack it and rebuild after it conducts some form of automated testing. - On extending the protocol indirectly while maintaining wire compatibility, I'll make a proper write up on the topic because MeshchatX is not the only one guilty of this. In general, please don't expand the feature set with proprietary features, such as reactions. They look harmless, but they are not. For example reactions send 'empty messages' to other clients such as sideband, wasting bandwidth. And the MeshchatX implementation of an in-line button to 'share location' caused my instance to bomb another user of Sideband, leading them ask me to delete their LXMF address from my contacts, because MeshchatX kept retrying sending invalid telemetry request to sideband, over and over. Please note I am in contact with developers in the RNS community who refuse to push some VERY cool apps to github because they feel these could be easily modified into de-anonymizers or DDoS type tooling. The rns network is burgeoning, and they realize any implementation that could be misused, even unintentionally - **ESPECIALLY unintentionally**, shouldn't be pushed out, period. Developers always have a choice to release, or not release. Always. Matter of fact, the developer of rBrowser, fr33n0w (who I think is here on this forum), pulled his client entire github repo down after I reported the rBrowser indexing feature was an indirect DDoS vector. Kudos to him for doing the right thing. I'll stop here, I already harped on too much. I hope you take this as what it's meant: tough love :) --- ## Reply 2 **Ivan (Web)** · Tue, Oct 6, 2026 4:32 AM You are right, the DDoS bug was bad. I really need to work on improving tests, my testing methods, and QA process (as I research and learn more things too), but it's also just me actively working on MeshChatX. I will make sure to heavily review and scrutinize any network related code and features more. There is now AI provenance, although still working out some issues so it can track more accurately and automatically: https://github.com/Quad4-Software/MeshChatX/blob/master/AI.md and I mostly use local ones like Qwen 3.8 with my own harness, then move bigger or complex tasks to cloud ones like GLM 5.3-flash or Kimi K3. I just don't have as much time to dedicate to it because of health issues, family, and having a day job. I don't and never will use Claude or OpenAI crap, but I will still use open-weight models locally or from inference providers for the bigger ones if really needed. I also reserve programming by hand for smaller python projects, Reticulum-Go, and my other Go and Odin projects, which is much easier for me, and for fun NextBASIC for my ZX Spectrum Next. I will also likely do away with the GitHub issues soon, which was opened temporarily anyways (https://github.com/Quad4-Software/MeshChatX/discussions/2), and lock discussions. The RRC hub and messaging directly will be much easier for me, and you will always get a human response when I am up on the net and have the time to respond. As for features, I do not plan to add any after v5. After that, not much will change, only updates and bug/security fixes, so I can focus on my Reticulum-Go applications. --- ## Reply 3 **NONGKHAEM_BKK_TH** · Tue, Oct 6, 2026 10:41 AM Thank you so much for your thoughtful reply Ivan, much appreciated, I mean that! --- ## Reply 4 **Torlando** · Tue, Oct 6, 2026 2:56 PM **NONGKHAEM_BKK_TH** wrote: > - On extending the protocol indirectly while maintaining wire compatibility, I'll make a proper write up on the topic because MeshchatX is not the only one guilty of this. In general, please don't expand the feature set with proprietary features, such as reactions. They look harmless, but they are not. For example reactions send 'empty messages' to other clients such as sideband, wasting bandwidth. Just wanted to mention, since you seem to care about details, that reactions and replies were added to LXMF as supported fields earlier this year. https://github.com/markqvist/LXMF/blob/master/LXMF/LXMF.py#L25 This was after Ivan and I had independently added our own separate implementations (LXMF does reserve a field range for extensions or experimental fields). Reactions *do* send messages with empty bodies, at least in Columba and MCX, but I think if you are going to support reactions, it is better to have the body be empty to save bandwidth there, though I have seen one other client (can't remember which one off hand) that seemed to send something like "User reacted with <3" for a time. --- ## Reply 5 **NONGKHAEM_BKK_TH** · Tue, Oct 6, 2026 5:46 PM **Torlando** wrote: > Just wanted to mention, since you seem to care about details, that reactions and replies were added to LXMF as supported fields earlier this year. That is insightful indeed, and I stand corrected on that one. Good stuff. --- ## Reply 6 **313e3b9e** · Wed, Oct 14, 2026 3:14 AM is the 'end of life' explained anywhere - what does that actually mean? --- ## Reply 7 **Ivan (Web)** · Wed, Oct 14, 2026 1:17 PM **Update:** MeshChatX will reach end of life on January 1st, 2027. I will be traveling early next year for a bit, and I have decided that maintaining MeshChatX is no longer sustainable for me, even with the assistance of LLMs. This is mostly due to my health issues specifically headaches among other issues that make it really inconvenient to use a computer that I have painfully dealt with until now. Version 5.0.0, planned for early December, will be the final release. After that, the project will be archived and ready to be forked if someone wishes to continue it. I will still be working on Reticulum-Go and my other projects when I can. --- ## Reply 8 **circfruit** · Wed, Oct 14, 2026 1:45 PM I hope you have a good rest. Being away from screen is always good idea. Hopefully someone would take over and fork. This the best web app to date. TBH it’s fully featured and only breaking changes to RNS could render it unusable. ---