rns.recipes

Is there an accepted method or convention for using multiple devices with Reticulum? Given that an Identity is portable, but different devices may be online at different times, it seems it would be ineffectual to try using the same one across all spaces. At present, I'm using the same identity on my mobile apps (same device) and a separate identity in a containerized MeshChatX instance I can access. Just trying to get a read on what solutions people are using to stay in touch effectively.

That is being worked on. Currently the best suggestion I have is to just make a separate identity per-device.

Got it, glad I'm at least not missing some obvious solution.

In the app I'm working on I set up a protocol for handling this and tbh was pretty happy with where it landed. My question here is, "Is the GROUP protocol progress near usable?" If so I can possibly lean into that (and help contribute to it where possible), happy to retire mine. But if not I'll continue as I were.

I mean no pressure whatsoever in asking this, this is not a demand or request for urgency whatsoever. Just looking for an honest status report, basically

I was doing some experimentation with this several months ago. As it is right now, you can have multiple LXMF clients on the same network using the same identity. While it's hard to predict which one will receive incoming messages, nothing is really broken in doing so.

It could be possible to support this kind of thing without the group protocol if each client had a separate device identity, and the user establishes a relationship between all of their clients so that messages can be synchronized no matter who receives the first one. Message sync shouldn't even use much bandwidth on the wider network, since multiple clients for the same user are likely to be geographically local (PC, phone, etc.) and maybe even on the same LAN.

This wasn't well received on the old Matrix server so I kind of gave up on the idea.

I believe multiple device and group chat support ideally need Reticulum multicast support first

Anonymous wrote:

I believe multiple device and group chat support ideally need Reticulum multicast support first

Is that just a belief or is there some reasoning behind it? I don't see any reason why this requires multicast.

ARF wrote:

Anonymous wrote:
> I believe multiple device and group chat support ideally need Reticulum multicast support first

Is that just a belief or is there some reasoning behind it? I don't see any reason why this requires multicast.

LXMF and Reticulum itself (see the Zen of Reticulum in the manual) try to be decentralised and transporting the same message to multiple devices would currently either require sending a packet per device (inefficient without multicast) or polling a server (against the zen)

Honestly, even multicast/group messaging doesn't solve this. If we want to have a LXMF destination identify a user and not a specific device of theirs and not rely on a centralized server, those devices will still need to communicate between themselves and synchronize accordingly.

For example, if your laptop is powered off when your phone receives a message, even if you're a multicast "group" destination, that laptop is not going to know about the message(s) received by your phone while it was powered off. The next time you go to use it, it will have an outdated state of all of your conversations that will never resolve.

I think worrying about sending a few packets between devices to handle sync is silly. LXST for voice calls uses far more bandwidth than synchronizing LXMF text messages would, and we have enough bandwidth for that.

I'm not suggesting a server exist, nor anyone polls one.

I have a solution I'm working on using RFed. RFed TL;DR: LXMF Propagation nodes but for other things

It'll work like this:

• register a phantom "Distro" address with RFed
• associate any number of device addresses with that Distro address
• distribute the public and private credentials of the Distro address to all of the devices
• message gets "sent" to Distro address and but goes to propagation
• RFed (is itself a propagation node) does the fanout by wrapping messages sent to the Distro address in packets addressed to each client address

Problem solved. No centralized servers involved. Just the RFed node that you connect to.

That's exactly what I'm talking about. I hope it works. :)