-
Notifications
You must be signed in to change notification settings - Fork 1
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
Claim by delivery point without specifying slice id #361
Comments
Thank you for reaching out @CharlesCheckley . In order to claim production to consumption you first need to transfer the quantity to the wallet_owner in this case the consumer before you claim the quantity of production against the consumption. This is in order to make sure the data does not leak - https://project-origin.github.io/docs/concept/granular-certificates/transactions/slice.html and it is being used by the underlying cryptographic solution that is described thoroughly in the documentation, to ensure no sensitive data leaks to the public. You could of course make a vanilla interface in your system that bundles these actions for ease of use but my two cents on it would be it is an externality for project origin - if you do this work feel free to share it, we are open for PR's :-). |
Hi @CharlesCheckley, Looking at your request, I have a few questions and comments: As @wisbech said, to claim certificates against each other, they are required to be in the same wallet. So I won't comment more on the Accounts part of your request. In general, the the wallet aims to provide a minimum set of features to enable the core functionality, and all specific business logic should be implemented in ones own business logic layer on top of the wallet. It could be we could add a ability to query certificates based on a filter of the AssetId or other attributes, which one can then use to make the specific claims. But to better understand your request, I would like to ask you a few questions: Given the below data in the wallet
and a request in the format you specified {
"productionAssetId": "asset1",
"consumptionAssetId": "asset2",
"periodStart": "2024-06-06T12:00",
"periodEnd": "2024-06-06T16:00",
"quantity": 12
} What would you expect the result to be? because for the given data, there are multiple ways to fulfill the request, and I would like to understand what you would expect.
Since the system is async in nature, how would you expect the system to handle the case where the request is partially fulfilled, and the rest is not? It would potentially start a large group of transactions, where the result would be a list of transactions ids which you could then use to query the status of the transactions. |
Hi Martin Good spot, I don't know why Elia implemented a start AND end date in their API, but it was aimed to be used for a single interval of 15 minutes (as explained in their description of the API). Apologies, this was misleading in our previous message. I assume this answers your example questions. The pain point for us is to require to provide slice IDs. Your suggestion of "we could add a ability to query certificates based on a filter of the AssetId or other attributes, which one can then use to make the specific claims." would be indeed useful. I think you understand our use case which is to make our life easier when making a claim, knowing that the info we have on our end to make a claim is ID of production device, ID of consumer/metering point, which 15 minute interval and the quantity. And currently it would be quite complicated from this info to make the claim: finding which slices, transferring the right slices to the right wallets, making the claim with the slice IDs, etc. So anything on your end that could simplify this use case (which is the typical "GO use case" for an energy supplier) would help. |
Description
As a user I want to be able to transfer and claim certificate slices without having to specify the slice ids, instead specifying the assets, period start, source and destination wallets and quantity to be transferred.
The slices themselves are considered fungible to me (given they are from the same device, for a given period start) and having this endpoint significantly reduces development complexity.
Basic Example
This endpoint exists in the Energy Track and Trace v1 api as v1/claims/bydeliverypoint
Api Documentation
Example Call:
Drawbacks
No response
Unresolved questions
No response
The text was updated successfully, but these errors were encountered: