DAOsign #1770
DAOsign #1770
Conversation
|
|
There was a problem hiding this comment.
Thanks for the application. Could you sign our terms and conditions (see the message above)? Also, could you specify which open source license you are planning to use as well as integrate the default deliverables (0a., 0b., etc.) into the second milestone? Furthermore, it's not fully clear to me why you want to integrate the eip712 and eip2771 as ink! smart contracts. Could you add a more detailed explanation as well as potentially link to the existing standards? In most cases, it makes sense to adjust the standards rather than simply reusing them.
|
pinging @Burmenska |
|
Hello , thanks @semuelle for the ping. T&C are signed, I'll be back to you with the answers shortly. |
|
@semuelle hello! the application was updated but there is some error in the CI/CD. can you please help me to resolve it? |
|
Hi @Burmenska. Thanks for the update. Don't worry about the CI, this is just for internal bookkeeping. |
There was a problem hiding this comment.
Thanks again for the application, @Burmenska! I have a couple of comments/questions:
adaptation means that user data is converted to a binary bit
I don't understand this part, can you explain? A bit doesn't hold a lot of information. :)
- There is already a standard an an implementation of ERC721 in ink!: code, website. I would suggest reusing their implementation and removing this deliverable altogether.
- You can leave the license as 'TBD' for now, but please note that it would have to be one approved by OSI.
- Meta transactions require an off-chain relayer. Could you add this to the deliverables?
- Related: there is no Docker deliverable in your milestones. For testing purposes, especially when it includes a relayer, some kind of setup automation would be very helpful.
- Can you be more specific in the specification of your deliverables? Specifications should be verifiable, so ideally for a smart contract it should list its functions or functionality.
- What does 'Application Private Key Management' mean?
- Wouldn't it make sense to split the EIP2771 work into a separate milestone? The rest of the platform works without it, correct? I'm mainly asking because I think this work would be interesting for many others in the ink!/Substrate ecosystem, and having a separate milestone would help
|
hello @semuelle , thanks for your comments, happy to answer, see below: There is already a standard an an implementation of ERC721 in ink!: code, website. I would suggest reusing their implementation and removing this deliverable altogether. Thanks for the link, will update the deliverables. You can leave the license as 'TBD' for now, but please note that it would have to be one approved by OSI. Meta transactions require an off-chain relayer. Could you add this to the deliverables? Related: there is no Docker deliverable in your milestones. For testing purposes, especially when it includes a relayer, some kind of setup automation would be very helpful. Can you be more specific in the specification of your deliverables? Specifications should be verifiable, so ideally for a smart contract it should list its functions or functionality. What does 'Application Private Key Management' mean? Wouldn't it make sense to split the EIP2771 work into a separate milestone? The rest of the platform works without it, correct? I'm mainly asking because I think this work would be interesting for many others in the ink!/Substrate ecosystem, and having a separate milestone would help From the development standpoint, within the RUST workspace we plann to include EIP2771 as a separate subrepository . From the reporting standpoint, it is included into a bigger milestone but if you believe, that it makes sense to separate it, let me know pls. It should not impact neither scope nor duration of the project. |
My understanding of ERC2771 is that a relayer accepts and forwards messages off-chain. It's named
Yes, interfaces are ideal.
There should be some kind of specification for each deliverable that we can refer to during the evaluation, so we can verify that everything was delivered as expected. I don't know what private keys you are planning to store, so I cannot comment on what needs to be included in the application and if.
That works.
Thanks. Please ping me here when you are done updating, I'll have another look then. |
|
pinging @Burmenska |
There was a problem hiding this comment.
Thanks for the update. But to already mention it. Please specify the license already at this stage. You can always amend it later. "most likely there will be Apache 2.0" could mean anything, even a non-open-source license, which is mandatory for this grants program.
|
Hi @semuelle CTO of DAOsign here. Let me step back and start from the beginning. DAOsign propose to store Agreements Proofs on Polkadot chain using Ink! smart contracts. And provide methods to verify signature on-chain. There are two types of users in DAOsign:
Proofs are implemented in EIP-712 standard and signed using user’s EVM private key (using Metamask for example). We are supporting this standard in Ink! smart contract to be able to verify signature. Creator can select option where to store proofs: only on IPFS or also on Polkadot. If they select Polkadot then Creator needs to pay some fee that will be used for transaction gas fee. For that, we are also implementing EIP-2771 standard to allow Agreement Signers gas-free delegation to publish proof on-chain. Here is a sequence diagram describing our process:
We are working on Smart Contract implementation for EVM-based chains, and you can take a look at the code here. This code is still in progress, but it gives some understanding of our approach. Documentation is also available. Answering to your question:
ERC2771 gives as ability to execute delegated call from Signer without making them to pay gas fee. Does it make sense? Let me know if you have any questions or concerns, |
|
Here is technical design and documentation for EVM-based chain integration: |
There was a problem hiding this comment.
Thanks for the updates, @Burmenska and @ramilexe. Some follow-up questions:
applications/DAOsign.md
Outdated
| | 0a. | License | Apache 2.0 | | ||
| | 0b. | Documentation | We will provide both **inline documentation** of the code and a basic **tutorial** that explains how a user can upload/generate the agreement, add signers/observers and complete the signature process with storing signature proofs either in test or mainnet, which will show how the new functionality works. | | ||
| | 0c. | Testing and Testing Guide | Core functions will be fully covered by comprehensive unit tests to ensure functionality and robustness. In the guide, we will describe how to run these tests. | | ||
| | 0d. | Delivery format | We will provide a website that will include the agreement creation, modification and signing functionality for users with further proofs storing on Polkadot chain. |
There was a problem hiding this comment.
0d is usually a Dockerfile or some other setup automation tool to help us and others test the project. Ideally, this would run a local node, deploy and instantiate the contracts or run unit tests on the smart contracts.
There was a problem hiding this comment.
@semuelle @keeganquigley added docker step as 0d
There was a problem hiding this comment.
Thanks @ramilexe typically this is required for all milestones, as I would think the local contract node would be needed for M2 as well. But an npm/yarn package should suffice if its easy to get up and running.
There was a problem hiding this comment.
@keeganquigley I don't see how docker could help with npm/yarn modules. It will be used docker from previous milestone to spin up node with smart contract
There was a problem hiding this comment.
@ramilexe Docker just helps for quickly spinning up a contracts-node to run the smart contract. So no worries, that's fine if it will be the same as the previous milestone.
There was a problem hiding this comment.
@ramilexe I just realised that M2 still doesn't contain the Docker deliverable. Could you please add it? As already mentioned by @keeganquigley it's sufficient if it's the same as in M1, but I think it'd make it easier to evaluate it you'd deliver.
There was a problem hiding this comment.
@takahser @keeganquigley I thought we agreed we don't need docker for M2 because it will contain Javascript library and frontend that usually delivered as a npm module, not docker container
There was a problem hiding this comment.
@ramilexe I think the idea was to use the same docker config file(s) as in M1 to test the integration with the js library. You can add a note that indicates that. Alternatively, you can add a note to the SDK indicating that it will be compatible with the docker deliverable from M1.
There was a problem hiding this comment.
Added docker to m2. Is it ok?
Create a DAOsign application file
Project description update
Adding an information about project purpose
Add info about team members
Adding milestone details
Polkadot address update
There was a problem hiding this comment.
Thanks @Burmenska for the changes and for your thorough answers. The application looks a lot better to me now than last time I looked at it, and I'm willing to go forward with it as well. LGTM.
|
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. |
|
@semuelle @Noc2 @keeganquigley @dsm-w3f @nikw3f , great news, we greatly appreciate the level of detail and attention you paid to our application, as well as all your questions. We are thrilled about receiving the grant and are super enthusiastic about this partnership.we will review the requirements to the delivery process together @ramilexe and I'll be back to you in case of any questions. Thanks! |
|
Don't hesitate to contact us if you have any questions, @Burmenska. |
|
Hi @Burmenska are you able to provide an update on M1? |
|
hello @keeganquigley, thanks for your patience. @ramilexe , DAOsign CTO already has everything in place and is preparing a PR. I will update you once the pull request is committed, it should happen in the nearest days. |
|
Hi @keeganquigley |
|
Hi @Burmenska @ramilexe how is milestone 2 coming along? Are you able to provide an update? |
|
Hi @Burmenska @ramilexe are you still working on this grant? As I noticed there haven't been any commits to the repo in quite some time. Thanks for any info you can provide. |
|
Hello @keeganquigley , I hope you’re doing well. I’m really sorry for the delivery delays and for the inconvenience it caused you. I haven’t been part of the DAOsign team since April and unfortunately can’t provide updates on this matter. However, let me pass your request to @ramilexe and another colleague who is currently responsible for grants delivery and I'll let you know once I'll have some update. If there's anything else, I can help with, please let me know. Thanks and have a great day! |
|
Thanks for the update @Burmenska much appreciated. @ramilexe let me know if you can confirm. |
|
Hi @keeganquigley |
|
Hi @Burmenska @ramilexe I think we still haven't received a delivery for this yet, correct? |
|
Hi @ramilexe are you still planning to submit a delivery soon? Otherwise we would likely cancel the grant due to inactivity. |
|
@keeganquigley , sorry, as I previously mentioned , I'm not a part of DAOsign team since April 2024. Still, let me pass your request to the team, perhaps @ramilexe just missed it. |
|
@keeganquigley Hi Keegan, We sincerely apologize for the delay and the lack of updates. Unfortunately, we encountered some unforeseen resource issues which affected our timeline. Additionally, we had to implement some technical changes that we didn't initially anticipate. We truly appreciate your patience and understanding, and we are committed to delivering quality work. Thank you once again for your continued support, and we will keep you posted with further updates. Please tag me or @TetianaRiabova for any next messages. |
|
Sounds good @eugeneBskyy thanks kindly for the update. Could you give a few more details about the technical changes? Will this change any of the deliverables? Minor changes are no big deal, but please note that any major changes would require an amendment, if it will change any of the end deliverables. Thanks! |
|
Hi @eugeneBskyy any updates? |
|
Thanks for your patience. The technical changes we implemented are not related to the core functionality that was outlined in the grant. The main challenges we faced were around integration with the app, specifically around generating the correct payload. As a result, we made adjustments to the integration side of things to ensure everything works smoothly. In terms of updates, we are currently preparing the pull request, and the code is in its final review phase. We are targeting to submit the PR for both Milestones 2 and 3 by Thursday. Thank you again for your understanding, and we'll keep you posted. Best regards, |
|
Hi @keeganquigley |
|
Hi @keeganquigley |
Project Abstract
Grant level
Application Checklist
project_name.md).@_______:matrix.org(change the homeserver if you use a different one)