[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

1 Like

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

1 Like

Curious to see any of this ! :ok_hand:

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