Whissage

Whissage is an innovative encrypted messaging app that facilitates confidential question-and-answer conversations between Web 3 users.

Leveraging end-to-end encryption and integration with wallet addresses, Whissage provides a secure environment for users to engage in private Q&A dialogues. They can ask each other questions and provide helpful answers back and forth.

By building on existing wallet infrastructure, Whissage streamlines adoption so users can instantly start private conversations without managing additional keys. This makes onboarding seamless for both crypto natives and Web2 users.

To encourage active engagement, Whissage incentivizes high-quality conversations via economic rewards. Askers attach a small ETH bounty to their questions which answerers receive. This model nurtures a thriving community sharing expertise.

In summary, with robust security, easy onboarding, and incentives, Whissage enables confidential crypto Q&A conversations. The platform promotes accessibility, engagement, and knowledge exchange through private peer-to-peer dialogues.

[What we use from ETHglobal parterners]

1. The project uses RelatoinService from Next.id(Mask Protocol) to help find the web 2 information of the addresses, which will encourage users to send more questions.

2. The main contract is deployed on Scroll and ETH.

[What do users do in Whissage] Alice is a crypto trader, and one day she notices Address Bob (a gifted trader) bought a lot of ETHs.

Alice wants to ask Bob why he did this. To do so, she will:

Enter Bob's wallet address and deposit some ETH into the contract to pay Bob. Compose her question locally and encrypt it with Bob's public key before sending it to him. This ensures only Bob can decrypt the message, not the servers. Bob receives the message and will:

Decrypt it using his private key. To claim the ETH Alice paid, he must reply to her question. To reply, Bob will:

Compose the answer locally and encrypt it with Alice's public key so only she can read it. Send the encrypted reply to Alice. When Alice gets the reply, she can:

Decrypt the message locally using her private key. Bob's Claimable Balance increases so he can withdraw the ETH Alice paid him. The process allows Alice and Bob to have an encrypted Q&A conversation by leveraging public key cryptography to share private messages only they can decrypt. The ETH payment incentivizes Bob to provide a thoughtful reply.

Initially, we investigated existing encryption schemes built on Ethereum.

We found that MetaMask provides eth_getEncryptionPublicKey and eth_decrypt JSON RPC methods that can be used for public key encryption.

However, further analysis showed that eth_getEncryptionPublicKey does not actually bind the encryption key to the user's Ethereum account - it just derives an ECIES public/private key pair using the account's BIP39 mnemonic phrase.

There is no way for a third party to cryptographically verify the relationship between the returned encryption public key and the Ethereum address.

After this failed attempt, we looked into ERC-5630, an Ethereum Improvement Proposal for encryption.

This cleverly utilizes Elliptic Curve Integrated Encryption Scheme (ECIES) to reuse Ethereum's secp256k1 elliptic curve infrastructure to enable asymmetric encryption/decryption.

The main benefit is that if you know someone's Ethereum public key (from any on-chain transaction or signed payload), you can encrypt a message that only they can decrypt.

However, this requires client-side wallet support to decrypt messages, and currently no mainstream Ethereum wallets implement ERC-5630 decryption.

Having exhausted existing options, we set out to build our own protocol.

The approach we took was to have users generate an ECIES key pair locally that is dedicated specifically for end-to-end encrypted messaging.

The user signs the public key with their Ethereum account, registering it on-chain to publicly prove ownership.

Now, when users want to communicate securely, they lookup each other's registered messaging public keys, and use them to ECIES encrypt their messages.

The sender signs the ciphertext to prove authenticity.

Upon receiving a message, the recipient verifies the signature, then decrypts using their private key.

By piggybacking on Ethereum's decentralized identity and signature infrastructure, we can enable trusted discovery of encryption public keys between parties that want to communicate privately. This eliminates the need for a centralized key server while preventing man-in-the-middle attacks.

On the backend, we used web3.py to read on-chain data and parse contract ABIs. Building performant web3 apps in Python can be challenging, but FastAPI and SQLAlchemy allowed rapid HTTP API development.

For the frontend, we used ethers.js to interact with our contracts and Ethereum. For encryption, we used the battle-tested TweetNaCl library exposed by nacl-js. We built a fast SPA with Vue Router and used Naive UI for components. Tailwind CSS was used for custom styling.

The smart contracts were written in Solidity using Remix IDE - boring but reliable technology.

We deployed the frontend on Cloudflare Pages for automatic updates from GitHub. The backend API runs on an AWS EC2 instance with SQLAlchemy connected to a PostgreSQL database.

Together, this architecture allows us to build performant end-to-end encrypted messaging by reusing Ethereum's decentralized capabilities for authentication and public key distribution.