-
Notifications
You must be signed in to change notification settings - Fork 2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Dotflow #1657
Dotflow #1657
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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?
@Noc2 @semuelle Thanks for reviewing my application quickly and asking me good questions.
Yes, I will put more details into the deliverable tables.
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.
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.
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.
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 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
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. For example: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
@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.
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 address book will only be keeping the
Block explorers deal with addresses. We want to abstract the addresses away by introducing a new structure we call |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.)?
@Noc2 I will add the pending transaction feature to the deliverables.
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. Regarding storage expenses, the data that an address book would store is pretty minimal, only |
@Noc2 I've updated the milestone deliverables to include the "pending transaction" feature. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
@semuelle Thanks for your review. Regarding this problem, I have provided a solution that can pretty much solve this issue:
This essentially means that the user will create multiple identities and when sending someone one of his |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@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.
Unfortunately, I am leaning more to @semuelle's side on this application and won't approve it. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
(see above) |
@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? |
Sure. Let me reopen it. |
@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. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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?
@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. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
@Szegoo regarding this:
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:
But in other places you seem to indicate that it's stored on-chain (in the identity contract):
|
Yes, we are aware of that, but we can still use HRMP.
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. @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 :) |
@Szegoo thanks for elaborating, that definitely helped understanding your plans better.
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? |
@takahser Locally in the address book we are only storing the 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 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. 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. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@Szegoo thanks for lining out the differences. I'm happy to give it a shot, good luck!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
We do not get into the specifics of how the
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.
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.
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
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. |
@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. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm still happy to go ahead with it.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
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. |
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
Application Checklist
project_name.md
).@_______:matrix.org
(change the homeserver if you use a different one)