"platform protocol": what happens if a space has a storage provider, and someone else adds a second storage provider?

[gobengo]

Scenario:

1. I create a space zSpace and delegate can: *, with: zSpace to Alice
2. I, bengo, add a storage provider to the space provider: "did:dns:free.web3.storage"
3. Alice adds a storage provider to the space provider: "did:dns:free.web3.storage"

What happens?

• Does alice's request suceed?
• In general, can there be more than one provider per space? Yes I think.
• In general, can there be more than one storage provider per space?
  • If not, how does one identify whether a given provider is a 'storage' provider for the sake of preventing multiple
• If more than one storage provider can be added to a space, and 100GiB of files are stored in the space, but then all but 5GiB worth of storage providers are removed, how do peers reason about how long the data will be stored, and who pays?

[gobengo]

I just read over here:

While we recognize that there needs to be a way to communicate "who to bill", that is only relevant if your space has multiple storage contracts. In the MVP we will not support multiple contracts case, we'll do that post MVP.

I still need to finish that long thread, which seems to be a precursor to the spec I read when i asked this question.

In the MVP we will not support multiple contracts case

Does that mean that at 'mvp' there can only be 1 provider in the space?

• If so, maybe for the MVP we shouldn't try to make such a general producer/consumer protocol because we don't have the time to think through all the edge cases. Maybe we just define a 'storageProvider' protocol for spaces and explicitly say that there can only be one at a time. Based on lessons learned in implementing that, we can decide whether/how to specify/implement a more general-purpose producer/consumer protocol.

[Gozala]

If so, maybe for the MVP we shouldn't try to make such a general producer/consumer protocol because we don't have the time to think through all the edge cases. Maybe we just define a 'storageProvider' protocol for spaces and explicitly say that there can only be one at a time. Based on lessons learned in implementing that, we can decide whether/how to specify/implement a more general-purpose producer/consumer protocol.

Reason we’d like to leave it out for mvp is not because we don’t know how or what we want to do, simply because we want to reduce scope. If we allow multiple storage providers we’ll need to allow signaling which to bill for each store operation. It alos complicates UX pieces etc…

since all our plans simply add more storage capacity we don’t need to implement these so leaving it out now seems like a good idea

[Gozala]

Maybe we just define a 'storageProvider' protocol for spaces and explicitly say that there can only be one at a time. Based on lessons learned in implementing that, we can decide whether/how to specify/implement a more general-purpose producer/consumer protocol.

At this point this would mean change more things and spec-ing more stuff. Personally I don’t think it’s better, but chances are I’m biased. If you disagree I think it’s probably best to write up a proposals so we could compare pros/cons with rest of the team.

[Gozala]

It is worth noting that nothing is set in stone here. We do intend to allow one provider at a time, in the future we think we’ll allow multiple and allocate store field in our caps. If we find that it was a bad idea we’ll simply release store field and update spec

[gobengo]

@gozala plan sounds good to me. Just poking to understand. Ty