rns.recipes

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

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: <arbitrary string>.<aspect>.<aspect>... 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

Does retichat still open a pre-emptive link when you open a conversation?

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

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.

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?

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

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

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

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

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

jrl290 wrote:

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

Fully understood, thank you!

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)

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

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 "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

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

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?

Anonymous wrote:

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?

Hmm yeah probably backend then; force close + re-open didn't change anything I'm afraid

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

Installed it on my iPad and was able to message my other nodes. Nice job!

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?