rns.recipes

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

jrl290 wrote:

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

oh, NICE. Lemme know when it's live!

KenAKAFrosty wrote:

oh, NICE. Lemme know when it's live!

It's live now, but there are already many more improvements to come

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.

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?

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?

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

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.

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.

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

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?

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.

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

jrl290 wrote:

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

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.

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.

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.

jrl290 wrote:

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

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 :)

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

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

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