Dotflow

[Szegoo]

Project Abstract

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 recipients 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.

We are looking to write a set of ink! contracts and develop a UI that can effectively abstract the addresses from the end user.

Grant level

• Level 1: Up to $10,000, 2 approvals
• Level 2: Up to $30,000, 3 approvals
• Level 3: Unlimited, 5 approvals (for >$100k: Web3 Foundation Council approval)

Application Checklist

• The application template has been copied and aptly renamed (project_name.md).
• I have read the application guidelines.
• Payment details have been provided (bank details via email or BTC, Ethereum (USDC/DAI) or Polkadot/Kusama (USDT) address in the application).
• The software delivered for this grant will be released under an open-source license specified in the application.
• The initial PR contains only one commit (squash and force-push if needed).
• The grant will only be announced once the first milestone has been accepted (see the announcement guidelines).
• I prefer the discussion of this application to take place in a private Element/Matrix channel. My username is: @_______:matrix.org (change the homeserver if you use a different one)

[CLAassistant]

All committers have signed the CLA.

[Noc2]

Thanks a lot for the application. I have a few initial questions/comments:

• Could you add to the milestone deliverable tables that your UI will be based on the mockups? Also, could you add the programming language, etc. (like ink!), there? The milestone tables are usually the requirements of our contracts.
• Could you remove the fact that you plan to deploy it on Astar? We usually try to be as objective as possible when it comes to different parachains and only care about the tech.
• Just from the top of my head: What happens if you potentially run into a race condition? Especially with XCM there might be problematic edge cases.
• It looks like people will be able to add multiple addresses per network. Is there a way to set a default payment address?

[semuelle]

Thanks for the application, @Szegoo. I have some questions and comments, for example

• there is address book functionality in several wallets and frontends, e.g. polkadot.js.org. What's the benefit of using a separate on-chain one?
• Would I have to reconnect my wallet with a different account every time I want to send from a different address, or how could this be handled?

But overall, I have some major concerns about the idea of storing my address book for everyone else to see. The footprint we leave behind with transactions is bad enough, but allowing anyone to query the addresses I own and that I frequently interact with, across all parachains, seems rather risky. Do you know of any comparable projects, perhaps in other ecosystems, that are/were popular?

[Szegoo]

@Noc2 @semuelle Thanks for reviewing my application quickly and asking me good questions.
I will try to answer all of your questions here:

Could you add to the milestone deliverable tables that your UI will be based on the mockups? Also, could you add the programming language, etc. (like ink!), there? The milestone tables are usually the requirements of our contracts.

Yes, I will put more details into the deliverable tables.

Could you remove the fact that you plan to deploy it on Astar? We usually try to be as objective as possible when it comes to different parachains and only care about the tech.

Sure, we are not using any Astar specific feature so our set of contracts can be deployed to any blockchain that implements the contracts pallet.

Just from the top of my head: What happens if you potentially run into a race condition? Especially with XCM there might be problematic edge cases.

Tbh I am not sure how the race condition, in this case, would be different than in any other case if we were to create two XCM messages at the same time. Sorry if I did not understand your question correctly.

It looks like people will be able to add multiple addresses per network. Is there a way to set a default payment address?

The UI mockup gives a somewhat bad example. A user can only store one address per network, so there is no need for a default payment address.

there is address book functionality in several wallets and frontends, e.g. polkadot.js.org. What's the benefit of using a separate on-chain one?

We are aware that there are address book functionalities in several frontends but one of our main features is that inside the address book, we are not storing specific addresses, instead, we are storing IdentityNos.

The reason we do this is that in case the owner of the identity that we have added to our address book changes one of his addresses the identityNo will still remain the same for him. So in essence we don't have to worry about updating our address book and replacing his old address with a new one.
When sending a transaction to a specific identity the UI will query the latest address for that identity on the destination chain we specified and based on that create a transaction.

Would I have to reconnect my wallet with a different account every time I want to send from a different address, or how could this be handled?

To send tokens to an identity the user would have to connect his wallet from which he is sending the funds, so in essence yes every time we are sending transactions from a different account we have to sign the transaction with that account.

I have some major concerns about the idea of storing my address book for everyone else to see. The footprint we leave behind with transactions is bad enough, but allowing anyone to query the addresses I own and that I frequently interact with, across all parachains, seems rather risky.

We are not attaching any kind of metadata(name, email, etc) to an identity so from looking at the identity on its own others could not really figure out the owner of the identity.
However, if you were to send your identityNo to someone that is sending you tokens frequently that person would be able to see all of your addresses.
If that is a problem we allow users to create multiple identities. So in theory this way you would be able to create an identity per every user that is sending you funds or more probably per groups of people.

