How should group chats work in decentralized systems?(marindedic.com) |
How should group chats work in decentralized systems?(marindedic.com) |
I did want to point out that Matrix does do distributed eventually-consistent authorization, which is their key invention IMHO. (Rooms are distributed among the homeservers, none of which are privileged over the others. You could (and their long-term plan from back in the day) was to run a tiny little single-device homeserver on every device to achieve P2P.)
It's tricky, but a very cool algorithm! Several entities (including myself as a hobby project) are working in combining the Matrix eventually-consistent CRDT with MLS for encryption for a no-compromise distributed E2EE system. It's possible, but very hard, as you might imagine.
Edit: Here's one academic paper writing up the abstract algorithm behind Matrix https://dl.acm.org/doi/10.1145/3381991.3395399
Best of luck!
In other words, show the kick/invite options to users when it does happen, but destroy and create a new group behind the scenes.
https://github.com/simplex-chat/simplex-chat/blob/stable/doc...
Why is that an issue? It's a fundamental fact about the world that your software will never address. No matter what options you purport to provide, you can't stop people from telling other people what messages they received.
In a decentralized system, messages are sent to a list of recipients. If you don't want someone to receive your message, you can take them off the list of recipients that you send to. But if you send a message to party B, and they recommunicate it to party C, there's nothing you can do about that. The only solutions are (1) to stop communicating with people you don't trust; or (2) to have the guy you want to kick out of the chat group kicked out of the world.
But history (and world-awareness) shows that those periods don't last forever, so having mature decentralized technology ready and warm for periods of crisis or devolotion is hugely valuable in the long term. It can be hard to maintain commitment to maturing and seeding that kind of technology when there's not yet a pressing need, exactly because it's hard to gain enough traction to overcome the relative inconveniences. It's admirable and important work regardless.
And that's where the leader matters -> to make that option executable as a group. Without an agreed authority, it's N separate choices that have to stay consistent forever: one member with a stale roster keeps X in the loop by accident, or X kicks Y while Y kicks X and there are two rosters claiming to be the group. One signed kick says "we stopped talking to X" for everyone.
But then again, you're right. If 4 members want to kick out member#6, but member#5 doesn't want to, there is nothing we can do to stop member#5 from sending everything to member#6. That's not a software-solvable problem.