>

Mastodon is not really a chat protocol as much as it is for social media. Still, I think the same issues persist. Your account is tied to a server, and servers talk to servers instead of users to users, on a server.
Product manager here. 
I see a few issues and they’re more UX related. 

With a public/private key managed by the users, what happens when a user inevitably forgets or needs to reset their password? No server is managing it, so a lost password is a lost identity AFAICT. Identity management is a strong reason for centralization. Has this been solved in a decentralized way?
Maybe I missed a detail. How do users select the same trusted server? How is server C negotiated? And what if user A trusts C, D, E and user B trusts F, G, H?
I’m not yet convinced this solves spam. There’s the “pure spam” problem of bots blasting messages blindly to large groups. But the issue users care more about is actually bacn. Bacn occurs anywhere users direct their attention as monetization pressure accumulates.  Decentralizing servers means any group of servers can be purchased/bot netted by an interested enough party and monetized. When you decentralize, you actually take monetary incentive away from a single “trusted” authority by making the cost/value of reputation violation very low. But perhaps I’m missing something cryptographically interesting there too. >


I'm tempted to say that's human error, and that a technically superior solution shouldn't be thrown out because people can't store their keys securely, but if a different solution was necessary, you could use an external service to back up your key, and only return it with E-Mail address access. But something like that should never be required on a protocol level.
You can have addresses just like with E-Mail. For example, User B tells User A that he can be found on example.com. That is the server he registered an account with. User A now joins example.com, and messenges User B (identified by his public key, or a corresponding nickname for convinience). User A wouldn't need an account on example.com, all he needs is a certificate that he has an account on a trusted service. The servers have to trust certificates from other servers. example.com may accept example2.com certificates, because it verified that users of this server are safe. Note that all of this certificate stuff would only be necessary to avoid spam, but the core protocol could function without it. 
Yes, anyone can create their own servers, or buy existing ones, and use it for malicious purposes. But that server would quickly be identified as a potential spam source, and servers wouldn't trust certificates from it anymore, meaning no one who registered there can get in to other servers. >



I mean I guess it depends on your goal. If you want a protocol people can use for secure decentralized chat, you need to solve the PW management issue or it won’t be secure. Because people will just reuse passwords. That’s what they’ll do. If you’re just interested in an academic solution, I could see this getting an A. But real security is practical. Having the protocol not solve the problem but relying on recentralizing services will result in what it resulted in with crypto exchanges. 


I might be missing something but this sounds a lot like e-mail. With all the issues of email. 


So people would occasionally be unreachable? How does user A rediscover user B’s new trustworthy server? >

How does your suggestion different from Discord? >

You can't self host discord, there is only one centralized server. If it went offline, your identity is gone. Futhermore, proprietary applications immediantly disquality as the ideal messaging protocol for me. It must be open source. >

What about mastodon?