# Retichat-ios Testing Needed _Showcase · started by jrl290 on Mon, May 18, 2026 9:14 PM_ --- ## Original post **jrl290** · Mon, May 18, 2026 9:14 PM Hello friends, many of you have already heard me describe this ongoing project. There have been substantial changes to the code to hopefully improve reliability and responsiveness, but I only have a limited test configuration to work with. I'm asking for more people to test and give feedback Retichat is another LXMF client but with some added capabilities mainly enabled by an extension to the LXMF Propagation mechanism. Specifically: - Publish and Subscribe based chat rooms - True "Apple Push Notification Service" based push notifications in response to propagation messages - Infrastructure-less group messaging (different from Publish and Subscribe) App Store link: https://apps.apple.com/us/app/retichat/id6762225314. An Android version is also in the works. Also, importantly, a default RFed instance is used if one isn't specified so that Channels and Push notifications function for testers Everything is open source and MIT license - App - https://github.com/jrl290/Retichat-ios - RFed node - https://github.com/jrl290/RFed Child libraries (not meant for individual use) - https://github.com/jrl290/app-links - https://github.com/jrl290/LXMF-rust - https://github.com/jrl290/Reticulum-rust **Disclaimer** There is substantial AI written code in this project. My first iPhone app was published 15 years ago. It was written in Objective-C and the flagship iPhone at the time was the 4s. **The Design and Scope of Retichat** The aim for Retichat is to provide a low friction user experience similar to Whatsapp or Signal but without central servers of any kind (the beauty of Reticulum). It will obfuscate many of the rougher edges such as announces and store-and-forward configuration. And it will bend the low bandwidth forgiveness of Reticulum in favor of responsiveness expected out of a typical chat app Public backbone TCP interfaces are hardcoded and randomly selected by the app at default. Multiple paths are tested for responsiveness when a message is sent. Additionally, a default RFed node provided for now. At the same time, interfaces can be manually designated. As can RFed or Propagation node Lastly, Retichat's goal is adoption, but its purpose is communication readiness under adverse conditions. LoRa will be supported. Voice and video will not be **Details: Group Messaging** The group messaging in Retichat is designed specifically to require no additional infrastructure. As such, a minimal amount of statefulness is added. Specifically: - an arbitrary group ID that has no meaning outside of the group - a list of participants who have been invited - and the annotations of who has accepted the invite (and not explicitly left) One user starts the group with a specific set of invitees. The invites include the list of invitees. Accepting the invite sends a message to the group designating them an active participant Each participant is responsible for distributing its own sent messages to every other participant individually. Additionally, for low bandwidth purposes, a participant may ask another participant to distribute its sent message (which that proxy may then pass to another participant). In this way, both fanout and round robin are implemented as is most efficient and most necessary And that is the scope of group mode in Retichat. Again, spec'd specifically for minimal additional coordination or infrastructure --- ## Reply 1 **jrl290** · Mon, May 18, 2026 9:17 PM **Details: RFed extension to LXMF Propagation** **LXMF Prop** The premise of LXMF Propagation is simple, elegant, and also extremely powerful. It is a coordination-less way to provide infrastructure services like store-and-forward. These infrastructure nodes find and synchronize with each other, so even when one device is using one prop node, it still receives messages from another device using a different prop node. The only requirement that needs to be fulfilled is that those nodes are designated hard points with higher reliability. So when your device is offline, the hard point stays online to buffer data that is addressed to you **RFed Channels** RFed extends this with additional logic in order to provide Subscriber based data distribution. Instead of holding data to be forwarded to one device, it holds data for a communal address and then forwards that data to every subscriber of that address. The format of a channel address is the same as the Reticulum destination addresses: ..... However, that is then hashed into both the destination address and the identity key pair. This allows for both public and private channels, with "public" being the first element in public channels. The benefit of organizing channels this way is that all data is still encrypted to RFed and transport nodes. The only information the network needs to see is the destination hash, which itself is a mathematical trap door. The subscribers to all channels must share the channel destination string out-of-band Subscribers register their destination (with proof of identity) and a channel destination with the RFed node. Channel messages are synchronized with other RFed nodes which then distribute the message to their subscribers. All channels are ephemeral. Every destination string is a channel. The actual payload is double wrapped in the same way LXMF Propagation is double wrapped. The first message payload is wrapped in the LXMF packet, addressed to its intended recipient. That packet is then wrapped in the LXMF Propagation packet, addressed to the lxmf.propagation destination of the propagation node. The Propagation node unwraps its payload. It then stores and synchronizes the LXMF packet with other propagation nodes for future delivery. When it is delivered, the recipient uses its private key to decrypt. For channels, RFed receives the double wrapped packet on its rfed.channel.publish destination, and extracts the payload LXMF packet. That packet is addressed to the channel. RFed synchronizes the packet with other RFed nodes. And then for every subscriber, it duplicates the packet and wraps it in a packet addressed to the subscriber. The subscriber holds the key for itself to unwrap the outer packet. It also holds the keys to the channel, which were shared as a destination string to subscribers out-of-band. **RFed Notify** Another subscription type for RFed. This allows a destination to register itself (with proof of identity), a source, and another destination address. That destination is designated to receive a ping with no data aside from the registrant address whenever the node receives a message addressed to the registrant. This does not include direct messages. Sources include a specific channel that has been subscribed to, or lxmf propagation addressed to the registrant. For Retichat, the destinations that are notified are the bridges to Apple and Google's mobile push notification systems. They are the best way to keep a chat app always able to receive without a constantly maintained connection, which prevents low power radio strategies and which Apple doesn't even allow in the background It was also kept generalizable for other possible reasons where multiple devices or mediums might want to react to a message sent to a specific destination. **RFed backup** Subscribers register with their own RFed node. Only that RFed node serves a channel message to that subscriber. However, RFed nodes are configured to ask another RFed node to watch it. If an RFed goes down, a watcher RFed node will adopt its subscribers for a limited time --- ## Reply 2 **Torlando** · Mon, May 18, 2026 11:25 PM Does retichat still open a pre-emptive link when you open a conversation? --- ## Reply 3 **jrl290** · Mon, May 18, 2026 11:51 PM **Torlando** wrote: > Does retichat still open a pre-emptive link when you open a conversation? No. I did a test to see what results in the fastest message send. Bizarrely, a cold send (that then establishes a link automatically) is faster than sending a message on a preestablished link. I have no idea why. If an already established link in either direction is available, it will use that link. But it won't do anything to keep a chat link alive What is done preemptively is a path request on all available interfaces to determine accessibility. The path requests do not use any cached paths either. It assumes all chat clients are not connected most of the time To be sure, speed and responsiveness are considered paramount for TCP connections. It will not be so aggressive on LoRa and similar low bandwidth interfaces --- ## Reply 4 **joakim** · Tue, May 19, 2026 10:15 AM **jrl290** wrote: > **Disclaimer** There is substantial AI written code in this project. My first iPhone app was published 15 years ago. It was written in Objective-C and the flagship iPhone at the time was the 4s. Just want to say that I appreciate that you're transparent about this. Not all developers are these days. --- ## Reply 5 **KenAKAFrosty** · Tue, May 19, 2026 2:06 PM I have a mac mini in transit as we speak, specifically to get into the apple ecosystem for development, mostly with Reticulum in mind. I have an iOS device in the household too, and I'd be happy to help! Do you have a TestFlight set up I should join, or using the public app for now is fine? --- ## Reply 6 **Anonymous** · Tue, May 19, 2026 2:13 PM **KenAKAFrosty** wrote: > I have a mac mini in transit as we speak, specifically to get into the apple ecosystem for development, mostly with Reticulum in mind. I have an iOS device in the household too, and I'd be happy to help! Do you have a TestFlight set up I should join, or using the public app for now is fine? Public is fine. TestFlight is a rampant pain in the ass. Thankfully, once the RFed and Group protocols are fully locked, the scope of the app is pretty well defined. Any changes to be made over time should be minimal or maintenance --- ## Reply 7 **Anonymous** · Tue, May 19, 2026 2:15 PM **joakim** wrote: > Just want to say that I appreciate that you're transparent about this. Not all developers are these days. Credit is not at all what's important with this project, in my view. It still takes plenty of work. AI is still pretty dumb in a lot of ways. But my personal github account is listed for (warrantless) accountability. I am a steward --- ## Reply 8 **KenAKAFrosty** · Tue, May 19, 2026 2:15 PM **Anonymous** wrote: > **KenAKAFrosty** wrote: > > I have a mac mini in transit as we speak, specifically to get into the apple ecosystem for development, mostly with Reticulum in mind. I have an iOS device in the household too, and I&#039;d be happy to help! Do you have a TestFlight set up I should join, or using the public app for now is fine? > > Public is fine. TestFlight is a rampant pain in the ass. Thankfully, once the RFed and Group protocols are fully locked, the scope of the app is pretty well defined. Any changes to be made over time should be minimal or maintenance Got it! Will report back after I try this (probably later today) --- ## Reply 9 **KenAKAFrosty** · Tue, May 19, 2026 2:32 PM Side quest-ion for jrl290. I'm working on a full RNS parity in Rust as well (i saw in your repo you have your needs-focused ones) -- My question here is I'm working to get bindings set up for maven/SPM along with some others, to help future builders in the ecosystem. If you've already got this on your radar too then I could pivot or contribute back to yours. If not I'll carry on, just trying to avoid too much fragmentation in the ecosystem --- ## Reply 10 **jrl290** · Tue, May 19, 2026 3:11 PM **KenAKAFrosty** wrote: > Side quest-ion for jrl290. I'm working on a full RNS parity in Rust as well (i saw in your repo you have your needs-focused ones) -- My question here is I'm working to get bindings set up for maven/SPM along with some others, to help future builders in the ecosystem. If you've already got this on your radar too then I could pivot or contribute back to yours. If not I'll carry on, just trying to avoid too much fragmentation in the ecosystem The reason I didn't use others' Rust implementations and that I don't recommend building on top of mine is that I have been taking *a lot* of liberties with the protocol implementation. The python code does a lot of things that are deterministic when they are (python) slow and single threaded. As soon as you untangle some of that stuff, you deviate from the canon determinism. Most of it makes no difference, and some of it might be a welcome improvement, but I'm not here to change the canon. Just to interoperate with it. As such, I would not recommend making a near clone of a near clone By all means, continue with your Rust implementation if accuracy is your goal --- ## Reply 11 **KenAKAFrosty** · Tue, May 19, 2026 3:26 PM **jrl290** wrote: > **KenAKAFrosty** wrote: > > Side quest-ion for jrl290. I&#039;m working on a full RNS parity in Rust as well (i saw in your repo you have your needs-focused ones) -- My question here is I&#039;m working to get bindings set up for maven/SPM along with some others, to help future builders in the ecosystem. If you&#039;ve already got this on your radar too then I could pivot or contribute back to yours. If not I&#039;ll carry on, just trying to avoid too much fragmentation in the ecosystem > > The reason I didn't use others' Rust implementations and that I don't recommend building on top of mine is that I have been taking *a lot* of liberties with the protocol implementation. The python code does a lot of things that are deterministic when they are (python) slow and single threaded. > > As soon as you untangle some of that stuff, you deviate from the canon determinism. Most of it makes no difference, and some of it might be a welcome improvement, but I'm not here to change the canon. Just to interoperate with it. As such, I would not recommend making a near clone of a near clone > > By all means, continue with your Rust implementation if accuracy is your goal Fully understood, thank you! --- ## Reply 12 **KenAKAFrosty** · Wed, May 20, 2026 1:47 PM Okay! Had a chance to try it out on an iPhone 13 and an ipad pro (but independently, not at the same time yet, will come back to this below). Overall it was functional; so in terms of a smoke test, it passes great! I did my best to not look too deeply at the code so that my user experience was as "fresh" as it could be. I went in excited to have an iOS app so it could communicate with my other devices. That's where I hit the wall, though, sadly. Two main things: 1) Without autointerface, only TCP & RNode, i didn't have a go-to way to communicate in this context. Might not be your design goals in the first place. You mentioned in your post here how it has hardcoded servers to work with, so Retichat <-> Retichat seems solid. Later I should be able to test iPhone <-> iPad and can confirm on that front 2) I'm using Columba on my Android, and the text format and QR format both don't inter-op, so I had no way to add me directly. I was thinking I could turn the privacy filter off (btw, I 100% agree and love that this is default-on; I think that will be a loadbearing decision for any app that's working to appeal to a broader audience like this), then announce from Columba. But (for good reason) those details aren't surfaced to the user in the first place. In short, I was blocked from doing Columba on my Android phone to another iPhone w/ Retichat in the same household. Happy to test future updates! (and again, I recognize my case may not be your target audience anyway so I'm not sure anything is actionable yet) --- ## Reply 13 **Anonymous** · Wed, May 20, 2026 2:06 PM **KenAKAFrosty** wrote: > Okay! Had a chance to try it out on an iPhone 13 and an ipad pro (but independently, not at the same time yet, will come back to this below). Overall it was functional; so in terms of a smoke test, it passes great! > > I did my best to not look too deeply at the code so that my user experience was as "fresh" as it could be. I went in excited to have an iOS app so it could communicate with my other devices. That's where I hit the wall, though, sadly. Two main things: > 1) Without autointerface, only TCP & RNode, i didn't have a go-to way to communicate in this context. Might not be your design goals in the first place. You mentioned in your post here how it has hardcoded servers to work with, so Retichat <-> Retichat seems solid. Later I should be able to test iPhone <-> iPad and can confirm on that front > 2) I'm using Columba on my Android, and the text format and QR format both don't inter-op, so I had no way to add me directly. I was thinking I could turn the privacy filter off (btw, I 100% agree and love that this is default-on; I think that will be a loadbearing decision for any app that's working to appeal to a broader audience like this), then announce from Columba. But (for good reason) those details aren't surfaced to the user in the first place. > > In short, I was blocked from doing Columba on my Android phone to another iPhone w/ Retichat in the same household. > > Happy to test future updates! (and again, I recognize my case may not be your target audience anyway so I'm not sure anything is actionable yet) Thank you so much! I'll put AutoInterface in and look at the QR/LMXD format compatibility --- ## Reply 14 **KenAKAFrosty** · Wed, May 20, 2026 2:53 PM **Anonymous** wrote: > **KenAKAFrosty** wrote: > > Okay! Had a chance to try it out on an iPhone 13 and an ipad pro (but independently, not at the same time yet, will come back to this below). Overall it was functional; so in terms of a smoke test, it passes great! > > > > I did my best to not look too deeply at the code so that my user experience was as &quot;fresh&quot; as it could be. I went in excited to have an iOS app so it could communicate with my other devices. That&#039;s where I hit the wall, though, sadly. Two main things: > > 1) Without autointerface, only TCP &amp; RNode, i didn&#039;t have a go-to way to communicate in this context. Might not be your design goals in the first place. You mentioned in your post here how it has hardcoded servers to work with, so Retichat &lt;-&gt; Retichat seems solid. Later I should be able to test iPhone &lt;-&gt; iPad and can confirm on that front > > 2) I&#039;m using Columba on my Android, and the text format and QR format both don&#039;t inter-op, so I had no way to add me directly. I was thinking I could turn the privacy filter off (btw, I 100% agree and love that this is default-on; I think that will be a loadbearing decision for any app that&#039;s working to appeal to a broader audience like this), then announce from Columba. But (for good reason) those details aren&#039;t surfaced to the user in the first place. > > > > In short, I was blocked from doing Columba on my Android phone to another iPhone w/ Retichat in the same household. > > > > Happy to test future updates! (and again, I recognize my case may not be your target audience anyway so I&#039;m not sure anything is actionable yet) > > Thank you so much! I'll put AutoInterface in and look at the QR/LMXD format compatibility Happy to help!! Just did the iPad <-> iPhone test now. QR code added on both sides. Both even had privacy filter off just in case. Messages on both sides showed double-check approval, but the destination device in either case never received a message. No interfaces were added manually in either case (testing the grandma-friendliness theory a bit haha). As I typed this I realized "oh, maybe the TCP interface picker will let us apply one but we'd still have to do it or something". I checked and don't think that's the case either as it's a starightforward input form to add a user-typed TCP connection. Also I long-pressed the messages showing the double-check confirmation but that didn't trigger any additional info to better understand. And both were connected to our home WiFi and had normal internet access --- ## Reply 15 **Anonymous** · Wed, May 20, 2026 10:04 PM **KenAKAFrosty** wrote: > Happy to help!! Just did the iPad <-> iPhone test now. QR code added on both sides. Both even had privacy filter off just in case. Messages on both sides showed double-check approval, but the destination device in either case never received a message. No interfaces were added manually in either case (testing the grandma-friendliness theory a bit haha). As I typed this I realized "oh, maybe the TCP interface picker will let us apply one but we'd still have to do it or something". I checked and don't think that's the case either as it's a starightforward input form to add a user-typed TCP connection. > > Also I long-pressed the messages showing the double-check confirmation but that didn't trigger any additional info to better understand. And both were connected to our home WiFi and had normal internet access So my guess is that the UI wasn't updated. Or maybe the database wasn't set up properly. What happens when you force close the app and reopen? --- ## Reply 16 **KenAKAFrosty** · Wed, May 20, 2026 10:54 PM **Anonymous** wrote: > **KenAKAFrosty** wrote: > > Happy to help!! Just did the iPad &lt;-&gt; iPhone test now. QR code added on both sides. Both even had privacy filter off just in case. Messages on both sides showed double-check approval, but the destination device in either case never received a message. No interfaces were added manually in either case (testing the grandma-friendliness theory a bit haha). As I typed this I realized &quot;oh, maybe the TCP interface picker will let us apply one but we&#039;d still have to do it or something&quot;. I checked and don&#039;t think that&#039;s the case either as it&#039;s a starightforward input form to add a user-typed TCP connection. > > > > Also I long-pressed the messages showing the double-check confirmation but that didn&#039;t trigger any additional info to better understand. And both were connected to our home WiFi and had normal internet access > > So my guess is that the UI wasn't updated. Or maybe the database wasn't set up properly. What happens when you force close the app and reopen? Hmm yeah probably backend then; force close + re-open didn't change anything I'm afraid --- ## Reply 17 **jrl290** · Thu, May 21, 2026 12:02 AM **KenAKAFrosty** wrote: > Hmm yeah probably backend then; force close + re-open didn't change anything I'm afraid Just narrows down the problem space. I'll get back to you --- ## Reply 18 **Zen** · Thu, May 21, 2026 12:35 AM Installed it on my iPad and was able to message my other nodes. Nice job! --- ## Reply 19 **KenAKAFrosty** · Thu, May 21, 2026 3:09 PM **Zen** wrote: > Installed it on my iPad and was able to message my other nodes. Nice job! Dang I've been a bit stuck. Did you use the LoRa interface or TCP? --- ## Reply 20 **jrl290** · Thu, May 21, 2026 5:52 PM **KenAKAFrosty** wrote: > Dang I've been a bit stuck. Did you use the LoRa interface or TCP? I reenabled the AutoInterface and put a minor amount of hardening for the privacy filter code in (that's what best explains the double check and no receipt). Also the QR code compatibility with Columba Just waiting for the App Store approval --- ## Reply 21 **KenAKAFrosty** · Thu, May 21, 2026 6:37 PM **jrl290** wrote: > **KenAKAFrosty** wrote: > > Dang I&#039;ve been a bit stuck. Did you use the LoRa interface or TCP? > > I reenabled the AutoInterface and put a minor amount of hardening for the privacy filter code in (that's what best explains the double check and no receipt). Also the QR code compatibility with Columba > > Just waiting for the App Store approval oh, NICE. Lemme know when it's live! --- ## Reply 22 **jrl290** · Fri, May 22, 2026 12:30 AM **KenAKAFrosty** wrote: > oh, NICE. Lemme know when it's live! It's live now, but there are already many more improvements to come --- ## Reply 23 **Ghost_898** · Thu, May 28, 2026 7:47 PM Running retichat iOS app version 1.16 on iOS 26.5 and noticing a background connectivity issue. After leaving the app or switching to the home screen, the app seems to stop receiving messages entirely, almost like it is no longer running in the background. As soon as I reopen the app, messages start coming through again. Same behavior when connected to an RNode. While the app is backgrounded, it appears to stop receiving data/signals. Once switching back into the app, the RNode suddenly sends a bulk batch of queued signals/messages all at once. So currently it looks like neither message reception nor RNode communication continues properly while the app is in the background. It seems to me on a earlier version it didn’t have such a behavior. --- ## Reply 24 **Arcade** · Thu, May 28, 2026 10:16 PM This may be me being a dolt, but I can't seem to get it to send a message indirectly. Is that a known issue? --- ## Reply 25 **jrl290** · Thu, May 28, 2026 11:11 PM **Arcade** wrote: > This may be me being a dolt, but I can't seem to get it to send a message indirectly. Is that a known issue? How do you mean, indirectly? Do you mean store and forward? --- ## Reply 26 **jrl290** · Thu, May 28, 2026 11:13 PM **Ghost_898** wrote: > Running retichat iOS app version 1.16 on iOS 26.5 and noticing a background connectivity issue. > > After leaving the app or switching to the home screen, the app seems to stop receiving messages entirely, almost like it is no longer running in the background. As soon as I reopen the app, messages start coming through again. > > Same behavior when connected to an RNode. While the app is backgrounded, it appears to stop receiving data/signals. Once switching back into the app, the RNode suddenly sends a bulk batch of queued signals/messages all at once. > > So currently it looks like neither message reception nor RNode communication continues properly while the app is in the background. > > It seems to me on a earlier version it didn’t have such a behavior. I restarted my RFed node which background push notification requires. It also saw my push notifications stop, so I think it might be a stability issue with the RFed service --- ## Reply 27 **Ghost_898** · Fri, May 29, 2026 7:06 AM **jrl290** wrote: > **Ghost_898** wrote: > > Running retichat iOS app version 1.16 on iOS 26.5 and noticing a background connectivity issue. > > > > After leaving the app or switching to the home screen, the app seems to stop receiving messages entirely, almost like it is no longer running in the background. As soon as I reopen the app, messages start coming through again. > > > > Same behavior when connected to an RNode. While the app is backgrounded, it appears to stop receiving data/signals. Once switching back into the app, the RNode suddenly sends a bulk batch of queued signals/messages all at once. > > > > So currently it looks like neither message reception nor RNode communication continues properly while the app is in the background. > > > > It seems to me on a earlier version it didn’t have such a behavior. > > I restarted my RFed node which background push notification requires. It also saw my push notifications stop, so I think it might be a stability issue with the RFed service Thanks for verifying. But I’m experiencing this „freeze“ with only TCP connection enabled too. It seems to stop receiving while on background entirely. --- ## Reply 28 **kujeger** · Fri, May 29, 2026 7:53 AM Hi, was just told of this and looks like we have a naming collision! I've had https://codeberg.org/kujeger/retichat , a TUI lxmf chatting app, for a while (it hasn't been very active lately as I've been waiting for a suitable rust-based reticulum/lxmf implementation to appear, and I'm in the process of porting it to rsReticulum/rsLXMF now). So we should probably figure something out around the naming. --- ## Reply 29 **jrl290** · Fri, May 29, 2026 1:19 PM **kujeger** wrote: > Hi, was just told of this and looks like we have a naming collision! > I've had https://codeberg.org/kujeger/retichat , a TUI lxmf chatting app, for a while (it hasn't been very active lately as I've been waiting for a suitable rust-based reticulum/lxmf implementation to appear, and I'm in the process of porting it to rsReticulum/rsLXMF now). > > So we should probably figure something out around the naming. Ah balls, sorry about that. It must've slipped my view when doing basic name checks. I don't see it as a substantially problematic collision though. The platforms separate the target audiences pretty well. One specifically targeted to mainstream mobile chat and the other for terminal users Is there something you'd like to see in particular? I could put a reference to Retichat for TUI on my github description pages. If it means anything, I have no intension of seeking any sort of trademark or anything like that --- ## Reply 30 **jrl290** · Fri, May 29, 2026 1:24 PM **Ghost_898** wrote: > Thanks for verifying. But I’m experiencing this „freeze“ with only TCP connection enabled too. It seems to stop receiving while on background entirely. Yes, iOS doesn't allow persistent background connections. RFed is required for push notifications to work, but there is a default RFed node used if nothing else is configured. What do you have configured for RFed and LXMF Propagation addresses? --- ## Reply 31 **Ghost_898** · Fri, May 29, 2026 2:20 PM **jrl290** wrote: > **Ghost_898** wrote: > > Thanks for verifying. But I’m experiencing this „freeze“ with only TCP connection enabled too. It seems to stop receiving while on background entirely. > > Yes, iOS doesn't allow persistent background connections. RFed is required for push notifications to work, but there is a default RFed node used if nothing else is configured. What do you have configured for RFed and LXMF Propagation addresses? I configured the identity hash of my meshchat running on docker, it does even automatically recognize the propagation node which is enabled. But Retichat tells me “no path”. Maybe that’s the issue when RFed is responsible for notification. I tried restarting meshchat but no luck. --- ## Reply 32 **jrl290** · Fri, May 29, 2026 4:56 PM **Ghost_898** wrote: > I configured the identity hash of my meshchat running on docker, it does even automatically recognize the propagation node which is enabled. But Retichat tells me “no path”. Maybe that’s the issue when RFed is responsible for notification. I tried restarting meshchat but no luck. Yes, if it says "no path" then that's at the root of the issue. And the Meshchat address shouldn't be in that top field. Just clear it and it'll use the default RFed node instead. You can have whatever you want in the bottom for the propagation node address, but if you don't have anything then it'll use a default node for that as well --- ## Reply 33 **Torlando** · Fri, May 29, 2026 5:47 PM **jrl290** wrote: > **KenAKAFrosty** wrote: > > Dang I&#039;ve been a bit stuck. Did you use the LoRa interface or TCP? > > I reenabled the AutoInterface and put a minor amount of hardening for the privacy filter code in (that's what best explains the double check and no receipt). Also the QR code compatibility with Columba > > Just waiting for the App Store approval One thing I observed with Columba is that I would get double checkmarks for sent OPPORTUNISTIC messages (which means it got a delivery proof back) to Sideband, even though Sideband didn't render the message. This turned out to be that Sideband has a (user toggle-able) stamp cost 1 enforcement for incoming messages. The version of Columba I was testing with at the time (1.0.x) had missed wiring up the stamper in the announce handler, so it wasn't stamping messages when needed. I found it strange that Sideband (probably LXMF under the hood) was sending delivery proofs even when the message was dropped. I didn't dig into the code to find the exact line to confirm though, so I may have been misinterpreting. Anyway, just wanted to point this out - you might want to double check how the client you're testing against handles its privacy filter, specifically whether it still sends a delivery proof if the message is dropped or hidden from the user (and this might actually be LXMF behavior, a layer down from whatever the app does, I haven't verified). I could see arguments for either approach; sending a delivery proof leaves the sender none the wiser that you have blocked incoming messages, while withholding the delivery proof (while still announcing on an interval) indicates to the sender that you are either never connected when they send a message, or that you have blocked them. On the flip side, sending the delivery proof does tell the sender that you are connected/online, even if you have blocked unknown senders. Same goes for accepting link requests. --- ## Reply 34 **K8** · Sat, May 30, 2026 2:30 AM **Torlando** wrote: > I found it strange that Sideband (probably LXMF under the hood) was sending delivery proofs even when the message was dropped. I didn't dig into the code to find the exact line to confirm though, so I may have been misinterpreting. Currently delivery proofs are generated and sent directly from Transport during inbound processing, while stamps are handled from the LXMF module, so as far as the implementation that behavior makes sense. I imagine some of Mark’s current work to bring stamping within RNS itself would allow this behavior to change. I’m also not sure if it *should* change, but maybe there’s a case for it being configurable. --- ## Reply 35 **jrl290** · Sat, May 30, 2026 2:43 PM **Torlando** wrote: > I could see arguments for either approach; sending a delivery proof leaves the sender none the wiser that you have blocked incoming messages, while withholding the delivery proof (while still announcing on an interval) indicates to the sender that you are either never connected when they send a message, or that you have blocked them. On the flip side, sending the delivery proof does tell the sender that you are connected/online, even if you have blocked unknown senders. Same goes for accepting link requests. I've looked at the code and what I want to happen. You know that I'm using custom rolled Reticulum and LXMF rust code. So I'm inserting a hook into LXMF that short circuits the proof mechanism as soon as the sender identity is decoded. If privacy is enabled and the identity doesn't appear on the whitelist, no proof is run and no response is given Some LXMF clients will be confused by this, I know. But I think it is important to protect the device from spamming proof calls (on top of the decode call), especially since the device broadcasts its address to the network. --- ## Reply 36 **kujeger** · Mon, Jun 1, 2026 6:24 PM **jrl290** wrote: > **kujeger** wrote: > > Hi, was just told of this and looks like we have a naming collision! > > I&#039;ve had https://codeberg.org/kujeger/retichat , a TUI lxmf chatting app, for a while (it hasn&#039;t been very active lately as I&#039;ve been waiting for a suitable rust-based reticulum/lxmf implementation to appear, and I&#039;m in the process of porting it to rsReticulum/rsLXMF now). > > > > So we should probably figure something out around the naming. > > Ah balls, sorry about that. It must've slipped my view when doing basic name checks. > > I don't see it as a substantially problematic collision though. The platforms separate the target audiences pretty well. One specifically targeted to mainstream mobile chat and the other for terminal users > > Is there something you'd like to see in particular? I could put a reference to Retichat for TUI on my github description pages. If it means anything, I have no intension of seeking any sort of trademark or anything like that yeah no worries, great minds think alike and all that! we can see how it turns out; your project seems to have more traction/users so I may end up just changing the name of my client :) --- ## Reply 37 **jrl290** · Mon, Jun 1, 2026 10:46 PM **kujeger** wrote: > yeah no worries, great minds think alike and all that! > > we can see how it turns out; your project seems to have more traction/users so I may end up just changing the name of my client :) I wouldn't undersell your creation. TUI has a smaller audience inherently. Doesn't make it unimportant In my estimation there's no need to change the name, but of course that's up to you --- ## Reply 38 **kujeger** · Tue, Jun 2, 2026 10:09 AM **jrl290** wrote: > **kujeger** wrote: > > yeah no worries, great minds think alike and all that! > > > > we can see how it turns out; your project seems to have more traction/users so I may end up just changing the name of my client :) > > I wouldn't undersell your creation. TUI has a smaller audience inherently. Doesn't make it unimportant > > In my estimation there's no need to change the name, but of course that's up to you thanks, and yeah, I was just thinking that "fewer users is less disruption if there's a name change" :D --- ## Reply 39 **metrafonic** · Tue, Jun 2, 2026 4:03 PM Awesome work! I love that you got RNodes working on iOS! I didnt think anyone had a working implementation yet. Could you allow setting the SF factor down to SF5? The dropdown currently only allows to SF7. Many radios support it and i use that locally --- ## Reply 40 **jrl290** · Wed, Jun 3, 2026 6:55 PM **metrafonic** wrote: > Awesome work! I love that you got RNodes working on iOS! I didnt think anyone had a working implementation yet. > > Could you allow setting the SF factor down to SF5? The dropdown currently only allows to SF7. Many radios support it and i use that locally New update has that change now --- ## Reply 41 **metrafonic** · Fri, Jun 5, 2026 1:03 PM **jrl290** wrote: > **metrafonic** wrote: > > Awesome work! I love that you got RNodes working on iOS! I didnt think anyone had a working implementation yet. > > > > Could you allow setting the SF factor down to SF5? The dropdown currently only allows to SF7. Many radios support it and i use that locally > > New update has that change now Awesome! I found the RNode link to be unstable. I do not like that the app has built in hidden tcp client connections to some hardcoded servers. Have them as options that can be toggled off. Maybe they do not exist in this version? Can you add a way to send an announce manually? Announces are a vital part of a reticulum network. It seems like it is currently on a timer, which does not make much sense. It should be done on interface changes, app start, etc. --- ## Reply 42 **jrl290** · Fri, Jun 5, 2026 1:40 PM **metrafonic** wrote: > **jrl290** wrote: > > **metrafonic** wrote: > > &gt; Awesome work! I love that you got RNodes working on iOS! I didnt think anyone had a working implementation yet. > > &gt; > > &gt; Could you allow setting the SF factor down to SF5? The dropdown currently only allows to SF7. Many radios support it and i use that locally > > > > New update has that change now > > Awesome! > > I found the RNode link to be unstable. I do not like that the app has built in hidden tcp client connections to some hardcoded servers. Have them as options that can be toggled off. Maybe they do not exist in this version? > > Can you add a way to send an announce manually? Announces are a vital part of a reticulum network. It seems like it is currently on a timer, which does not make much sense. It should be done on interface changes, app start, etc. Yes, I agree. I will put a toggle on the Default multi connection. The announce system is on a timer, a rate limiter, and a set of event triggers. Every time an interface comes up, an announce is automatically triggered on that interface. Also when foregrounding the app and when there is a ratchet desync. There are other events, but I can't list them off the top of my head Tell me about the RNode link. To be honest, the RNode implementation was only just started when I had to do some refactoring on another section of code. Where as TCP connections are designed to be somewhat greedy in favor of responsiveness and reliability, LoRa necessarily has to be much more deliberate with its connection. That hasn't really been addressed at all yet. What are you seeing on the RNode graph when sending and receiving? Thank you for giving feedback btw, this kind of thing really needs multiple sets of eyes ---