7 ms·

How should group chats work in decentralized systems?

73 points by Realman78 2mo ago

esafak 2mo ago
The hardest problem is social. Who is going to use this?
- Realman78 2mo ago
  I agree, and since there is no mobile version, this won't replace your whatsapp, and it was never designed for that. The actual people I see using this: - People who want anonymous messaging (I realize that there are already Tor messengers, so the idea was to make this one much more feature rich) - Friend groups that want private group chats without any central dependencies or accounts - security, self-hosting, decentralization and open-source enthusiasts
- swatcoder 2mo ago
  Probably not a ton of people in the largely-peaceful, largely-comfortable world that many people here have only ever experienced. 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.
  - Realman78 2mo ago
    Thank you!
tpah8 2mo ago
One option that you sort-of mentioned but missed: go with the static groups, but don’t let the users feel that. In other words, show the kick/invite options to users when it does happen, but destroy and create a new group behind the scenes.
- Realman78 2mo ago
  I understand the vision, but I would still have to rotate keys through different groups. It doesn't solve anything, it just gives the illusion of a clean group delete-then-rebuild
aeturnum 2mo ago
This is a nice little write up and I kinda feel like the author (sensibly) chose centralization just on a smaller scale. I also think that the algorithm is pretty similar to the og textsecure2[1] protocol signal used (and still uses?) in terms of key generation. It's different in that messages are in a distributed hash table instead of sent through a server and also that there's less cross-verification by chat members, but I'm not sure the author would lose any of their goals by using the signal approach (with distributed storage). [1] https://signal.org/blog/private-groups/ https://signal.org/blog/private-groups/
- Realman78 2mo ago
  The issue with that is that when there is no "leader", there is also no way to guarantee kicking someone out. Signal didn't have the kick option for years, and they only added it once they moved the group state management to the server. Now, is "kicking" a good enough justification to go with the leadership route? That is up for debate...
  - thaumasiotes 2mo ago
    > The issue with that is that when there is no "leader", there is also no way to guarantee kicking someone out. 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.
    - Realman78 2mo ago
      But notice your own option: "stop communicating with people you don't trust." For a group, kick is an option: everyone stops including X, at once. 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.
pizzafeelsright 2mo ago
[flagged]
sandeepkd 2mo ago
Decentralization is not really a feasible option when you have more than one actors. Either you embed the centralization from beginning with some good and verifiable contracts or a certain majority is going to hijack the platform and act as centralized controllers.
- Realman78 2mo ago
  Sure, but what is there to hijack in a messenger platform? The groups basically act as their own separate islands, and everything is signed for their buckets. Worst thing that an attacker can do is hurt availability
  - sandeepkd 2mo ago
    People are generally really smart and resourceful. Specially the ones on the hacking side, boils down to whats available to take advantage of.
    - Realman78 2mo ago
      Yes, and that's what I'm saying - the attach vector is small. There isn't much on the network to take advantage of. It's basically one giant value-encrypted lookup table
miloignis 2mo ago
Neat, thanks for the writeup! I think a single creator-admin for small groups is a nice, simple, and practical design point. 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 https://dl.acm.org/doi/10.1145/3381991.3395399
- Realman78 2mo ago
  This is genuinely cool (and weird that I haven't heard of it). I released the 1.0 version today, but I'm already thinking about improvements for v2. Hopefully you will figure it out and I can implement it for v2 haha Best of luck!
- Arathorn 2mo ago
  P2P Matrix (and Matrix over DMLS) is back as of a few days ago: see https://arewep2pyet.com https://arewep2pyet.com and in particular https://arewep2pyet.com/assets/pdf/2026-07-09%20DWebCamp%20P2P%20Matrix%20-%20A%20New%20Hope.pdf https://arewep2pyet.com/assets/pdf/2026-07-09%20DWebCamp%20P... :)
arto 2mo ago
@Realman78 Have you looked into how SimpleX does it? https://github.com/simplex-chat/simplex-chat/blob/stable/docs/protocol/simplex-chat.md#decentralized-design-for-chat-groups https://github.com/simplex-chat/simplex-chat/blob/stable/doc...
- Realman78 2mo ago
  I've looked now... We have a similar design regarding the leadership roles, with the difference that they support multiple "leaders". However, they use a full-mesh which means sending a message to each user separately. Kiyeovo has "anonymous" mode which routes traffic through Tor. That means that even offline messages that get saved to DHT get routed through Tor. They are already slow as it is when sending 1, now imagine sending 9... Thanks for the suggestion though!
- pineapplepizza5 2mo ago
  [dead]
28304283409234 2mo ago
Like...email? Usenet?
- Realman78 2mo ago
  Sure, the offline delivery part can be thought of as e-mail-ish. Is that what you're going for?
- 627467 2mo ago
  Not sure why you're downvoted but email came to mind too: can't group chat be compared to an email thread with the same set of recipients throughout?
- kmacleod 2mo ago
  Possibly very much like Usenet. In the 80s there was a distributed "Slack-like" (for lack of a better description) distributed BBS network called Citadel (still some sites around now Internet based). I wrote a UUCP clone and UseNet gateway for CitNet and made it available through a Citadel BBS "newsreader" to callers. "uccico unidel ken bitsko macleod" still brings up some results[0] [0] https://groups.google.com/g/alt.bbs/c/QFvfoxxONGU https://groups.google.com/g/alt.bbs/c/QFvfoxxONGU
ellis0n 2mo ago
Like Bitchat https://news.ycombinator.com/item?id=48852405 https://news.ycombinator.com/item?id=48852405
yruzin 2mo ago
[dead]
simonpure 2mo ago
There's a truly decentralized alternative to MLS: Key Agreement for Decentralized Secure Group Messaging with Strong Security Guarantees [0] [0] https://eprint.iacr.org/2020/1281 https://eprint.iacr.org/2020/1281
there_is_try 2mo ago
I am not sorry for commenting that a public blockchain is not a server and it would satisfy this use case.
jazzz 2mo ago
I'm curious what the motivation is for the protocol being decentralized? Being serverless is cool and all, but what makes it worth all the extra complexity and effort? To me the future of decentralized group chats is focused on what's missing from platforms like WhatsApp, Telegram and WeChat: - Verifiable Sender and Conversation Privacy - Censorship Resistance / Permission-less operation - User ownership of their own messaging (no application lock-in) - Harvest Now, Decrypt Later (HNDL) protections While maintaining a similar feature set: - Efficient scalable groups - Recovery from compromised/stolen devices - Accessible UX for non-technical users All design work is managing trade offs, however this approach appears to make some serious concessions: Sender & Social Graph Privacy: Queries in a DHT (like Kademlia) bind the requested key to the requester's IP/Node ID. This would allow the network to be able to reconstruct the social graph, and unmask group membership by associating who is querying for who. Compromise Recovery: Users are unable to rotate their own keys without the creator being online. In the event a device/account is compromised, a user has no mechanism to stop attackers from posting messages on their behalf. Additionally with the group size limits, lack of forward secrecy/post compromise security - My question is, what makes this particular path worth it?
- ozlikethewizard 2mo ago
  Not the author, but to me the main benefit of decentralisation will always be the stability of independence from organisations. If any aspect is centralised, you are dependent on the provider of that service. What if they go out of business, what if the EU make encrypted chat illegal, what if they get coerced by the state to hand over information? An entire class of security issues disappear when you are not dependent on a third party, particularly one that with be subject to state regulation and interference.
- Realman78 2mo ago
  Everything on your list except one is possible with servers + crypto. The exception is permissionless operation. Any server-based design has an "operator" who can be compromised. The network should outlive the operator, function without it. Infrastructure servers that I set up (in order to reduce user onboarding friction) shut down in about 2 weeks. The app will keep working without me. Regarding the extra complexity - the design was "no privileged party at all", the price is the complexity. You're right about the DHT metadata -> queries expose requester IP to nodes on the path, so designing a social graph is possible. However, that is exactly why there are two modes: - fast mode, which basically trades metadata privacy for lower latency and calls - anonymous routes everything (DHT queries also) over Tor Regarding compromise recovery, you're also correct. That is on top of the v2 list. > Additionally with the group size limits, lack of forward secrecy/post compromise security Direct (1:1) chats rotate keys every 15 messages - I thought about a similar approach for group chats, but it turned out to be very noisy, also a v2 feature to address. You mentioned some valid flaws, but none of them seem fundamental/unsolvable. Of course, there is going to be a certain kind of trade-off when going fully decentralized, but these trade-offs are becoming smaller and smaller each day. In return, we are getting our privacy back. There is still a long way to go regarding the things that you mentioned, but also some basic UX: - Mobile app - Anonymous mode Tor alternative (thought about I2P, but it's very slow) - Calls in anonymous mode ...
valentynkit 2mo ago
[dead]

73 points by Realman78 2mo ago

esafak 2mo ago

The hardest problem is social. Who is going to use this?

Realman78 2mo ago
I agree, and since there is no mobile version, this won't replace your whatsapp, and it was never designed for that. The actual people I see using this: - People who want anonymous messaging (I realize that there are already Tor messengers, so the idea was to make this one much more feature rich) - Friend groups that want private group chats without any central dependencies or accounts - security, self-hosting, decentralization and open-source enthusiasts
swatcoder 2mo ago
Probably not a ton of people in the largely-peaceful, largely-comfortable world that many people here have only ever experienced. 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.
- Realman78 2mo ago
  Thank you!

tpah8 2mo ago

One option that you sort-of mentioned but missed: go with the static groups, but don’t let the users feel that. In other words, show the kick/invite options to users when it does happen, but destroy and create a new group behind the scenes.

Realman78 2mo ago
I understand the vision, but I would still have to rotate keys through different groups. It doesn't solve anything, it just gives the illusion of a clean group delete-then-rebuild

aeturnum 2mo ago

This is a nice little write up and I kinda feel like the author (sensibly) chose centralization just on a smaller scale. I also think that the algorithm is pretty similar to the og textsecure2[1] protocol signal used (and still uses?) in terms of key generation. It's different in that messages are in a distributed hash table instead of sent through a server and also that there's less cross-verification by chat members, but I'm not sure the author would lose any of their goals by using the signal approach (with distributed storage). [1] https://signal.org/blog/private-groups/ https://signal.org/blog/private-groups/

Realman78 2mo ago
The issue with that is that when there is no "leader", there is also no way to guarantee kicking someone out. Signal didn't have the kick option for years, and they only added it once they moved the group state management to the server. Now, is "kicking" a good enough justification to go with the leadership route? That is up for debate...
- thaumasiotes 2mo ago
  > The issue with that is that when there is no "leader", there is also no way to guarantee kicking someone out. 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.
  - Realman78 2mo ago
    But notice your own option: "stop communicating with people you don't trust." For a group, kick is an option: everyone stops including X, at once. 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.

pizzafeelsright 2mo ago

[flagged]

sandeepkd 2mo ago

Decentralization is not really a feasible option when you have more than one actors. Either you embed the centralization from beginning with some good and verifiable contracts or a certain majority is going to hijack the platform and act as centralized controllers.

Realman78 2mo ago
Sure, but what is there to hijack in a messenger platform? The groups basically act as their own separate islands, and everything is signed for their buckets. Worst thing that an attacker can do is hurt availability
- sandeepkd 2mo ago
  People are generally really smart and resourceful. Specially the ones on the hacking side, boils down to whats available to take advantage of.
  - Realman78 2mo ago
    Yes, and that's what I'm saying - the attach vector is small. There isn't much on the network to take advantage of. It's basically one giant value-encrypted lookup table

miloignis 2mo ago

Neat, thanks for the writeup! I think a single creator-admin for small groups is a nice, simple, and practical design point. 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 https://dl.acm.org/doi/10.1145/3381991.3395399

Realman78 2mo ago
This is genuinely cool (and weird that I haven't heard of it). I released the 1.0 version today, but I'm already thinking about improvements for v2. Hopefully you will figure it out and I can implement it for v2 haha Best of luck!
Arathorn 2mo ago
P2P Matrix (and Matrix over DMLS) is back as of a few days ago: see https://arewep2pyet.com https://arewep2pyet.com and in particular https://arewep2pyet.com/assets/pdf/2026-07-09%20DWebCamp%20P2P%20Matrix%20-%20A%20New%20Hope.pdf https://arewep2pyet.com/assets/pdf/2026-07-09%20DWebCamp%20P... :)

arto 2mo ago

@Realman78 Have you looked into how SimpleX does it? https://github.com/simplex-chat/simplex-chat/blob/stable/docs/protocol/simplex-chat.md#decentralized-design-for-chat-groups https://github.com/simplex-chat/simplex-chat/blob/stable/doc...

Realman78 2mo ago
I've looked now... We have a similar design regarding the leadership roles, with the difference that they support multiple "leaders". However, they use a full-mesh which means sending a message to each user separately. Kiyeovo has "anonymous" mode which routes traffic through Tor. That means that even offline messages that get saved to DHT get routed through Tor. They are already slow as it is when sending 1, now imagine sending 9... Thanks for the suggestion though!
pineapplepizza5 2mo ago
[dead]

28304283409234 2mo ago

Like...email? Usenet?

Realman78 2mo ago
Sure, the offline delivery part can be thought of as e-mail-ish. Is that what you're going for?
627467 2mo ago
Not sure why you're downvoted but email came to mind too: can't group chat be compared to an email thread with the same set of recipients throughout?
kmacleod 2mo ago
Possibly very much like Usenet. In the 80s there was a distributed "Slack-like" (for lack of a better description) distributed BBS network called Citadel (still some sites around now Internet based). I wrote a UUCP clone and UseNet gateway for CitNet and made it available through a Citadel BBS "newsreader" to callers. "uccico unidel ken bitsko macleod" still brings up some results[0] [0] https://groups.google.com/g/alt.bbs/c/QFvfoxxONGU https://groups.google.com/g/alt.bbs/c/QFvfoxxONGU

ellis0n 2mo ago

Like Bitchat https://news.ycombinator.com/item?id=48852405 https://news.ycombinator.com/item?id=48852405

yruzin 2mo ago

[dead]

simonpure 2mo ago

There's a truly decentralized alternative to MLS: Key Agreement for Decentralized Secure Group Messaging with Strong Security Guarantees [0] [0] https://eprint.iacr.org/2020/1281 https://eprint.iacr.org/2020/1281

there_is_try 2mo ago

I am not sorry for commenting that a public blockchain is not a server and it would satisfy this use case.

jazzz 2mo ago

I'm curious what the motivation is for the protocol being decentralized? Being serverless is cool and all, but what makes it worth all the extra complexity and effort? To me the future of decentralized group chats is focused on what's missing from platforms like WhatsApp, Telegram and WeChat: - Verifiable Sender and Conversation Privacy - Censorship Resistance / Permission-less operation - User ownership of their own messaging (no application lock-in) - Harvest Now, Decrypt Later (HNDL) protections While maintaining a similar feature set: - Efficient scalable groups - Recovery from compromised/stolen devices - Accessible UX for non-technical users All design work is managing trade offs, however this approach appears to make some serious concessions: Sender & Social Graph Privacy: Queries in a DHT (like Kademlia) bind the requested key to the requester's IP/Node ID. This would allow the network to be able to reconstruct the social graph, and unmask group membership by associating who is querying for who. Compromise Recovery: Users are unable to rotate their own keys without the creator being online. In the event a device/account is compromised, a user has no mechanism to stop attackers from posting messages on their behalf. Additionally with the group size limits, lack of forward secrecy/post compromise security - My question is, what makes this particular path worth it?

ozlikethewizard 2mo ago
Not the author, but to me the main benefit of decentralisation will always be the stability of independence from organisations. If any aspect is centralised, you are dependent on the provider of that service. What if they go out of business, what if the EU make encrypted chat illegal, what if they get coerced by the state to hand over information? An entire class of security issues disappear when you are not dependent on a third party, particularly one that with be subject to state regulation and interference.
Realman78 2mo ago
Everything on your list except one is possible with servers + crypto. The exception is permissionless operation. Any server-based design has an "operator" who can be compromised. The network should outlive the operator, function without it. Infrastructure servers that I set up (in order to reduce user onboarding friction) shut down in about 2 weeks. The app will keep working without me. Regarding the extra complexity - the design was "no privileged party at all", the price is the complexity. You're right about the DHT metadata -> queries expose requester IP to nodes on the path, so designing a social graph is possible. However, that is exactly why there are two modes: - fast mode, which basically trades metadata privacy for lower latency and calls - anonymous routes everything (DHT queries also) over Tor Regarding compromise recovery, you're also correct. That is on top of the v2 list. > Additionally with the group size limits, lack of forward secrecy/post compromise security Direct (1:1) chats rotate keys every 15 messages - I thought about a similar approach for group chats, but it turned out to be very noisy, also a v2 feature to address. You mentioned some valid flaws, but none of them seem fundamental/unsolvable. Of course, there is going to be a certain kind of trade-off when going fully decentralized, but these trade-offs are becoming smaller and smaller each day. In return, we are getting our privacy back. There is still a long way to go regarding the things that you mentioned, but also some basic UX: - Mobile app - Anonymous mode Tor alternative (thought about I2P, but it's very slow) - Calls in anonymous mode ...

valentynkit 2mo ago

[dead]