rns.recipes

I now have released an Android version of my Retichat LXMF/RFed client on Github (and soon Google Play store):
https://github.com/jrl290/Retichat-android/releases/tag/v0.1.1

All open source. Heavily AI written (yes I am an app developer of 15 years)

I did a more detailed description of Retichat and RFed on the iOS release post here:
https://rns.recipes/forum/showcase/retichat-ios-testing-needed

But here are the highlights:

The design goal of Retichat is to be a (mostly) grandma friendly chat app, hiding most of Reticulum's complexity behind familiar chat interface.

Secondary to that goal is to showcase a subscription-centric distribution mechanism called RFed, which is an extension to LXMF store-and-forward server and is heavily based on it. In Retichat, this enables chatroom "Channels" that can be either public or private, but is designed to be generic for other uses

And the two other unique features are a Group mode that requires no extra infrastructure and adds minimal extra protocol, and true mobile push notification. Push notification requires RFed but enables mobile clients to avoid having a constant background connection which is a major battery drain and isn't allowed on Apple devices

Everything is early but definitely converging as lessons are learned and the code gets refined

Reti-Chat continually crashes when I try to enter the setup to create an identity.

Just a symbol problem caused by the minify. Here's a new release: https://github.com/jrl290/Retichat-android/releases/tag/v0.1.1

Yes, that did solve the problem. Thank you!

I am curious what Groups and Channels refer to. Are channels related to RRC channels?

Search wrote:

I am curious what Groups and Channels refer to. Are channels related to RRC channels?

RRC requires a server to host the channel and has control over the channel

An RFed Channel requires at least one federation node is otherwise not defined by any hardware. Much like the Reticulum network itself. The "Channel" is ephemeral. You could type anything into the address box and it would be a Channel. The key is that the RFed nodes synchronize with each other in order to distribute messages to anyone who also has that Channel address

Groups are purely adhoc. Nothing outside of the Reticulum network is required. The group participants do all of the message distribution

Cool - thanks for the information... I also found https://github.com/jrl290/RFed and went through the README. I admit I don't quit understand all of it but am pretty excited about the possibilties.

I'm not able to connect with Retichat Android. Can't send messages and other peers don't have a path.

I tested only iOS version, but what I'd like to see is an announce button. I kind of feel handicapped without it 😄

batrat wrote:

I'm not able to connect with Retichat Android. Can't send messages and other peers don't have a path.

New release available: https://github.com/jrl290/Retichat-android/releases

circfruit wrote:

I tested only iOS version, but what I'd like to see is an announce button. I kind of feel handicapped without it 😄

It's a QC handicap. If you have to press the "Please work" button, it is not working as I intend it to work

Can a channel be reached from Meshchat?

Mastodon wrote:

Can a channel be reached from Meshchat?

Negative. An RFed Channel is a specific protocol that has to be implemented. And that is in the name of the core design principle of Reticulum: no intermediary node is trustworthy.

Reticulum Relay Chat offers a "hub" based chat mechanism. If you want to subscribe to a group, it has to be on that hub. That hub can shut down the chat if desired. Or it can be taken down

RFed is a federated chat implementation. It operates like LXMF store and forward. You connect to a node. All nodes synchronize with each other. The namespace of all channels is global. No one has admin rights. Private channels are the same as public channels but with a key pair that is shared out-of-band

In my view, subscriber based data transfer is a major boost to capability of the network. Right now, only my apps implement it. But time will tell if it wins in the marketplace of ideas

I still can't send or receive. All other Reticulum apps work well. Could they be conflicting with Retichat? I also don't have play services installed but I doubt the app depends on them in any way?

batrat wrote:

I still can't send or receive. All other Reticulum apps work well. Could they be conflicting with Retichat? I also don't have play services installed but I doubt the app depends on them in any way?

No, they wouldn't be conflicting. Play services might be required for push notifications but not for anything while the app is open.

Do you get any checkmarks on sent messages? Or is it all x's

It's all x. I have (had) default tcp endpoints, auto-LAN and i2p enabled. And I've been mixing and matching them.

I have (had) default tcp endpoints, auto-LAN and i2p enabled.

Ah, everything except tcp is stubs right now. Sorry about that. Would you try removing those and only configuring tcp manually?

Ah that explains. Thank you, it works now. It seems I didn't try plain tcp after all. Anyway, nice job with the app. Just curious, what did you set for the announce interval?

It announces whenever the app foregrounds or an interface connects. Then every 30 minutes on an interface (if you left the app open the whole time) and no more than every 5 minutes on an interface

Nice to know. If it is possible I would suggest adding support for UnifiedPush. Also identity management would be good but I suspect that is already on the roadmap.

I did look into UnifiedPush. Sadly:

Q: Will UnifiedPush ever work on iOS?
iOS doesn’t support running services in the background, so running a UnifiedPush distributor won’t be possible without jailbreaking or Apple’s approval for the foreseeable future. If someone has a solution, please share that in the chat.

That also means that their Android implementation also runs in the background. And that unfortunately makes it power hungry. I'm certainly not opposed to getting out of the Apple and Android ecosystems. But for this project, the goal is mainstream accessibility

Yes, identity management will be part of the app as it develops