You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Is your feature request related to a problem? Please describe.
Today (03-11-2022), asset validity is calculated as order timestamp + asset/DDO timeout against current timestamp, thus, would be disaster to the data buyer if:
03-11-2022, Data buyer X but Asset A without timeout of 1 month.
Downloaded the Data A.
04-11-2022, Asset A owner edit the metadata and changed the timeout from 1 month to 1 day.
05-11-2022, Data buyer X order would be expired because is based on the last asset/DDO timeout.
Describe the solution you'd like
As per previous discussion with @alexcos20 , while provider/initialize or provider/initalizeCompute, provider could store either the current Asset/DDO timeout or the expiry timestamp in ProviderData.
Additional context
Market/provider would display/calculate validity based on order timestamp + ProviderData Asset timeout or the expiry timestamp.
Is your feature request related to a problem? Please describe.
Today (03-11-2022), asset validity is calculated as
order timestamp + asset/DDO timeout
againstcurrent timestamp
, thus, would be disaster to the data buyer if:1 month to 1 day
.Describe the solution you'd like
As per previous discussion with @alexcos20 , while provider/initialize or provider/initalizeCompute, provider could store either the
current Asset/DDO timeout
or theexpiry timestamp
in ProviderData.Additional context
Market/provider would display/calculate validity based on order timestamp + ProviderData Asset timeout or the expiry timestamp.
@alexcos20
The text was updated successfully, but these errors were encountered: