So, we are building a peer-to-peer email system where users truly own their addresses and data. We’ve already talked about data — today, let’s focus on addresses.
In traditional email, you don’t truly own your address — you rent it. There are two typical scenarios:
1. An address on a provider’s domain — like [email protected]. That address is essentially owned and controlled by the provider.
2. An address on a “custom” domain — like [email protected]. But even here, you're only renting the domain from a registrar.
In practice, your address seems to be under your control — until it isn’t. You might get suspended for breaking service rules. Someone could impersonate you and gain access. Your domain might expire. At the end of the day, critical decisions are made by the provider. Loss of access happens regularly — and it’s always their decision.
Some real-world examples:
Email today is far more than messaging. It holds licenses, contracts, medical records. It’s the backbone of your online identity — and gateway to hundreds of services. Losing it can be a digital nightmare.
That’s why we’re building a third model. In Eppie, your address isn’t rented. It is created by you — and you fully own it. Even if Eppie were to shut down like Skiff, your address would stay active on the decentralized network. No central authority, no provider lock-in.
Here’s how it works.
In Eppie, your address is created locally on your device as a cryptographic public key. It’s unique, self-generated, and only you hold the private key needed to read and sign messages. Eppie connects to the decentralized network, fetches messages addressed to your key, and decrypts them. The ability to decrypt proves ownership. Concepts like login or authentication are irrelevant — there’s no gatekeeper.
Transport is built on DHT and SBBS, storage on IPFS. More on these in future posts — or explore our GitHub if you're curious.
Eppie addresses are based on compressed secp256k1 public keys (33 bytes). They’re used for ECIES encryption and ECDSA signature verification.
To make addresses human-friendly, they’re encoded in custom Base32 (alphabet: abcdefghijkmnpqrstuvwxyz23456789, excluding o, l, 0, 1 to reduce ambiguity).
Example:
ahejyckdjrciwq9dkdgqmemu26pr5qsmbwhfk4vf65w6sw9ivinig@eppie
This fits standard formats like address@domain and hybrid ones like email+address@domain.
Supported formats:
One of Eppie’s core strengths is flexibility. The hybrid email+address@domain model enables seamless communication between legacy email and decentralized networks.
You can even register your Bitcoin address as an email identity — e.g. bc1qar0srrr7xfkvy5l643lydnw9re59gtzzwf5mdq@eppie. This address can be used for communication within Eppie, and even to receive emails from classic email.
Once you sign a transaction from that address, it’s verified as yours and ready for use.
Other supported formats (coming soon):
We're also working on human-readable aliases through ENS and DNS. Their job is to map a nice name like alice.epp to a cryptographic address. It’s easy to remember, like a traditional email address.
For ENS, the address will look like this: alice.eth.
For DNS — alice.com or alice.site.com, if it's a second-level domain.
And for our decentralized name service, which we also plan to launch — alice.epp or alice@eppie.
***
Email address is your entry point into digital communication. Today, users don’t control it: you either rent a name from an email provider or rent a domain from a registrar.
The address system in Eppie is generated directly on your device, independent of any servers, and cannot be taken away. You can have one address, several, or even a whole hierarchy for different purposes. And no one can tell you what you can or cannot do with them.
Join the waitlist and give us a star GitHub — your support helps us grow. Thank you!