> What do you mean by “Email is already decentralized”?
I can run my own email server in my basement, or on a VPS.
> But as a user of email provider you are a client to a server in a centralized network.
If I use my own email server, the network is only as centralised as the server itself; there's also nothing stopping me from hosting a second server on the other side of the planet, and using e.g. CockroachDB as the storage backend.
> Eppie is “more decentralized” because it is a p2p network, there are no servers.
What do I point my MX records at, then?
> in Eppie you can generate as many addresses as you want.
This strategy comes with its own shortcomings, and while it's a useful feature, it is not a be-all-end-all. There was a blog post which I can't find now, of some guy who had used it for something like a decade, detailing everything that went wrong with it: you need to keep track of which email you used where; people get confused which address to use to write you; once you decide to have a "primary" address, "for humans only", the scheme is more or less defeated as you can no longer afford to throw it away, etc.
Don't get me wrong - it's very useful to have this, and I think it should be a standard offering from any and every provider. Just like GMail made GB+ of storage space the standard, addresses are in fact cheap. But that doesn't end spam.
> And Whitelist is also in our backlog.
I'm actually more interested in the complementary problem. How do you plan to address deliverability from your end? As I said, self-hosting an email server today is trivial, compared to the effort in ensuring your email doesn't get rejected by @gmail.com, @outlook.com, @yahoo.com, etc. Which is the core reason why email tends to be more centralised nowadays (even if the underlying protocol and infrastructure supports and encourages federation/decentralisation).