Taking part in these events is a great way to meet the wider community, but the primary reason for taking part in the event was to progress Mailchain. We set ourselves this criteria as being crucial for any ideas we would work on:
- Useful for the community — building takes time, and maintaining uses continuous energy.
- Needs to progress our roadmap — we have a prioritised roadmap for everyday development, but we can be flexible for sprints/ prototypes that can be built during a single hackathon session.
- It must use Mailchain in some way — i.e. show how Mailchain can be useful for the wider community, or create an application that sends messages.
At ETHLondon, we started by checking out the sponsors to see if there were any new products we could use to solve roadmap items. Two caught our attention Aztec Protocol and Starkware. They both offer privacy solutions to shield parts of a transaction from prying eyes. It was exciting to explore if a solution could be found to hide the sender of a Mailchain message (or transaction sender).
It was helpful that the sponsor’s founders and technical teams were at the event to assist. We could quickly explain what we were trying to achieve and find out if or how we could use these products. Unfortunately, it became clear that both Aztec and Starkware are able to solve hiding the value of the transaction, but not the sender. It may be something we see in the near future.
Back to brainstorming, late on Friday night we investigated the idea of creating a tool that decentralised applications (or DApp) developers could use to collect Ethereum addresses, to later be used for marketing communication. No need for collecting email addresses.
This neatly fulfilled our first and last criteria, as it would be a useful tool for the community. It would also clearly demonstrate the value of Mailchain.
We hesitated a little because we didn’t want to stray too far from the roadmap without introducing new core features that would help a broad set of users. Our concerns lessened as we started to scope out what would be required, and we realised that bulk sending of messages was a key requirement on our roadmap.
We were ready to build the email marketing tool for web3 powered by Mailchain, called DAppLaunch.
“Users can sign up using their Ethereum address (or ENS) to get notified when your DApp launches. You can send messages to addresses using Mailchain, which handles email-like messaging on Ethereum.”
We had two personas. Alf, an expectant user, keen to know when an upcoming DApp launches. Sarah, a DApp developer who wants to gauge interest in two DApps she plans to launch, as well as keep users up to date with news and offers.
To make it easy for Sarah to collect ethereum account addresses or ENS names, we built an interface where she could create a ‘Site’ for each DApp.
She could then copy/paste generated HTML form code into her own landing pages.
Now when Alf visits Sarah’s landing page, he can fill out the form with his Ethereum address.
Back in the DappLaunch web interface, Sarah can see and manage her contacts (the Ethereum addresses and ENS names that had signed up to each DApp).
Sarah can create a ‘Campaign’ and compose beautiful-looking messages using a drag-and-drop HTML editor, for example, to announce the launch of the DApp or share an update.
Once designed, the campaign message can be sent to the entire contact list using Mailchain.
Alf, and all the other contacts, receive the encrypted Mailchain message from Sarah, which he can access using the Mailchain client.
Using Angular enabled us to move quickly, adding many building blocks, reducing the amount of code we had to write. Styling was achieved using Twitter Bootstrap and ngx-bootstrap. We used Unlayer for the drag-and-drop editor because it looks great and is simple to use.
The Mailchain Web inbox already had some of the code written in Angular for the Mailchain API. For example, for looking up the recipient public keys (used to encrypt messages), resolving ENS names to Ethereum Addresses, and for sending the messages.
Today, sending Mailchain messages in quick succession is likely to have unreliable results, and is currently not recommended due to the way nonces are handled. A relayer is required to support this functionality. We explored running a Gas station network (GSN) as a potential solution, but we also needed to ensure transactions are delivered reliably.
any.sender guarantees delivery of transactions by using a smart contract to set the nonce and gas price on the sender’s behalf. This met most of our needs, we quickly discovered that integration would require some extra work.
Time to test… and it did not disappoint. Messages were sent successfully on Ropsten.
After looking at the sent messages we discovered more about how the relayers send messages. A relayer will use a smart contract to send the transaction, but these are listed as internal transactions. You can see an example.
Mailchain currently uses the Etherscan API to check for received messages. The Etherscan API, does not provide details of the internal transactions that are called. Each internal transaction would need to be looked up via a different RPC call to get the details and determine if it’s a Mailchain message. This is not an efficient way of picking up Mailchain messages because every transaction would need to be looked up individually (which means many API calls). We looked at different approaches so we could reduce the number of calls, and building a customised indexer appears to be the best long term solution.
Pressed for time, we prepared DAppLaunch for the demonstration and showed it to some of the other hackers for feedback. The prototype supported everything Alf and Sarah needed, except the bulk message sending which still required the transaction indexer.
As we worked, we uncovered more requirements we needed to build for Mailchain. For example, DAppLaunch uses the same Typescript bindings for ENS lookups that the Mailchain web client does. Making the bindings available as a separate npm module would be useful for the community. We intend to build out the service calls in a modular way and make them available on npm.
We will also production-ize the any.sender Mailchain message sender, add support for all networks, and release the any.sender Go bindings so they are publicly available.
The Mailchain indexer will also be extended to analyze internal transactions fully supporting messages sent via smart contracts.
Here is the example landing page that we used: https://landing.dapplaunch.xyz.
Feel free to sign up and we’ll send you a Mailchain message once the service fully launches.
Overall it was an exhausting but exhilarating weekend for the team, full of learning, working with the amazing community, and building a valuable tool for DApp developers. We’re looking forward to participating in another ETHGlobal hackathon soon.
The future for DAppLaunch is to get it production-ready and start iterating on features. Examples include, users signing a piece of data to confirm their Ethereum address, being able to schedule a message, or segment contacts by on-chain dimensions (i.e. with a certain balance or type of activity). This could become the leading web 3 marketing platform.
We’ll be working on the following:
- Make DappLaunch production ready. (Update: you can sign up for Early Access here: https://dapplaunch.xyz)
- Make message sending using any.sender production ready.
- Make available the Go bindings for any.sender.
- Add internal transactions to the indexer.
- Investigate Gas station network (GSN) as a relayer.
- Create npm modules for Mailchain. (Update: these can be found on NPM here)
On DappLaunch can be found here:
- Website: DappLaunch.xyz
- Gitcoin Grant: https://gitcoin.co/grants/626/dapplaunch?tab=description (generosity pays off… you’ll skip the waitlist)
On Mailchain can be found here:
- Website: Mailchain.xyz
- Mailchain repository: https://github.com/mailchain/mailchain
- Mailchain Ethereum specification: https://docs.mailchain.xyz/reference/ethereum
Feel free to reach out to the team on your favourite channel.