Project Delmonicos milestone 1

[lumena-tech]

Milestone Delivery Checklist

• The milestone-delivery-template.md has been copied and updated.
• The invoice form 📝 has been filled out for this milestone.
• This pull request is being made by the same account as the accepted application.
• In case of acceptance, the payment will be transferred to the initial BTC/ETH payment address.
• The delivery is according to the Guidelines for Milestone Deliverables.

Link to the application PR: w3f/Grants-Program#283

[fcroiseaux]

I don't understand the error. If the google sheet in the one related to the invoice, I've filled it.

[lumena-tech]

I thought it was related to the author but apparently not

[semuelle]

Thanks for the delivery, @lumena-tech & @fcroiseaux. We will look into it as soon as possible.

The check is in fact just for our internal bookkeeping, so nothing to worry about!

[lumena-tech]

Hello, is ti possible to have an idea of the standard duration of the evaluation process of a milestone ?

[alxs]

Hey @lumena-tech. We currently have a bit of a backlog and this is likely to take a couple of weeks. Submitting a milestone shouldn't stop you from continuing to work on the project though. We recommend adding a tag or commit hash to the links in the deliverables so that you can continue to work without breaking anything.

[adetante]

Hi @alxs , thanks for your feedback, I have created a tag (milestone-1) and updated the README to link a specific commit in our source repository.

[mmagician]

@lumena-tech @fcroiseaux I've got a few comments regarding your delivery from my initial review:

---

UserConsent struct in two modules:

pallet-user-consent

• map of hash -> (user_id, charger_id)

pallet-session-payment

• map of AccountId -> (timestamp, iban, bic_code) (of which timestamp is never used - unless I've missed something)

I think the name UserConsent here is slightly misleading (especially if timestamp is not used). To me it sounds more like UserDetails, as it holds the relevant banking information of the user.

---

registrar pallet:
Do you plan to support multiple organisations created by the same account, or rather just having one charger organisation as specified in your docs?

If the use case is to have just one organisation, why not use the membership pallet as you initially suggested in the first milestone?

---

Otherwise everything looks fine. Some unit tests are still missing and there are a few leftover TODOs, but that's ok, as I see you're working on the next milestone already - I expect that would be addressed there?

---

Extra:

PR to update the DID pallet to substrate 3.0. Still in review. Thanks for trying to merge upstream, it would be great to get that in!

[lumena-tech]

@lumena-tech @fcroiseaux I've got a few comments regarding your delivery from my initial review:
UserConsent struct in two modules:

pallet-user-consent

• map of hash -> (user_id, charger_id)

pallet-session-payment

• map of AccountId -> (timestamp, iban, bic_code) (of which timestamp is never used - unless I've missed something)

I think the name UserConsent here is slightly misleading (especially if timestamp is not used). To me it sounds more like UserDetails, as it holds the relevant banking information of the user.

Actually both are user consents but for different things. We should have define more explicit names. We will rename at least one of the two elements.

• pallet-user-consent proves that the user has given his consent to start a specific charging session.
• UserConsent in pallet-session-payment proves that the user give consent to the bank to initiate payment from his account. If you have a look at the current version, we have added a signature that is generated and verified off-chain. The idea is that the user first connects to his web banking site and send a signed chalenge to prove to the bank that he owns a specific private key. For each payment, the signature stored in pallet-session-payment is send to the bank with the timestamp. Then the bank can verify that the initiator of the payment is really the account owner.

registrar pallet:

Do you plan to support multiple organisations created by the same account, or rather just having one charger organisation as specified in your docs?

If the use case is to have just one organisation, why not use the membership pallet as you initially suggested in the first milestone?

Yes, we plan to create several organizations through this registrar pallet. Currently we only have the charger organization, but later we could have an organization that list all the users authorized to access the service, another organization that lists the accounts authorized to add a new charger for example, ... So the goal is to use the registrar to configure these different organizations, and check who can do what.
Another reason why we use the registrar pallet is the fact that we want to use the did-pallet to add trusted attributes to identities (e.g. the location of a charging station).

Otherwise everything looks fine. Some unit tests are still missing and there are a few leftover TODOs, but that's ok, as I see you're working on the next milestone already - I expect that would be addressed there?

Yes, we will complete the tests and the TODO in the upcoming milestones.

Extra:

PR to update the DID pallet to substrate 3.0. Still in review. Thanks for trying to merge upstream, it would be great to get that in!

[mmagician]

@lumena-tech thanks for a prompt response.

We will rename at least one of the two elements.

Do you mean for this milestone? Seeing that you have already done work on top of the current codebase, I understand it might be somewhat tricky if you try to change milestone1 branch and then cherry-pick those commits on your master. It's fine by me if you "fix it" for the next milestone, too. I'll leave that up to you, just let me know if I should wait or proceed.

[lumena-tech]

@lumena-tech thanks for a prompt response.

We will rename at least one of the two elements.

Do you mean for this milestone? Seeing that you have already done work on top of the current codebase, I understand it might be somewhat tricky if you try to change milestone1 branch and then cherry-pick those commits on your master. It's fine by me if you "fix it" for the next milestone, too. I'll leave that up to you, just let me know if I should wait or proceed.

Yes, I meant we will rename for the next milestone if this is ok for you. It will be more easy for us.

[mmagician]

Great. Then I'm happy to announce that your first milestone has been accepted. Please see the evaluation here & good luck with the next phase!

[mmagician]

@lumena-tech Currently your invoice's currency is BTC. As your original contract states USD, please send us an updated invoice using DAI.

Also, something that slipped our attention is that your payment address in the contract is a BTC address. I imagine you'll want a different address for DAI. We'd need an amendment to the above document - please submit a relevant PR to the Open Grants repo. Thanks for understanding!

[fcroiseaux]

I've submitted a new PR with the DAI(ETH) address instead of the BTC address and refilled the invoice form with a new invoice.