For example:
Alice may be frequently receiving tokens from Bob but she doesn't want to share her existing identity with him because she does not want him to see all of her addresses. In that case, Alice could create a new identity that would only include the addresses on the chains Bob is sending her funds to. She could then send him this new identityNo of the identity that she created just for interacting with him.
This way Bob wouldn't be aware of all the other addresses Alice owns.

[Szegoo]

@Noc2 @semuelle I have made the description of the milestones more detailed, hope this is better now.

[Noc2]

Sorry for the delay here. Regarding the race condition, I meant, for example, if you update an address and at the same time, someone tries to send you money. Regarding the on-chain address book, isn’t this something that could also be easily handled by the front end? The front end could also replace the old address with the new one automatically. Also, I guess the identities you interact with most frequently are part of any block explorer, etc. But I'm generally already happy to support milestone 1.

[Szegoo]

Regarding the race condition, I meant, for example, if you update an address and at the same time, someone tries to send you money.

@Noc2 This is a very good question. Because of these types of edge cases 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.

Regarding the on-chain address book, isn’t this something that could also be easily handled by the front end?

We want to store the address book information onchain. The front end will be displaying this information and will allow users to interact with the identities added to the address book.

The front end could also replace the old address with the new one automatically.

The address book will only be keeping the identityNos, not the actual addresses. The Identity contract would keep track of the user's actual addresses. The identityNos will only be a reference to actual Identities.

Also, I guess the identities you interact with most frequently are part of any block explorer, etc.

Block explorers deal with addresses. We want to abstract the addresses away by introducing a new structure we call Identities. These will hold the user's addresses and have a unique identifier called identityNo. The reason for this is that this way identity owners are responsible for updating their addresses in case they change. This way the senders don't need to be asking for the receiver's address once they have their identityNo. When having their identityNo they will have access to all their addresses which are kept up to date by the owner.
Using the UI the senders will only select the identityNo of the receiver and specify the origin, destination chain, token, and amount they want to send. Based on this the frontend will query the actual address of the receiver and will construct a transaction.

[Noc2]

Thanks for the quick reply. Could you add the "pending transaction" feature to the milestone deliverables? Regarding the address book, I meant a front-end that stores the identityNo as part of the UI and handles all other functionality that you describe as part of the on-chain address book. My main question here is: Is it really necessary to put this on-chain or what's the benefit of it (since on-chain storage is always more expensive and has potential privacy issues, etc.)?

[Szegoo]

@Noc2 I will add the pending transaction feature to the deliverables.

Is it really necessary to put this on-chain or what's the benefit of it (since on-chain storage is always more expensive and has potential privacy issues

We could theoretically store the address book locally(e.g. browser storage), but that would make this data device-specific. We want to make it so that if a user logs in with his wallet on any device he will have access to his address book.
Also, having an address book is optional, if the user doesn't want to create an address book for reasons like privacy he can still send transactions to identities by providing the identityNos on his own on the transfer page.

Regarding storage expenses, the data that an address book would store is pretty minimal, only identityNos and nicknames.

[Szegoo]

@Noc2 I've updated the milestone deliverables to include the "pending transaction" feature.

[Noc2]

Thanks for the update. I will mark the application as ready for review. I'm still not convinced about the on-chain address book, but I'm happy to approve it and give it a chance.

[semuelle]

Hi @Szegoo, sorry for the late response and thanks for the updates.

To send tokens to an identity the user would have to connect his wallet from which he is sending the funds, so in essence yes every time we are sending transactions from a different account we have to sign the transaction with that account.

We are not attaching any kind of metadata(name, email, etc) to an identity so from looking at the identity on its own others could not really figure out the owner of the identity. However, if you were to send your identityNo to someone that is sending you tokens frequently that person would be able to see all of your addresses.

In this case, I'm afraid I a with @Noc2 on this one. There are few upsides and at least one very big downside, namely putting all addresses that are mine or relevant to me in one place, publicly. Therefore, I won't support this application.

[Szegoo]

@semuelle Thanks for your review. Regarding this problem, I have provided a solution that can pretty much solve this issue:

If that is a problem we allow users to create multiple identities. So in theory this way you would be able to create an identity per every user that is sending you funds or more probably per groups of people.
For example:
Alice may be frequently receiving tokens from Bob but she doesn't want to share her existing identity with him because she does not want him to see all of her addresses. In that case, Alice could create a new identity that would only include the addresses on the chains Bob is sending her funds to. She could then send him this new identityNo of the identity that she created just for interacting with him.
This way Bob wouldn't be aware of all the other addresses Alice owns.

