[New] AEmail - AE Decentralized mail service

Hello, family, it’s a great pleasure to meet you again. I am your old friend Baixin

Application Status

Status: New
Last updated: 13.06.2023
Submitted by Baixin , [email protected]
Team: AeBox Team
Approved Budget (in h):
Used Budget (in h):
Planned Delivery:

Specify the funding category

Open Source Development

Application Title



baixin.chain sunbx (Baixin) · GitHub

Value Application

At present, the mailbox service is basically based on the centralized network, and there are few mail systems in the decentralized network. AE can take advantage of the natural advantages to develop an mail system, which can be quickly promoted by using AENS + smart contracts. Implementation in a layer1 of network

Definition of Terms

Our original intention is to use AEMail like a centralized mail service, which only needs to connect Superhero, such as sending and so on , Ultimately, our goal is the Google email experience

Status Quo

The technical research has been done, the initial idea has been implemented

Required Work

  1. Complete the development of AEMail smart contract
  2. Complete the UI operations
  3. Perform contract and UI data debugging
  4. Conduct the test phase. To the last release


It takes about six months

Known Limitations

I already know a lot about AE, there are no technical limitations at the moment


Aepp has video presentation after all the work is completed And to promote within and outside the community




As long as AE is running here, I will always maintain it


Looking forward to see how this will work :slight_smile:


I think this is an interesting idea but I have a few questions with regards the contract’s contents, namely are all emails public? Do you plan obfuscating the sender, the receiver and email’s contents?


Interesting idea…

Running a decentralized mail service on layer 1 sounds a bit expensive (mainly in terms of duplicated data) - wouldn’t each node have to hold the entire universe of mail. Encrypted or not :thinking:


Yes, the content of the email is encrypted. Consider using asymmetric encryption, or some other way to encrypt the email so that only the recipient and sender can read the content


My teacher, long time no see, all the data exists in the contract, only the sender will pay a small amount of AE to send, the receiver can use the node to obtain data for free. All the information is stored in nodes (which is a headache for Yani, since the blockchain can store it anyway), and the email content is encrypted, either using asymmetric encryption or some other method in the contract to encrypt the data. I’m still working on that


Curious to see any of this ! :ok_hand:

1 Like

Yes, great seing new ideas from you @Baixin.chain !

But I’m thinking of the scale here… As an example, my mailbox (on Google) is ~14GB… The entire aeternity chain (GC:ed) is ~45GB - so I have a hard time seing it scale properly :thinking:

And also each mail would be a contract call, so max rate would be something like ~10 mails/s. Good enough for a PoC/toy example but it wouldn’t be enough if it gets popular?


Application developers never care about server hard disk capacity. That’s something companies should think about.

Similarly, you can block baixin from applying for developer funding, but you can’t stop other people who want to write junk data to AE.

Just like you can’t stop AEX9 Regenerates Points Token(RPT)

It didn’t make much sense, it just created a lot of meaningless TX, but it made another sense, it brought random numbers to SpaceDice.



就像你无法阻止AEX9 Regenerates Points Token(RPT)


1 Like

The data on AE is up for grabs for the highest bidder, that is how it is supposed to be I think.

The point I was trying to make was that there isn’t nearly enough data (or gas) in microblocks to scale an AEmail service very far - so to make the project interesting (from a funding perspective) I think there should be ideas on how to solve this?!


This is the logic of the contract implementation, in theory can be solved, for example, there is a mapping relationship in the contract, only the index is stored in the page, the mail list to get the mail title, while getting the content of a page, this gas should be enough, when opening the mail details, according to the mail index to get the specific content of the mail. In this way, we can avoid the situation where there is a lot of mail and it will cause insufficient gas

1 Like

It’s an interesting idea.

Perhaps it’s an option to only use the AE chain for verification or blacklisting of senders, for example to prevent spam, and pointers to where actual data can be found. Some SSI systems solved a similar scalability problem this way.

So in your particular case perhaps the data itself could be (encrypted) on IPFS and the mail contract would only hold metadata and a pointer to the data on IPFS.


This is theoretically possible, but one problem is that IFPS has a GC mechanism, which will cause mail to be lost if it is not used for a long time or if there is a problem with the node. But it’s a good idea, and it can be done in other ways

1 Like

@aeternity_Foundation Has there been a change of leadership at the foundation? This project has been submitted for a long time without feedback results. Can we continue the email communication? Please leave your email address if possible.

Hey @Baixin.chain

Hope you’re all doing great. Just wanted to drop a quick note regarding your AEMail grant application. First off, huge thanks for bringing such a cool idea to the table! We’re all about pushing the envelope with blockchain here at AE, and your project is right up our alley.

Your app is currently under the microscope (in a good way!), as we’re digging into the nitty-gritty of what you’ve proposed. We’re genuinely excited about the potential for AEMail to shake things up in the email world with a decentralized twist.

Might need a bit more info from you soon, so keep an eye on your inbox. We’ll be in touch with any questions, or just to chat about how things are going.

Stay awesome, and keep innovating.
Catch you soon!

Cheers :wave: :wave:


What about Filecoin? … I think putting emails on the blockchain itself is not feasible (maybe only pointers at most). It would not scale. Imagine 1 million people’s daily emails and all their normal emails and the spam they would get on the aeternity blockchain. What would that be? 100 gigabytes added to the blockchain daily? And what to do with file attachments? Also, many would feel uncomfortable with their email - even encrypted - on the blockchain. I like the idea of using AE somehow, even related to email, but putting emails directly on the chain would not have much confidence from most people. But I really appreciate your motivation and willingness to build on AE! What have you decided or thought about this since?

Another idea that you can consider is using Aeternity as a DNS. Store domain names and IP addresses. Then create browser or browser plugins that can use it as a default or alternate DNS. That could open up an alternate for people that want to have their own customer domain names and even alterante TLD’s… How that might work? I don’t know :slight_smile:

Browsers need something like…
HCTP (Hyperchain Transfer Protocol) :sunglasses:
BCTP (Blockchain Transfer Protocol)
…to access blockchains. I think it’s now safer to say, blockchains are probably not going away.



We considered Filecoin, but ultimately decided not to use it because of the high cost of use and learning, and our vision is to make AEmail accessible to some blockchain newbies. And files can be lost if Filecoin is not accessed for a long time. But you’re right, it’s impossible for an email service to store all of its content on a blockchain. Only the information related to the pointer is stored in the blockchain, and some information about the content of the mail can be stored in AE. Some large files (attachments) are stored in OSS after we consider encryption, and the pointer is set to point to the mail.

1 Like

I haven’t changed my opinion - running mail directly (even with just “pointers”) on top of a blockchain is most likely not a good idea. It will not scale.


Thanks for the creative input @_dog ! Creativity and reasoning about various ideas and concepts is what brings up innovation down the line. Unfortunately filecoin is very, very inefficient in the way it works under its hood. but hey, for the DNS idea: Why don’t you try storing an ACI (aeternity cotract interface) in the text record of a domain, plus an address to the contract which the ACI corresponds to? technically it is all you need to generate a user interface to a dApp. then people could interact with your contract by just entering dogsCoolDapp.com !

1 Like