Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

How should group chats work in decentralized systems?

marindedic.com

Post reply on HN
Print view View original

11–20 of 36 posts

Re: How should group chats work in decentralized systems?

#11

Post by swatcoder »

esafak wrote: post #2

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

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.

Re: How should group chats work in decentralized systems?

#12

Post by Realman78 »

sandeepkd wrote: post #9

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.

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

Re: How should group chats work in decentralized systems?

#13

Post by Realman78 »

swatcoder wrote: post #11
esafak wrote: post #2

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

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 techno…

Thank you!

Re: How should group chats work in decentralized systems?

#16

Post by thaumasiotes »

Realman78 wrote: post #7
aeturnum wrote: post #4

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 member…

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...

> 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.

Re: How should group chats work in decentralized systems?

#17

Post by Realman78 »

miloignis wrote: post #10

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…

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!

Re: How should group chats work in decentralized systems?

#18

Post by Realman78 »

arto wrote: post #14

@Realman78 Have you looked into how SimpleX does it? https://github.com/simplex-chat/simplex-chat/blob/stable/doc...

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!

Re: How should group chats work in decentralized systems?

#20

Post by Realman78 »

thaumasiotes wrote: post #16
Realman78 wrote: post #7

Earlier quoted context omitted.

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...

> 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…

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.

Post reply on HN