This essentially means that the user will create multiple identities and when sending someone one of his identityNo the receiver will only be able to see the addresses from that identity.
For example, I could work on two projects and I am sending or receiving transactions back and forth with these two projects. Let's say that the first project is sending me GLMR and ACA tokens while the other project is sending me MGX and INTR.
All of these tokens are on different chains so the first project has no need to know about my addresses on the chains they don't use when sending me tokens. The same goes for the second project.
In this case, we can create two identities. One of them will hold my Moonbeam and Acala addresses while the other one will hold my Mangata and Interlay addresses. This way I will have two separate identities and the first project will only know about the Moonbeam/Acala identity while the other one will only know about the Mangata/Interlay identity.

[takahser]

@Szegoo I understand the difficulties that come with managing multiple addresses. However, I do see the validity in the concerns raised by @semuelle regarding privacy implications. In my opinion, an on-chain address book may not be the best solution to this problem. Additionally, it's important to note that relying on wallet users to keep their addresses up-to-date could potentially lead to false security, as addresses may already be outdated.

In this case, we can create two identities. One of them will hold my Moonbeam and Acala addresses while the other one will hold my Mangata and Interlay addresses. This way I will have two separate identities and the first project will only know about the Moonbeam/Acala identity while the other one will only know about the Mangata/Interlay identity.

I think creating multiple identities is not going to solve the problem neither, since they're still stored on-chain and anybody would be able to inspect them, incl. the addresses they contain.

For the reasons stated above, I'm not going to approve the proposal in its current state.

[randombishop]

Unfortunately, I am leaning more to @semuelle's side on this application and won't approve it.
I also think there are already existing primitives to achieve similar UX such as decentralized identity providers and things like ens pns etc.

[Noc2]

Thanks again for the application and all the effort you put into this. However, the rest of the grants committee isn't willing to proceed with it, so I'm closing the application. Let me know if you have any questions, and feel free to apply for another grant.

[Noc2]

(see above)

[Szegoo]

@Noc2 We have been working on a solution to the privacy problem. I was looking to update the application. Is there a chance of re-opening this PR so that we can share the changes we have made?

[Noc2]

Sure. Let me reopen it.

[Szegoo]

@Noc2 As mentioned we have found a solution to the privacy problem and added a new section to the application which explains it in detail. We would really appreciate some new reviews.

[Noc2]

Thanks for the update, and I'm personally still happy to go ahead with it. But is there a reason you have chosen AES which is a symmetric algorithm as far as I know. Doesn't it make more sense to use Public-key cryptography here?

[Szegoo]

@Noc2 The reason we use symmetric key encryption is because it would be easier to manage only one key and we believe that it would be sufficient enough for this use case.

[Noc2]

I personally think that for this kind of use case, public-key cryptography makes more sense. But I'm happy to approve the application anyway.

[takahser]

@Szegoo regarding this:

For the XCM transaction to work there has to be an existing XCM channel between the two blockchains.

Keep in mind that XCMP is not rolled out yet.

Also, I'm a bit confused where the address book data will be stored. On one hand, you're saying it's stored locally:

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. (..)
All of the address book data will be stored locally on the user's browser local storage.

But in other places you seem to indicate that it's stored on-chain (in the identity contract):

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.

[Szegoo]

Keep in mind that XCMP is not rolled out yet.

Yes, we are aware of that, but we can still use HRMP.

Also, I'm a bit confused where the address book data will be stored. On one hand, you're saying it's stored locally:

But in other places you seem to indicate that it's stored on-chain (in the identity contract):

The address book will be stored locally, but the encrypted addresses will be stored in the identity contract. The identity contract will contain data about identities.
An identity consists of multiple addresses each mapped to a different blockchain. But because we don't want to expose all of these addresses they will be encrypted with a cipher(This process is explained in the Privacy section of the proposal).
The identity contract is not an address book. It is used so that each user can create their own identity and fill it out with all of his addresses. Each identity will have a unique identityNo that the identity owner can share with people he does transactions with often. These people can then add the identity to their address book.
Since all of the addresses are encrypted with the Identity Key the person that wants to add an identity to their address book will also need access to the Identity Key(This is explained in the Privacy section and the user's perspective is shown in the Design section).

@takahser I hope I succeeded in answering your questions, but please let me know if some parts of the application are not written clearly enough so that I can try and explain better :)

[takahser]

@Szegoo thanks for elaborating, that definitely helped understanding your plans better.

Yes, we are aware of that, but we can still use HRMP.

That's fine, thanks for clearifying.

Regarding the identities, while I agree you improved security with the recent updates, I'm still not sure why you'd want them to store on-chain. Since you're locally caching them, wouldn't it be easier to create an end-to-end-encrypted communication channel between the two transacting users to transfer the identities? Can you elaborate on the reason to store them on-chain?

[Szegoo]

Regarding the identities, while I agree you improved security with the recent updates, I'm still not sure why you'd want them to store on-chain. Since you're locally caching them, wouldn't it be easier to create an end-to-end-encrypted communication channel between the two transacting users to transfer the identities? Can you elaborate on the reason to store them on-chain?

