anish-agnihotri / weve

A Weavemail client implementation—private, decentralized and open source mail, built on Arweave.

Latest beta is deployed at weve.email and in the deploy-b5 branch.
The master branch is for feature development only.

weve.

weve is a prototype decentralized mail system, running on the Arweave network, according to the Weavemail protocol specifications, built during New York Blockchain Week.

It is deployed to the Arweave permaweb, so its messages and the web app itself are permanent and always available.

How is it built?

weve uses the Arweave HTTP API, Arweave JS, and is deployed with Arweave Deploy.

Speaking to its technical implementation, it makes extensive use of sessionStorage capabilities (for temporary storage of keyfiles and drafts) and react-router-dom for mail-client application-level routing.

weve offers an enhanced experience over the original Weavemail protocol implementation, by offering a variety of new features, including:

1. Simplified, familiar UI/UX
2. Session-based keyfile storage
3. Markdown-extensible message bodies.
4. Session-based mail drafts.
5. Mobile-responsiveness.

How does it work?

Sending messages

1. Messages are encrypted with the recipients public key using RSA-OAEP.
2. After encrypting the message contents for the recipient, messages are packaged into an Arweave transaction, signed, tagged, and submitted to the network.

Receiving messages

1. ArQL is used to collect messages from the network. The query asks for transactions that are a) addressed to you and b) tagged with App-Name: permamail.
2. When you click on a message to view it, the transaction is pulled from the network and decrypted using your private key.

Additional info

• Arweave.org
• Weavemail

Goals

1. The first goal for this bounty was to build your own version of a WeaveMail client. My submission is a completely new and improved platform built keeping in mind the basic principles of the WeaveMail protocol (and complete backwards compatibility), and catering to an audience coming from a Web 2.0 background. The client significantly improves loading messages speed, and the UI is new and fully mobile-responsive.
2. The second goal for this bounty was in regards to the WeaveMail UI. Weve has been built from scratch, using no external UI/CSS frameworks (in pursuit of reduced dependencies and fast loading). It is built adhering to modern ReactJS practices, and the UI/UX emulates that of a conventional email client (to simplify on-boarding for new users and those familiar with Web 2.0 email clients).
3. The third goal for this bounty was in regards to incorporating existing features and new features. Weve is a fully-backwards-compatible client implementation, meaning it works with the original WeaveMail application without a hitch. All existing functionality of the original WeaveMail client has been implemented. In addition to existing functionality, significant additional functionality has been added, as discussed in the Highlighted Features section.
4. The fourth goal for this bounty was in regards to deployment on the permaweb. Weve has been deployed to the permaweb for ~a week now, and is accessible at http://weve.email.

Hackathon criteria

• Submissions must be your original work.
• Previously published dApps aren't eligible to participate in this bounty.
• You must make your full source code available over Github and it needs to include an OSS license. Which one is up to you.
• Complete all the goals set in the Goals section.

Highlighted Features

1. Simplified/familiar UI/UX.

2. Session-based keyfile storage.

3. Markdown-extensible message bodies.

4. Session-based mail drafts.

5. Sent mail outbox.

6. Mobile-responsiveness.

7. Additional mail functionalities (quick reply, download raw content, save draft, delete draft)

8. Live mail confirmation tracking with a notifications panel

9. Improved error handling via toast notifications

10. Direct add email receiver via URL (a.k.a quick-links to send individuals mail), with /inbox/to=address format.

11. Experimental: Contacts

12. and much more...

Community Feedback

To gauge as much community feedback as possible, I released beta versions of Weve to the Discord community early-on. In this way, I was able to collect valuable feedback from users, hands-on, and implement it directly towards application improvements. Some of the feedback I iterated upon included:

1. Virtualizing inbox list to improve performance for users with >100 mails in their inbox (kudos @tiamat).
2. Cached transactions post-first-load to reduce network requests and improve performance (kudos @SystemWizard).
3. Added an outbox (aka sent page) to show outgoing mail transactions (kudos @tiamat, @woombash).
4. Added error handling for insufficient balances (kudos @dwrx).
5. Updated text copy of keyfile upload to make more user-friendly (kudos @woombash).
6. and more... (you can see full changelogs in the weavemail-client channel in Discord)

Significant design decisions

1. The first significant design decision that I analyzed was prompting the user to confirm the transaction fee (validation) when composing a mail. In earlier beta versions of Weve, the user would be prompted to confirm the fee that they were paying for sending a transaction. Upon analysis, though, I found that at any given point of time, the cost of sending even a large markdown mail would be minimal if any (in the 1/1000s of a cent, at least at current permaweb usage benchmarks). Thus, to reduce friction and make the experience as seamless as possible for an average Web 2.0 user, I've removed the fee validation.
2. The second significant design decision that I analyzed was the use of sessionStorage vs localStorage. In my opinion, a large majority of individuals working on this bounty will have likely opted to use localStorage. After conducting some research, and asking various individuals their preference through Discord, I found that localStorage is a very insecure means of saving secure keyfile data. Since it is exposed to every single website, and lasts for the complete browsing session, any malicious website can easily retrieve your keyfile from storage. As such, saving data like the keyfile and mail drafts in localStorage could prove to be harmful for user security. As such, I opted to use sessionStorage instead which is limited to a browser-tab and domain scope, significantly increasing the security of the users data. Although it adds some minimal friction (the user has to re-upload their keyfile should they close the tab), it is well worth it for the added security.
3. I debated adding an account page to weve, but ended up choosing against it. The only information I would be able to show on an account page would be an individuals address and their wallet balance, which I felt were not necessary and would retract from the core-focus of the mail client.
4. Experimental feature: Contacts. This is an experimental feature I choose to include, which lets users save frequent addresses as contacts (that they can easily send mail to in the future). It uses a repository account (a.k.a, when you create a contact, it sends a transaction to the repository from your account). This is currently experimental since it requires significantly more testing before I am happy with its functionality. For the time being, though, it is fully operational (albeit without encrypting the contact data with your public_key, so be careful if you're linking names to addresses—it will be public to the complete blockchain should they choose to parse it).

weve's Issues

Sign up with google.

Doesn't signing up with Google make us subject to the Google privacy policy?