From d5db92d7b03314686439a5b4950e83a70bac304e Mon Sep 17 00:00:00 2001 From: Sergej Sakac <73715684+Szegoo@users.noreply.github.com> Date: Wed, 5 Apr 2023 16:49:46 +0200 Subject: [PATCH 1/7] Dotflow --- applications/Dotflow.md | 179 ++++++++++++++++++++++++++++++++++++++++ 1 file changed, 179 insertions(+) create mode 100644 applications/Dotflow.md diff --git a/applications/Dotflow.md b/applications/Dotflow.md new file mode 100644 index 00000000000..c64844812f7 --- /dev/null +++ b/applications/Dotflow.md @@ -0,0 +1,179 @@ +# 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 two smart contracts coded in ink!, and a React.js-based user interface. + +The first 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 second contract. + +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. + +The second contract will be an address book that enables users to store the `IdentityNos` of the people they are most frequently engaged with . Each user will have the option to create their own address book, where they can add a nickname to each identity to differentiate them easily. + +The UI we are going to build will serve the purpose of interacting with both of our contracts. 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 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 token to. Based on all of this the UI will query the first 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. + +Our ink! smart contracts will be deployed on the Astar network. + +### UI Design +The UI will consist of three main parts: + +- My Identity page +- Transfer page +- Address book page + +#### My Identity page +![My Identity page](https://i.postimg.cc/288CDys6/1-1-dashboard-1.png) + +The user will be able to create his own identity and provide the addresses that he owns on different chains. + +![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) + +#### 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. + +![Add identity](https://i.postimg.cc/TwzSg9j3/3-1-Address-book-2.png) + +### 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 that was explained above. This includes functionality for creating an identity, adding addresses to an identity, updating the addresses of an identity. We will also implement the routing function that will return the proper destination address based on input arguments. | +| 2. | My Identity page | We will make a UI that will allow users to interact with the Identity Contract. Users will be able to access all of the functionality from the Identity Contract by using this UI | + + +### Milestone 2 Example — Additional features + +- **Estimated Duration:** 1,5 month +- **FTE:** 1,5 +- **Costs:** 11,000 + +| Number | Deliverable | Specification | +| -----: | ----------- | ------------- | +| **0a.** | License | MIT | +| **0b.** | Documentation | Both contracts 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 before being deployed to the Astar network. 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 Contract | We will write the code for the address book contract. This will contain the functionality for creating an address book, adding and modifying addresses. | +| 2. | Routing functionality. | We will write the logic for constructing XCM messages that will route the tokens to the proper address. In case the destination chain is same as the origin there will just be a simple transaction. The code for this will be stored on the frontend. +| 3. | Address Book page | We will make a UI that will allow users to interact with the Address Book Contract. Users will be able to access all of the functionality from the Address Book contract by using this UI | +| 4. | Transfer page | We will make a UI that will allow users to send tokens by setting the destination to some `IdentityId`. The UI will abstract addresses away and take care of the routing. | + + +## 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 From c94e687caa6ac70f43b823b1f297a0e58a41912d Mon Sep 17 00:00:00 2001 From: Sergej Sakac <73715684+Szegoo@users.noreply.github.com> Date: Thu, 6 Apr 2023 20:53:32 +0200 Subject: [PATCH 2/7] Update Dotflow.md --- applications/Dotflow.md | 16 +++++++--------- 1 file changed, 7 insertions(+), 9 deletions(-) diff --git a/applications/Dotflow.md b/applications/Dotflow.md index c64844812f7..bb3b5d90883 100644 --- a/applications/Dotflow.md +++ b/applications/Dotflow.md @@ -30,8 +30,6 @@ When a user wants to transfer some tokens to an identity the user will only have 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. -Our ink! smart contracts will be deployed on the Astar network. - ### UI Design The UI will consist of three main parts: @@ -142,8 +140,8 @@ Please also provide the GitHub accounts of all team members. If they contain no | **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 that was explained above. This includes functionality for creating an identity, adding addresses to an identity, updating the addresses of an identity. We will also implement the routing function that will return the proper destination address based on input arguments. | -| 2. | My Identity page | We will make a UI that will allow users to interact with the Identity Contract. Users will be able to access all of the functionality from the Identity Contract by using this UI | +| 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 include the functionality for creating an identity, adding addresses that are mapped to specific blockchains and updating these addresses in case some of them change over time. The Identity contract will automatically create an `identityNo` which will be a unique identifier for an identity. | +| 2. | My Identity page | The My Identity page will be written in React.js and it will make it possible for users to interact with the Identity contract. This includes creating an identity, adding addresses to an identity and removing an address from the identity. From this UI users will be able to easily access and copy their `identityNo` so that they can send it to someone. This UI will be based on the mock 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). | ### Milestone 2 Example — Additional features @@ -156,13 +154,13 @@ Please also provide the GitHub accounts of all team members. If they contain no | -----: | ----------- | ------------- | | **0a.** | License | MIT | | **0b.** | Documentation | Both contracts 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 before being deployed to the Astar network. The functionality for generating XCM messages will very well tested to make sure the tokens are always transfered to the proper destination. | +| **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 Contract | We will write the code for the address book contract. This will contain the functionality for creating an address book, adding and modifying addresses. | -| 2. | Routing functionality. | We will write the logic for constructing XCM messages that will route the tokens to the proper address. In case the destination chain is same as the origin there will just be a simple transaction. The code for this will be stored on the frontend. -| 3. | Address Book page | We will make a UI that will allow users to interact with the Address Book Contract. Users will be able to access all of the functionality from the Address Book contract by using this UI | -| 4. | Transfer page | We will make a UI that will allow users to send tokens by setting the destination to some `IdentityId`. The UI will abstract addresses away and take care of the routing. | +| 1. | Address Book Contract | We will write the code for the Address Book contract using ink! so that our contracts can be compiled to wasm and deployed to any blockchain that implements the contracts pallet. The Address Book contract will include the functionality for creating an address book and filling it out with identities the user interacts with the most frequently. | +| 2. | Routing functionality. | The code that will route the tokens to the proper destination will be part of the frontend code written in typescript. This code will include the logic for constructing XCM messages that will route the tokens to the proper address. In case the destination chain is same as the origin there will just be a simple transaction. +| 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 make a UI written in React.js that will allow users to send tokens by setting the destination to some `IdentityId`. The UI will abstract addresses away and take care of the routing using the Routing functionality that we described in the section 2. inside this table. This UI will also be based on the mock design 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). | ## Future Plans From e87f50df2ba40c85a1ab67a537b9669ee110e2b0 Mon Sep 17 00:00:00 2001 From: Sergej Sakac <73715684+Szegoo@users.noreply.github.com> Date: Mon, 10 Apr 2023 11:40:13 +0300 Subject: [PATCH 3/7] Describe milestones better --- applications/Dotflow.md | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/applications/Dotflow.md b/applications/Dotflow.md index bb3b5d90883..e72958a98a6 100644 --- a/applications/Dotflow.md +++ b/applications/Dotflow.md @@ -140,8 +140,8 @@ Please also provide the GitHub accounts of all team members. If they contain no | **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 include the functionality for creating an identity, adding addresses that are mapped to specific blockchains and updating these addresses in case some of them change over time. The Identity contract will automatically create an `identityNo` which will be a unique identifier for an identity. | -| 2. | My Identity page | The My Identity page will be written in React.js and it will make it possible for users to interact with the Identity contract. This includes creating an identity, adding addresses to an identity and removing an address from the identity. From this UI users will be able to easily access and copy their `identityNo` so that they can send it to someone. This UI will be based on the mock 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). | +| 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. 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 @@ -157,10 +157,10 @@ Please also provide the GitHub accounts of all team members. If they contain no | **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 Contract | We will write the code for the Address Book contract using ink! so that our contracts can be compiled to wasm and deployed to any blockchain that implements the contracts pallet. The Address Book contract will include the functionality for creating an address book and filling it out with identities the user interacts with the most frequently. | -| 2. | Routing functionality. | The code that will route the tokens to the proper destination will be part of the frontend code written in typescript. This code will include the logic for constructing XCM messages that will route the tokens to the proper address. In case the destination chain is same as the origin there will just be a simple transaction. +| 1. | Address Book Contract | We will develop the code for the Address Book contract using ink! so that our contracts can be compiled to wasm and deployed to any blockchain that implements the contracts pallet. The Address Book contract will enable users to create an address book and populate it with the identities they interact with most frequently. | +| 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. | 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 make a UI written in React.js that will allow users to send tokens by setting the destination to some `IdentityId`. The UI will abstract addresses away and take care of the routing using the Routing functionality that we described in the section 2. inside this table. This UI will also be based on the mock design 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). | +| 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 From 9fcc8b7ddbf4e01e6fb31a7b96950ad8fc4f21cf Mon Sep 17 00:00:00 2001 From: Sergej Sakac <73715684+Szegoo@users.noreply.github.com> Date: Thu, 27 Apr 2023 14:38:23 +0200 Subject: [PATCH 4/7] Update Dotflow.md --- applications/Dotflow.md | 252 ++++++++++++++++++++++++++++++++++------ 1 file changed, 214 insertions(+), 38 deletions(-) diff --git a/applications/Dotflow.md b/applications/Dotflow.md index e72958a98a6..20a64ad87a2 100644 --- a/applications/Dotflow.md +++ b/applications/Dotflow.md @@ -1,177 +1,353 @@ -# Dotflow +# 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: + + +## Project Overview :page_facing_up: -### Overview + + +### Overview + + + +#### Problem -#### 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 + + +### Project Details + + Our project will comprise of two smart contracts coded in ink!, and a React.js-based user interface. + + The first 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 second contract. + + 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. + + The second contract will be an address book that enables users to store the `IdentityNos` of the people they are most frequently engaged with . Each user will have the option to create their own address book, where they can add a nickname to each identity to differentiate them easily. + + The UI we are going to build will serve the purpose of interacting with both of our contracts. 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 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 token to. Based on all of this the UI will query the first 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. -### UI Design + + +### UI Design + The UI will consist of three main parts: + + - My Identity page + - Transfer page + - Address book page -#### My Identity page + + +#### My Identity page + ![My Identity page](https://i.postimg.cc/288CDys6/1-1-dashboard-1.png) -The user will be able to create his own identity and provide the addresses that he owns on different chains. + + +The user will be able to create his own identity and provide the addresses that he owns on different chains. + + ![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) -#### Transfer page + + +#### 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 + ![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. + +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. + + ![Add identity](https://i.postimg.cc/TwzSg9j3/3-1-Address-book-2.png) -### Ecosystem Fit + + +### 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 + + +#### Target Audience + Our target audience is people who deal with sending assets frequently over the Polkadot network. -## Team :busts_in_silhouette: + + +## Team :busts_in_silhouette: + + -### Team members +### Team members + + - Sergej Sakac [Szegoo](https://github.com/Szegoo) + - Oliver Lim [cuteolaf](https://github.com/cuteolaf) -### Contact + + +### Contact + + - **Contact Name:** Sergej Sakac + - **Contact Email:** sakacszergej@gmail.com + - **Website:** https://github.com/Szegoo -### Legal Structure + + +### Legal Structure + - **Registered Address:** Kanalska 7 Novi Sad Serbia + - **Registered Legal Entity:** MASTER UNION LLC. -### Team's experience + + +### Team's experience + + + +#### [Sergej Sakac](https://github.com/Szegoo) -#### [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) + + +#### [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 +- [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) + + +### 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: + + +## Development Roadmap :nut_and_bolt: -### Overview + + +### Overview + + - **Total Estimated Duration:** 2,5 months -- **Full-Time Equivalent (FTE):** 1.5 FTE + +- **Full-Time Equivalent (FTE):** 1.5 FTE + - **Total Costs:** 19,000 USD -### Milestone 1 Example — Basic functionality + + +### Milestone 1 Example — Basic functionality + + - **Estimated duration:** 1 month -- **FTE:** 1,5 + +- **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. 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 +### Milestone 2 Example — Additional features + + - **Estimated Duration:** 1,5 month -- **FTE:** 1,5 + +- **FTE:** 1,5 + - **Costs:** 11,000 + + | Number | Deliverable | Specification | + | -----: | ----------- | ------------- | + | **0a.** | License | MIT | + | **0b.** | Documentation | Both contracts 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 Contract | We will develop the code for the Address Book contract using ink! so that our contracts can be compiled to wasm and deployed to any blockchain that implements the contracts pallet. The Address Book contract will enable users to create an address book and populate it with the identities they interact with most frequently. | -| 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. + +| 1. | Address Book Contract | We will develop the code for the Address Book contract using ink! so that our contracts can be compiled to wasm and deployed to any blockchain that implements the contracts pallet. The Address Book contract 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. | + +| 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: +## 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: + + +## Additional Information :heavy_plus_sign: + + **How did you hear about the Grants Program?** GitHub From 7febd3862940eeb1a6c608bbeeda7f70e050bd61 Mon Sep 17 00:00:00 2001 From: Sergej Sakac <73715684+Szegoo@users.noreply.github.com> Date: Thu, 27 Apr 2023 14:41:40 +0200 Subject: [PATCH 5/7] Remove accidental empty lines --- applications/Dotflow.md | 248 ++++++---------------------------------- 1 file changed, 36 insertions(+), 212 deletions(-) diff --git a/applications/Dotflow.md b/applications/Dotflow.md index 20a64ad87a2..8f87666bbdd 100644 --- a/applications/Dotflow.md +++ b/applications/Dotflow.md @@ -1,353 +1,177 @@ -# Dotflow - - +# 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: +## Project Overview :page_facing_up: - - -### Overview - - - -#### Problem +### 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 - - +### Project Details Our project will comprise of two smart contracts coded in ink!, and a React.js-based user interface. - - The first 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 second contract. - - 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. - - The second contract will be an address book that enables users to store the `IdentityNos` of the people they are most frequently engaged with . Each user will have the option to create their own address book, where they can add a nickname to each identity to differentiate them easily. - - The UI we are going to build will serve the purpose of interacting with both of our contracts. 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 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 token to. Based on all of this the UI will query the first 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. - - -### UI Design - +### UI Design The UI will consist of three main parts: - - - My Identity page - - Transfer page - - Address book page - - -#### My Identity page - +#### My Identity page ![My Identity page](https://i.postimg.cc/288CDys6/1-1-dashboard-1.png) - - -The user will be able to create his own identity and provide the addresses that he owns on different chains. - - +The user will be able to create his own identity and provide the addresses that he owns on different chains. ![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) - - -#### Transfer page - +#### 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 ![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. - - + 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. ![Add identity](https://i.postimg.cc/TwzSg9j3/3-1-Address-book-2.png) - - -### Ecosystem Fit - - +### 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 - +#### Target Audience Our target audience is people who deal with sending assets frequently over the Polkadot network. - - -## Team :busts_in_silhouette: - - +## Team :busts_in_silhouette: -### Team members - - +### Team members - Sergej Sakac [Szegoo](https://github.com/Szegoo) - - Oliver Lim [cuteolaf](https://github.com/cuteolaf) - - -### Contact - - +### Contact - **Contact Name:** Sergej Sakac - - **Contact Email:** sakacszergej@gmail.com - - **Website:** https://github.com/Szegoo - - -### Legal Structure - +### Legal Structure - **Registered Address:** Kanalska 7 Novi Sad Serbia - - **Registered Legal Entity:** MASTER UNION LLC. - - -### Team's experience - - - -#### [Sergej Sakac](https://github.com/Szegoo) +### 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) - +#### [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) + - ... -- [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 - - +### 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) - - +### 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: +## Development Roadmap :nut_and_bolt: - - -### Overview - - +### Overview - **Total Estimated Duration:** 2,5 months - -- **Full-Time Equivalent (FTE):** 1.5 FTE - +- **Full-Time Equivalent (FTE):** 1.5 FTE - **Total Costs:** 19,000 USD - - -### Milestone 1 Example — Basic functionality - - +### Milestone 1 Example — Basic functionality - **Estimated duration:** 1 month - -- **FTE:** 1,5 - +- **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. 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 - - +### Milestone 2 Example — Additional features - **Estimated Duration:** 1,5 month - -- **FTE:** 1,5 - +- **FTE:** 1,5 - **Costs:** 11,000 - - | Number | Deliverable | Specification | - | -----: | ----------- | ------------- | - | **0a.** | License | MIT | - | **0b.** | Documentation | Both contracts 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 Contract | We will develop the code for the Address Book contract using ink! so that our contracts can be compiled to wasm and deployed to any blockchain that implements the contracts pallet. The Address Book contract 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. | - | 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 -## 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: - - +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: - - +## Additional Information :heavy_plus_sign: **How did you hear about the Grants Program?** GitHub From 7d88a4e94ef2a3d37455250c9750074fb3bd9c94 Mon Sep 17 00:00:00 2001 From: Sergej Sakac <73715684+Szegoo@users.noreply.github.com> Date: Mon, 22 May 2023 14:10:53 +0200 Subject: [PATCH 6/7] Update Dotflow.md --- applications/Dotflow.md | 45 ++++++++++++++++++++++++++++++----------- 1 file changed, 33 insertions(+), 12 deletions(-) diff --git a/applications/Dotflow.md b/applications/Dotflow.md index 8f87666bbdd..fec14b597ae 100644 --- a/applications/Dotflow.md +++ b/applications/Dotflow.md @@ -17,18 +17,33 @@ To mitigate these challenges, we aim to simplify the user experience by abstract ### Project Details -Our project will comprise of two smart contracts coded in ink!, and a React.js-based user interface. +Our project will comprise of a singe smart contract coded in ink!, and a React.js-based user interface. -The first 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 second contract. +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. -The second contract will be an address book that enables users to store the `IdentityNos` of the people they are most frequently engaged with . Each user will have the option to create their own address book, where they can add a nickname to each identity to differentiate them easily. +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. -The UI we are going to build will serve the purpose of interacting with both of our contracts. 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 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 token to. Based on all of this the UI will query the first contract and based on that create a transaction that will route the tokens to the proper address. +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. +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: @@ -38,9 +53,9 @@ The UI will consist of three main parts: - Address book page #### My Identity page -![My Identity page](https://i.postimg.cc/288CDys6/1-1-dashboard-1.png) +[![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 that he owns on different chains. +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) @@ -48,6 +63,10 @@ In case some of the addresses the user owns change over time he will be able to ![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) @@ -59,7 +78,9 @@ Ther user will be able to transfer tokens to an identity by specifying the origi 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. -![Add identity](https://i.postimg.cc/TwzSg9j3/3-1-Address-book-2.png) +[![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 @@ -141,7 +162,7 @@ Please also provide the GitHub accounts of all team members. If they contain no | **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. 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. | +| 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 @@ -153,11 +174,11 @@ Please also provide the GitHub accounts of all team members. If they contain no | Number | Deliverable | Specification | | -----: | ----------- | ------------- | | **0a.** | License | MIT | -| **0b.** | Documentation | Both contracts 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. | +| **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 Contract | We will develop the code for the Address Book contract using ink! so that our contracts can be compiled to wasm and deployed to any blockchain that implements the contracts pallet. The Address Book contract 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. | +| 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. | From 42b031052c16670685c65a409d91779d0069903a Mon Sep 17 00:00:00 2001 From: Sergej Sakac <73715684+Szegoo@users.noreply.github.com> Date: Fri, 26 May 2023 14:13:55 +0200 Subject: [PATCH 7/7] Update Dotflow.md --- applications/Dotflow.md | 17 ++++++++++------- 1 file changed, 10 insertions(+), 7 deletions(-) diff --git a/applications/Dotflow.md b/applications/Dotflow.md index fec14b597ae..8875dbc10d1 100644 --- a/applications/Dotflow.md +++ b/applications/Dotflow.md @@ -17,15 +17,15 @@ To mitigate these challenges, we aim to simplify the user experience by abstract ### Project Details -Our project will comprise of a singe smart contract coded in ink!, and a React.js-based user interface. +Our project will comprise two smart contracts 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. +One of the ink! contracts will store the user's address-related data in an entity called `Identity`. Each user will have their own `Identity`, containing 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 address book contract and UI. 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. +The second contract will be an address book that enables users to store the `IdentityNos` of the people they are most frequently engaged with. Each user will have the option to create their own address book, where they can add a nickname to each identity to differentiate them easily. Each address book will be attached to a wallet so that when a user logs in with his wallet the UI and provides the `IdentityKey` the frontend will automatically be able to display the address book to the user. -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. +The UI will serve the purpose of interacting with both smart contracts. 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. @@ -34,7 +34,7 @@ In case the origin and destination chain are not the same, the UI will create an 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. +Users will have multiple addresses each attached to a certain blockchain. AES 128-bit ciphers will be generated by the UI per each blockchain. These ciphers will only change if the user changes them when updating an address, otherwise, 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' -- @@ -45,6 +45,8 @@ Each address will be encrypted with the associated cipher before it gets stored 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. +In case we update some of our addresses but we want to restrict access to the users that previously were granted access to that address there will be an option to regenerate the cipher. This way everyone that had access to the old address won't have access to the new one. + ### UI Design The UI will consist of three main parts: @@ -60,8 +62,9 @@ The user will be able to create his own identity and provide the addresses he ow ![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. +Also, we can select the option to regenerate the cipher so that people that had access to the old address won't be able to access the new one. -![Edit Address](https://i.postimg.cc/G2w1rdB2/1-1-create-identity-1.png) +[![1-1-create-identity-4.png](https://i.postimg.cc/509Z5LX0/1-1-create-identity-4.png)](https://postimg.cc/jW9gtWQ0) 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. @@ -178,7 +181,7 @@ Please also provide the GitHub accounts of all team members. If they contain no | **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. | +| 1. | Address Book | We will develop the code for the Address Book contract using ink! so that our contracts can be compiled to wasm and deployed to any blockchain that implements the contracts pallet. 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. The address book will be stored on chain but the `IdentityKey` will be stored in local storage. The application will expect the user to provide the `IdentityKey` when using the app from a different device for the first time. | | 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. |