# Reticulum group chat

_Showcase · started by JohnWW on Fri, Nov 13, 2026 10:59 AM_

---

## Original post

**JohnWW** · Fri, Nov 13, 2026 10:59 AM

In our little group we use a mixture of Sideband and Meshchatx and most of us both. Having only one to one chats available you have to know which device the recipient is currently using or send messages to both. We use Signal group chats a lot which got me thinking.

Anyway, after an hour chatting to an AI we now have a Reticulum group chat server called RNSChat running on one of the transport nodes. It announces itself and any messages sent to it will be queued and delivered to all the recipients specified in a members list file. Any not on-line eventually have their messages sent to the propagation network for collection later. Any messages originating from an ID not in the members file are silently discarded.

Currently it supports just a single group. Instances could be run on different transport nodes but I am planning another session with the AI to add multiple group support. It would be handy to have a group for each person with two or more devices, it would work more like Signal then with messages automatically duplicated to all devices.

John.

---

## Reply 1

**CarL_PetErson** · Fri, Nov 13, 2026 12:36 PM

Chatgroups are already a thing, you might want to check those out before burning tokens :)

Tested and working great:
https://github.com/SebastianObi/LXMF-Tools/tree/main/lxmf_distribution_group_extended
https://github.com/SebastianObi/LXMF-Tools/tree/main/lxmf_distribution_group_minimal

Not tested:
https://github.com/thatSFguy/reticulum-group-chat

And yeah, you could use such groups to tackle the multiple device problem, but I think that would be a super clunky workaround. Idk, with a bit of luck that will be solved when Mark gets to implement groups.

---

## Reply 2

**Boltic** · Fri, Nov 13, 2026 1:33 PM

I, too, would like to see an efficient implementation sooner—one that supports sending images, audio, and so on. An idea I’ve been considering is: wouldn't it be better to have two operational modes? One mode would rely on direct transmission and propagation nodes, while the other would allow one of the group members to act as a "server." In this second mode, every message sent within the group would go to that specific member, who would then distribute it to the rest of the group. If the server happens to be offline, we could simply fall back to manual message delivery. It’s somewhat similar to RRC but with a dual-mode approach—built on top of LXMF—and it would also include multimedia capabilities.

---