Group chat functionality?

[johays]

As far as I can see, reticulum already has great direct messaging functionality in both Nomad, Sideband and Meshchat.

What would it require to enable some kind of closed group-chat functionality over Reticulum?
I guess one safe and quite simple way of doing so could be to create a closed network as described here, and use Nomad to broadcast/share messages?

Is this feature considered in any overlay apps like Sideband or MeshChat?
Do you know of any existing chat-infrastructure that is already considering supporting Reticulum that I can support?

I love this project and would be very exited to see this functionality develop somehow. I don't have the coding-skills myself, but I would love to test anything during development.

(edit: added Nomad in mentioning of functional p2p messengers)

[Rick1029]

Cleverly, people have been using forums on Nomad pages as group chats - though they are public since they are forums and connected via TCP. If you had your own LoRa / non-internet connected Reticulum network, you could do the same to get around the lack of group chats.

[LinuxinaBit]

There are many future plans to do group messaging in a fully distributed, Reticulum/LXMF native way.
Until that happens you can always set up something like https://github.com/SebastianObi/LXMF-Tools/tree/main/lxmf_distribution_group_extended

[RandomTNT]

offtopic but will you post more reticulum videos on your channel?

[LinuxinaBit]

will you post more reticulum videos on your channel?

That's pretty unlikely, sorry. I will keep the Reticulum explainer on https://linuxinabit.codeberg.page/ updated though.

[TheJackiMonster]

The problem with distributed group chats is that you can not have proper order of messages since multiple devices could send messages in parallel without being able to enforce a clear order (effectively all messages will be a directed graph... like git commits). You will also run into issues with authorization (which user is able to delete, moderate or edit previous messages? how do you kick one person from a group?).

Additionally you probably want to have forward secrecy against attackers gaining access to your private key eventually. However establishing forward secrecy is really annoying to pull off if you have a fully distributed context with all messages being asynchronous. I've implemented something like this for the GNUnet Messenger service that provides fully distributed group chat functionality and it's not ready for practical use yet, I'd say. But I assume the goal is very similar.

So whoever implements this on Reticulum, I recommend checking that out: https://docs.gnunet.org/latest/developers/apis/messenger.html

Otherwise you probably end up with a federal approach like Matrix, I assume. But they still have issues with moderation like all moderators/admins of chat groups can't loose their privileges for example. It's difficult.

[LinuxinaBit]

This sounds like centralized moderation to me.

You can't have it both ways. Even Matrix requires someone to be designated as a group/room administrator.
If you want to be able to deal with malicious members, you have to have someone in charge to decide what "malicious" means!

You need centralized moderation of some kind in order for a group chat to be usable.
It's about trust, not connectivity. Centralizing moderation/key distribution does not necessarily centralize connectivity.

Besides, anyone else can create another group with the same people in it. I don't see the problem; this is how group messaging has worked for years.

[TheJackiMonster]

You can't have it both ways. Even Matrix requires someone to be designated as a group/room administrator. If you want to be able to deal with malicious members, you have to have someone in charge to decide what "malicious" means!

You need centralized moderation of some kind in order for a group chat to be usable. It's about trust, not connectivity. Centralizing moderation/key distribution does not necessarily centralize connectivity.

Besides, anyone else can create another group with the same people in it. I don't see the problem; this is how group messaging has worked for years.

Matrix had the issue for years that one malicous user gaining moderation privileges being a one-way function causes a whole group chat to shutdown. Enforcing the recreation of a group chat with all previous messages from history being reset. If you think this is no issue to users then I can't convince you otherwise, I assume. I personally think it's a huge problem.

It doesn't matter that users can create a new group with new admins... who is actually gonna do so in practice instead of switching back to a centralized messaging application? - Nobody.

That's exactly the reason why distributed applications like this fail. Because people do not understand that usability is a security concern. If you can't hold users, all of your other security and privacy measurements become pointless.

[LinuxinaBit]

That is not what I am suggesting at all.

Let me pose a scenario:
Say you're running a Discord guild. Discord is a centralized messaging application.
You transfer ownership of the guild to someone else. They are now the owner.
What can you do if they happen to be malicious? Basically nothing. Oops.

What about messaging services where everyone in a group has equal admin privileges?
In that situation you give up any control you have over bad actors. If someone lets a malicious member in, they get admin privileges, and then that group chat just has to be replaced. I wonder why services doing that are incredibly uncommon!

Even SMS has this problem, and the solution it takes is to literally make the "group chat" only identifiable by its members.
Added someone to an SMS group chat? It's a new group chat now. Want to remove someone? Congratulations, you just made another new group chat.

This is not a Reticulum specific problem.
This is not a decentralized group chat specific problem.
It is a problem inherent to any trust-based system.
Every group chat application, centralized or not, suffers from it.

Granting someone unilateral access to modify a room's canonical member list is the same as giving them ownership/admin privileges of the room.
This is very easy to mitigate by having properly implemented permission management and by using said permission management to avoid giving such elevated privileges to bad actors.

I hope this makes sense.
I was never saying that this wasn't a problem; just that it's a relatively easy problem for LXMF group messaging to solve, just like every group messaging application before it.

[TheJackiMonster]

The difference I see between Discord and a distributed service without actual consistency when it comes to timing of messages:

Let's say Alice is admin of the group chat and trusts Bob be moderator or admin. However Bob turns out to abuse that power. Can Alice revert that step? In case of Discord: Yes, typically you have enough different role layers of privileges and the owner has more permissions than any other role. In the case of the distributed service, we couldn't even properly tell when someone else gained permission. So we couldn't tell when they loose permission either. That means whatever they could do... as long as they utilize the time window with such permissions, they could continue doing that.

So sure, for text messages timestamps might not really matter. But in the bigger picture, message order is really important. Otherwise you create this one-way scenario from matrix: Alice trusts Bob, Bob is admin now, the whole chat is blocked.

[LinuxinaBit]

You're not wrong, message ordering is important, but I don't believe that's a major problem when it comes to moderation.
If you let someone modify the canonical members list then re-distribute keys, it's like allowing them to perform a Matrix room upgrade. The member that does the key re-distribution gains complete control over the room.
So yes, it is a one-way action (assuming the other member doesn't allow you to do the same thing), but the key re-distribution step actually provides a pretty clear cutoff for permissions. Issues can crop up with IRC-like netsplit stuff, but I assume there are ways of handling that.
The easier solution is to simply not make software capable of letting another member do key re-distribution, but that wouldn't be as flexible and is probably a worse solution.