Write a contract method or separate contract which will confirm multiple accepted requests at once in order to help users save on gas cost of confirming one request at a time

Optimize the layout of components on mobile

To encourage adoption, it needs to be easy to integrate EFD into wallets. A react component should help make it easy to adopt EFD into your own app

Currently, the user that receives the invite has to confirm it and therefore pay the gas for publishing the signature to the blockchain. Create a /confirm/:encodedRequest route which will accept a base64 encoded object similar to the /invite route with the required parameters to publish the signature to the blockchain. The card should show who the invitation is from, who it was accepted by, and a confirm button, which will prompt the user to send the transaction to confirm the invite.

Background

Mainnet and L2 deployments both come with their respective pros and cons. EFD aims to be accessible and cost-effective. Accessibility refers to the ability of clients to easily call contract methods. Mainnet is the most accessible because that is where users currently start off. L2 is less accessible because it requires a user to bridge funds over to start using contracts. Cost-effectiveness refers to the price of interacting with the deployed contracts. e.g. confirming a request. L2s aim to decrease the cost of transactions, which are the most expensive on mainnet.

Idea

Deploy the canonical EFD contract on an optimistic rollup such as Optimism or Arbitrum. Choose the one that gets the most support from wallets. Deploy contracts that can read from those contracts on other chains and mainnet. Optimism allows communication between L1 and L2, which means that we just need to build a contract that reads the Optimistic contract. In the future, similar functionality should be deployable on any chain, even other L2s. L1-L2 messaging requires writing transactions on L1, which will not be viable. A REST API will have to be written and hosted to make it accessible via the web.

Pros

• Confirmations on L2 should be cheaper

Cons

• Contract interaction becomes more complex
• Support won't be great at the start
• Web API needs to be developed

Add the contract's address to the contract hash arguments to prevent signatures from being reused on other contracts where the same input data is used.

Write a contract method or separate contract which will remove multiple friends from the user's account at once in order to help users save on gas cost of removing one friend at a time.

Use local browser storage to store accepted invites. This would be shown above the user's friends when the user views their own account