Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Dotflow #1657

Merged
merged 7 commits into from
May 31, 2023
Merged

Dotflow #1657

Changes from 6 commits
Commits
Show all changes
7 commits
Select commit Hold shift + click to select a range
d5db92d
Dotflow
Szegoo Apr 5, 2023
c94e687
Update Dotflow.md
Szegoo Apr 6, 2023
e87f50d
Describe milestones better
Szegoo Apr 10, 2023
9fcc8b7
Update Dotflow.md
Szegoo Apr 27, 2023
7febd38
Remove accidental empty lines
Szegoo Apr 27, 2023
7d88a4e
Update Dotflow.md
Szegoo May 22, 2023
42b0310
Update Dotflow.md
Szegoo May 26, 2023
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
198 changes: 198 additions & 0 deletions applications/Dotflow.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,198 @@
# Dotflow

- **Team Name:** Sergej Sakac & Oliver Lim
- **Payment Address:** 0x1e86CD18E4443B5f57b0133077954Cd84896964d (USDC)
- **[Level](https://github.com/w3f/Grants-Program/tree/master#level_slider-levels):** 2

## Project Overview :page_facing_up:

### Overview

#### Problem
We can most certainly agree that the future is multi-chain. As such, it is not uncommon for users to hold multiple accounts across various chains for reasons such as distinct address formats and security benefits. However, this practice presents a challenge in managing multiple addresses. Adding to the complexity is the need to verify the address of the intended recipient, as it may have changed over time.

In summary, there are two key challenges to address: the management of multiple addresses and making sure the addresses of the recepients did not change in the meantime.

To mitigate these challenges, we aim to simplify the user experience by abstracting away the complexity of address management.

### Project Details

Our project will comprise of a singe smart contract coded in ink!, and a React.js-based user interface.

The ink! contract will store users' address-related data in an entity called `Identity`. Each user will have their own `Identity`, which will contain their addresses across different chains. The Identity creators will be responsible for updating their addresses if any changes occur. Every Identity will be assigned a unique `IdentityNo`, which will serve a crucial purpose in the UI and the end user experience.

Additionally, this contract will feature a function that, based on input arguments, will return the appropriate destination address for token transfers. This function will mainly be used by the user interface.

We are also going to add address book functionality, but for privacy reasons, the address book data won't be stored on the blockchain, instead, it will be stored locally on the users' device. Users will be able to optionally assign nicknames to these identities for easier identification.

Other than the address book functionality, the UI will serve the purpose of interacting with the identity smart contract. Users will be able to create an identity and customize the addresses of their identity. Using the UI users will also be able to create their address book and customize it. The most important functionality the UI will provide will be the routing.
When a user wants to transfer some tokens to an identity the user will only have to worry about the token, origin and destination chain, and the identity they want to send the tokens to. Based on all of this the UI will query the identity contract and based on that create a transaction that will route the tokens to the proper address.

In case the origin and destination chain are not the same, the UI will create an XCM message that will route the tokens to the proper blockchain. For the XCM transaction to work there has to be an existing XCM channel between the two blockchains.

### Privacy
Most of us don't want to share all of our addresses with the rest of the world. For that reason, we are including some privacy features that will keep all our addresses private.
All of the addresses in the identity smart contract will be encrypted with a secret key.

Users will have multiple addresses each attached to a certain blockchain. AES 128-bit ciphers will be generated by the UI per each of these blockchains. These ciphers will not change over time and they will always be the same for the associated blockchain.
Ciphers will be created when creating an identity or when adding a new blockchain address to the identity. These ciphers will be stored in a structured format so that the frontend code can associate each cipher with a blockchain. Ciphers will be stored locally in the following format:
```
-- We will call this data the 'Identity Key' --
blockchain_name_1:cipher_1;blockchain_name_2:cipher_2;...and so on
```
Each address will be encrypted with the associated cipher before it gets stored in the identity contract. This will ensure that no one has access to an identity's addresses simply by reading the contract's state.

To share an identity with someone the `Identity Key` will also be needed to be sent together with the `IdentityNo`. In case an identity doesn't want to expose all of their addresses to someone else, but only some of them, it is possible to send part of the `Identity Key` that contains the ciphers for the blockchain addresses he wants to share.
Of course, the user won't need to do this task manually, the UI will make this task very simple. The following section will show how this will work from the user's perspective.

### UI Design
The UI will consist of three main parts:

- My Identity page
- Transfer page
- Address book page

#### My Identity page
[![1-1-dashboard-2.png](https://i.postimg.cc/nLt38NpZ/1-1-dashboard-2.png)](https://postimg.cc/dh42rHhS)

The user will be able to create his own identity and provide the addresses he owns on to his identity.

![Add Address](https://i.postimg.cc/jdKdPQS5/1-1-create-identity.png)

In case some of the addresses the user owns change over time he will be able to edit them.

![Edit Address](https://i.postimg.cc/G2w1rdB2/1-1-create-identity-1.png)

When sharing their identity users will also be able to select which addresses will be available for the person they are sending their identity to. The user will have to copy his `identityNo` but also the `identityKey` which specifies which addresses are accessible for the user that receives this key.

[![1-1-create-identity-2.png](https://i.postimg.cc/BnhvGMML/1-1-create-identity-2.png)](https://postimg.cc/fV9scj4D)

#### Transfer page
[![2-1-transfer-1.png](https://i.postimg.cc/Cx9ZCHpB/2-1-transfer-1.png)](https://postimg.cc/75MYwz6w)

Ther user will be able to transfer tokens to an identity by specifying the origin chain, destionation chain, and the receiver's `identityNo`.

#### Address Book page
![Address book page](https://i.postimg.cc/QtXyT9kK/3-1-Address-book.png)

The user will be able to add identities to his own address book. The identities will be added by providing the `identityNo` and some nickname for the identity.
Also by clicking on the transfer icon on one of the identities the user will be redirected to the transfer page where the `identityNo` will be automatically filled out.

[![3-1-Address-book-3.png](https://i.postimg.cc/xT5snzHN/3-1-Address-book-3.png)](https://postimg.cc/PPLbMNSd)

When adding an Identity to an address book the user will also be required to provide the Identity Key which will be used for decrypting the identity's addresses when sending tokens.

### Ecosystem Fit

This project fits perfectly with the Polkadot ecosystem because it has everything we need to make it work. Polkadot is a multi-chain network, so a lot of users have different addresses on different chains for the same reasons we mentioned earlier. That's why the problems we talked about are important in this ecosystem.

XCM is going to be a core component of our project since it'll help us transfer tokens between the parachains and the relay chain.

#### Target Audience
Our target audience is people who deal with sending assets frequently over the Polkadot network.

## Team :busts_in_silhouette:

### Team members

- Sergej Sakac [Szegoo](https://github.com/Szegoo)
- Oliver Lim [cuteolaf](https://github.com/cuteolaf)

### Contact

- **Contact Name:** Sergej Sakac
- **Contact Email:** sakacszergej@gmail.com
- **Website:** https://github.com/Szegoo

### Legal Structure
- **Registered Address:** Kanalska 7 Novi Sad Serbia
- **Registered Legal Entity:** MASTER UNION LLC.

### Team's experience

#### [Sergej Sakac](https://github.com/Szegoo)
- More than three years of programming experience
- Active contributor to [Substrate](https://github.com/paritytech/substrate/pulls?q=is%3Apr+author%3ASzegoo)
- Member of the [fellowship](https://github.com/polkadot-fellows/seeding/pull/36)
- Contributor to [rmrk-pallets](https://github.com/rmrk-team/rmrk-substrate/pulls?q=is%3Apr+is%3Aclosed+author%3ASzegoo)

#### [Oliver Lim](https://github.com/cuteolaf)
- Full stack blockchain developer with 5+ years of experience
- Quick learner and active contributor to open source projects
- [Fair Squares](https://github.com/fair-squares/fair-squares)
- [Imbue Network](https://github.com/imbuenetwork)
- [Anagolay Network](https://gitlab.com/anagolay/anagolay)
- ...

### Team Code Repos

We will be working on two separate repos, one for the UI and the other for the ink! contracts.

- https://github.com/TheDotflow/dotflow-ui
- https://github.com/TheDotflow/dotflow-ink

Please also provide the GitHub accounts of all team members. If they contain no activity, references to projects hosted elsewhere or live are also fine.

- https://github.com/Szegoo
- https://github.com/cuteolaf

### Team LinkedIn Profiles (if available)

- http://linkedin.com/in/sergej-sakac-334a47252
- https://www.linkedin.com/in/oliver-lim-2215a8235/

## Development Roadmap :nut_and_bolt:

### Overview

- **Total Estimated Duration:** 2,5 months
- **Full-Time Equivalent (FTE):** 1.5 FTE
- **Total Costs:** 19,000 USD

### Milestone 1 Example — Basic functionality

- **Estimated duration:** 1 month
- **FTE:** 1,5
- **Costs:** 8,000

| Number | Deliverable | Specification |
| -----: | ----------- | ------------- |
| **0a.** | License | MIT |
| **0b.** | Documentation | Ink! contracts and the UI code will be well documented and open for everybody to take a look. The UI will be simple and intuitive to use. |
| **0c.** | Testing and Testing Guide | The Identity ink! contract will be well tested with unit and integration tests. |
| **0d.** | Docker | We will provide a Dockerfile that can be used to test all the functionality delivered with this milesone. |
| 1. | Identity Contract | We will write the code for the Identity contract using ink! so that our contracts can be compiled to wasm and deployed to any blockchain that implements the contracts pallet. The Identity contract will provide a range of functions, including creating an identity, adding addresses that are mapped to specific blockchains, and updating these addresses as needed. The contract will automatically generate a unique identifier, referred to as `identityNo`, for each identity. To ensure maximum security, we will allow the identity creator to specify the accounts that are authorized to modify the identity's addresses. This will enable the creator to retain control of the identity even if they lose access to the account used to create it.|
| 2. | My Identity page | The My Identity page will be developed using React.js, providing users with a user-friendly interface to interact with the Identity contract. This will include the ability to create a new identity, add or remove addresses associated with an identity, and access and copy the unique `identityNo` to share with others. This UI will also generate the `Identity Key` for the user's identity and will update it every time he adds a new blockchain address. This `Identity Key` will be accessible for the identity creator when sharing his identity. The interface will be based on the mock design presented in the [UI design](https://github.com/Szegoo/Grants-Program/edit/application/applications/Dotflow.md?pr=%2Fw3f%2FGrants-Program%2Fpull%2F1657#ui-design) section. |


### Milestone 2 Example — Additional features

- **Estimated Duration:** 1,5 month
- **FTE:** 1,5
- **Costs:** 11,000

| Number | Deliverable | Specification |
| -----: | ----------- | ------------- |
| **0a.** | License | MIT |
| **0b.** | Documentation | The contract and the website code will be well documented and open for everybody to check. The UI will have a simple UI that will be intuitive to use. |
| **0c.** | Testing and Testing Guide | The Address Book ink! contract will be well tested with unit and integration tests. The functionality for generating XCM messages will very well tested to make sure the tokens are always transfered to the proper destination. |
| **0d.** | Docker | We will provide a Dockerfile that can be used to test all the functionality delivered with this milesone. |
| 0e. | Article | We will publish a Medium article that explains the details of our project. |
| 1. | Address Book | We will develop the code for the Address Book in typescript. This will be added to the frontend code. The Address Book will enable users to create an address book and populate it with the identities they interact with most frequently. The identities will be added via their identityNo since our main goal is abstracting away addresses from the users. When adding an identity to an address book the Identity Key will also be needed. All of the address book data will be stored locally on the user's browser local storage. |
| 2. | Routing functionality. | The code responsible for routing tokens to the correct destination will be incorporated into the frontend code written in TypeScript. This code will incorporate the necessary logic for constructing XCM messages to route tokens to the appropriate address. In cases where the destination chain is the same as the origin, a simple transaction will be executed. Because of possible race conditions where the identity owner is trying to update an address on a parachain while another user is trying to send funds to that identity on that parachain we introduce additional checks on the frontend. Before sending a transaction that will transfer the funds, the frontend will check whether there are any pending transactions happening that would change the address on the chain the user is transferring funds to. In case there is a pending transaction the user will get a warning and will be advised to wait for a moment and try sending the transaction again. |
| 3. | Address Book page | We will write the code for the Address Book UI using React.js. The UI will be based on the provided mock design that we displayed above in the [UI design section](https://github.com/Szegoo/Grants-Program/edit/application/applications/Dotflow.md?pr=%2Fw3f%2FGrants-Program%2Fpull%2F1657#ui-design). The UI will make it possible for users to create an address book and add identities to it. |
| 4. | Transfer page | We will create a user interface using React.js that will enable users to send tokens to a designated `IdentityId`. This UI will abstract away the complexity of addresses and leverage the Routing functionality described in this table(Section 2) to handle token routing. The UI design will be based on the mock design presented in the [UI design](https://github.com/Szegoo/Grants-Program/edit/application/applications/Dotflow.md?pr=%2Fw3f%2FGrants-Program%2Fpull%2F1657#ui-design) section for optimal user experience. |


## Future Plans

Our future plan is to expand our core functionality and add more features so that the tokens can be routed based on some different criteria. Some example of these ideas are:

- Route tokens based on the amount, sender and/or the token itself
- Split the transferred amount to multiple addresses

An exciting feature we would like to build in the future is enable token transfers between blockchains that are not part of the Polkadot network(e.g. Polkadot<->Ethereum).

## Additional Information :heavy_plus_sign:

**How did you hear about the Grants Program?** GitHub