Realman78

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

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

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.

Sure, the offline delivery part can be thought of as e-mail-ish. Is that what you're going for?

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!

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!

Thank you!

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

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

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

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