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.
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
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
I have verified that the app works without an issue on clean installations of Ubuntu, Debian and MacOS. I have spent the last 2 days testing the app by pretending to be a malicious user and patched those holes up. I ran the whole app through a detailed security scan using Fable. I went through the whole app and reduced metadata leakage to a bare minimum required by the app to work. I implemented all electron security recommendations. Currently, I'm just doing manual testing which mostly doesnt bring up any bugs, but rather some UI issues (like flickering or text going out of bounds) that I immediately patch
In this blog post, I share my experience of fully letting the AI take over the wheel. My goal was to complete one of my small side-projects without having to think about it (while watching a TV show).
https://github.com/Realman78/Kiyeovo - I'm currently working towards the full release of my P2P dual-network mode messenger which is currently in beta. The reviews were overwhelmingly positive when I released the beta a week ago so that motivated me to try extra hard to make it pseudo-perfect upon full release
Haha, it's roughly pronounced as it's typed out. The name actually comes from a Croatian dialect. "Ki je ovo" translates to "who is this" -> and then when you connect the words and make it english compatible, you get kiyeovo.
If you go to google translate, select Croatian input "kijeovo" and click the speak button, you will hear how it is properly pronounced. Not that I care how people pronounce it, just wanted to share :)
The two modes are in one app for convenience, but they are separate systems. IMO, the risk is not data leaking between mode protocols/DHT, but rather the user linking their identity between the modes through their behavior - reusing usernames, same contacts... So in short, it's ease of use vs the risk of user error
Yes, I agree Tor is not the best anonymity service these days. I2P was my first choice, but the performance was just awful. I did not fully give up on the I2P idea, maybe it was just that day, so I will give it a second choice and mazbe add a third mode or fully replace tor. Not sure since a lot of people are familiar with tor, and not I2P
I appreciate the criticism, really. In the current version users only have to exchange the username or peer ID via third party and then find each other on the DHT...
However, there is also another way, which is already implemented and I am currently writing the how-to on my blog site, and that is using "trusted users". Basically, instead of 2 users trying to find each other on the DHT, they can just export their profiles in the "Profile" section. That prompts them to create a shared secret and exports a ".kiyeovo" file. You send that file to the other party, they click on the "+" in the sidebar header ->"import trusted user", select the ".kiyeovo" file and voila!
I know it's not nearly as convenient as what you're describing, but it's just a more "trustable" way of creating a contact which is also not that inconvenient.
You're right in general. The main mitigation here is that Kiyeovo does not trust unsigned DHT data: the important records are signed and validated. That doesn't fully solve censorship nor eclipse attacks, but it does stop record forgery. The remaining risk is mostly availability/partitioning - bootstrap connectivity (topology) matters a lot here