search

storacha-network / specs

🏅 Technical specifications for the w3up protocol stack
17 stars 0 forks source link

feat: w3 aggregation #51

Closed vasco-santos closed 1 year ago

vasco-santos commented 1 year ago

Preview

alanshaw commented 1 year ago

I was reading through this and noted down a slightly simplier version (IMO! haha)

https://hackmd.io/ZjfqlXaPRtO39rVzpOqy_A?view

I don't really like using "filecoin" everywhere, this is actually a service for submitting aggregates to another service that makes deals with Filecoin storage providers. It's pretty far removed.

vasco-santos commented 1 year ago

@alanshaw using aggregateCid for initial request is a good approach. We need to define the schema inside only.

I am not sure aggregate is a good naming though. filecoin maybe is not either.

My main concerns at the moment, are the pull based logic Spade is requiring. We would need to keep state in the proxy which I would avoid to the bare minimum and not have state there. This is, w3filecoin should be pulled if Spade will always work like this

alanshaw commented 1 year ago

My main concerns at the moment, are the pull based logic Spade is requiring. We would need to keep state in the proxy which I would avoid to the bare minimum and not have state there. This is, w3filecoin should be pulled if Spade will always work like this

It is only the list of aggregates that spade hasn't pulled yet...🤷‍♂️ I'm kinda ok with that...

I am not sure aggregate is a good naming though.

...but, why? 🙈

vasco-santos commented 1 year ago

@Gozala @alanshaw iterated on this based on previous convos. Essentially, handled 2 out of the 3 key take aways we had:

did not added new state that is between queued and accepted because we currently do not have any new info to add there and talking with Alan we decided maybe not to worry about this for MVP