@takahser Locally in the address book we are only storing the identityNos. The reason why we don't store actual addresses is actually the core idea of our project. I think this is best explained with a simple example.

Example:

Alice is working on a project as a contributor and she is receiving bounty rewards for her work from Bob.

Bob is usually paying her in GLMR on Moonbeam or USDT on Statemint.

Alice created an identity where she stores all of her addresses. Let's say in this example that these addresses are on Moonbeam, Statemint and Acala

She shares her identityNo with Bob and sends her IdentityKey, but only the part that gives access to her Moonbeam and Statemint address.

Bob adds Alice's identity to his address book and now he can send her tokens using the Dotflow interface.

In the case, Alice changes her Moonbeam or Statemint address she just needs to update her identity so that it now contains her new address.
This way Bob doesn't have to worry about Alice changing her addresses since Dotflow will route all of his transactions to the proper address. So in essence our app would always query the latest address from the identity contract before sending a transaction.

If we were to store the addresses locally as you said, Alice would always need to notify Bob about her address change and he would always need to change the addresses in his address book manually.

[takahser]

@Szegoo thanks for lining out the differences. I'm happy to give it a shot, good luck!

[semuelle]

Thanks for the update, @Szegoo. I still have a couple of issues:

• How is my identityKey sent? From what I can see, I have to copy and paste it into some communication channel I have with the receiver?
• If I want to change one address but don't want those I shared the old one with to be able to read it, do I have to delete the old address and create a new one with a new cipher? Or is this not possible?
• Is it still true that I can only save one address per network? Why?

Overall, I think this kind of works now, but while it removes some complexity from reusing addresses, it adds a heap of complexity by introducing new concepts such as identities, identity keys and identity numbers. It's also limited by allowing only one address per network and storing everything in localStorage, meaning it's transient. My wallet's address book automatically converts accounts between chains, syncs with my browser and is integrated into the wallet, so doesn't require an extra frontend.

[Szegoo]

How is my identityKey sent? From what I can see, I have to copy and paste it into some communication channel I have with the receiver?

We do not get into the specifics of how the IdentityKey will be sent, but using some decentralized messaging apps like Element that provide message encryption will be secure enough for sharing the key.

If I want to change one address but don't want those I shared the old one with to be able to read it, do I have to delete the old address and create a new one with a new cipher? Or is this not possible?

Great observation. We didn't actually provide this feature, but the solution to this would be to add an option to generate a new cipher when changing an address. We will update the application to include this option.

Is it still true that I can only save one address per network? Why?

The reason why is because when sending a transaction we don't want the user to deal with addresses. The tokens will be routed based on the destination chain. If you take a look at the future plans we are looking to add support for that. The future plan is to add some other criteria based on which the tokens will be routed. This way it would be possible to have multiple addresses since the destination chain wouldn't be the only criteria.

storing everything in localStorage, meaning it's transient.

After some consideration, we will bring the address book contract back. This won't affect privacy since all of the addresses are encrypted anyway. The IdentityKey will still be stored in the local storage and the application will expect the user to provide it when using the app from a different device for the first time. Will update the application to again include the address book contract.

My wallet's address book automatically converts accounts between chains

Yes, but for example the Moonbeam address I use is not the one associated with my Polkadot address. So in this scenario, your address book won't be actually able to figure out my Moonbeam address.

Thanks for your comments. I will update the application to include the above mentioned changes.

[Szegoo]

@semuelle As promised, I updated the application to include the changes I mentioned in my previous message. We would be really thankful if you could take a look at the changes we have made.

[Noc2]

I'm still happy to go ahead with it.

[keeganquigley]

Thanks all for the deep dives, and thanks @Szegoo for thoroughly answering all of the questions. After reading through all of the comments, I'm satisfied with your research, and it sounds like you've thought a lot about proper key management regarding AES. Perhaps the faster speed and lower computational power of symmetric encryption will benefit the app. This could be an interesting use case for storing data on-chain. Based on your experience with substrate and your reputation in the fellowship, I'm happy to approve it as well.

[github-actions]

Congratulations and welcome to the Web3 Foundation Grants Program! Please refer to our Milestone Delivery repository for instructions on how to submit milestones and invoices, our FAQ for frequently asked questions and the support section of our README for more ways to find answers to your questions.

Before you start, take a moment to read through our announcement guidelines for all communications related to the grant or make them known to the right person in your organisation. In particular, please don't announce the grant publicly before at least the first milestone of your project has been approved. At that point or shortly before, you can get in touch with us at grantsPR@web3.foundation and we'll be happy to collaborate on an announcement about the work you’re doing.

Lastly, please remember to let us know in case you run into any delays or deviate from the deliverables in your application. You can either leave a comment here or directly request to amend your application via PR. We wish you luck with your project! 🚀