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

21–30 of 36 posts

Re: How should group chats work in decentralized systems?

#25

Post by sandeepkd »

Realman78 wrote: post #12
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

People are generally really smart and resourceful. Specially the ones on the hacking side, boils down to whats available to take advantage of.

Re: How should group chats work in decentralized systems?

#27

Post by jazzz »

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?

Re: How should group chats work in decentralized systems?

#28

Post by ozlikethewizard »

jazzz wrote: post #27

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…

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.

Re: How should group chats work in decentralized systems?

#29

Post by Realman78 »

jazzz wrote: post #27

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…

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

Post reply on HN