In a permissionless incentivized decentralized system, incentive-motivated peers maximize reward and minimize cost.
Since FOC isn't a philantropic/public goods product, many SPs will be incentive motivated.
Unless there is retrieval incentives, or non-retrievability-penalties, for FOC, a good amount of SPs will eventually not serve retrievals, leading to unhappy users.
Retrievals are required for PDP to function to user satisfaction.
It is assumed that SPs participating in PDP will serve retrievals. Based on my experience with Saturn and Spark, I think this is only true for the initial phases of the FOC roll out (closely working with SPs), and will not hold true in the wild and more chaotic growth phase of the product.
In light of the possibility of FilBeam being shut down and deprioritized for FOC, I want to revisit this topic.
The past observations of Filecoin SPs not serving retrievals, and trying to get more SPs to do so, is what lead to the creation of both Filecoin Spark and Filecoin Beam.
One might argue that FOC would notice if SPs don't serve retrievals, through dealbot and user complaints. Then, problematic SPs could be temporarily or permanently blocked. It is my understanding that for now this is the plan to ensure retrievability (on top of only working with trusted SPs, ie: not getting into a permissionless growth phase).
SPs can learn how to serve retrievals to Dealbot but not to anyone else, thereby reducing cost but not being penalized.
This is why Spark was created, built on Station, with a sophisticated protocol for preventing many different ways of SPs trying to cheat the protocol. And SPs were still successfully cheating (ie: acting as if they were serving retrievals, but not), there's a lot of challenges to be solved here.
Eventually, Spark was shut down because of lack of funding. We then created FilBeam: Instead of burdening the network with huge amounts of synthetic traffic, rather measure retrievability in real traffic. This is why FilBeam has to sit between the public and the SP, in the request flow. On top of that, Filbeam is simpler / less cheatable, as it's impossible for SPs to seem to serve retrievals.
Since there is no proof of retrieval, users can falsely claim an SP is unavailable. Here the user can also be a competing SP, who wants to be the sole reward receiver for a piece CID.
It is also possible that users correctly claim an SP is unavailable, however this claim isn't verifyable, since the SP looks retrievable to the FOC team. This can be because of network segmentation, traffic patterns, and many other reasons.
Even if SPs are good willing, they can still be not retrievable, due to networking issues or misconfiguration. They should be penalized for it.
Instead of FilBeam sitting between the public and the SP, proxying every byte, a pay-per-request flow can be built. Like with x402, the requester would pay for every single byte, interacting with the SP, and the SP directly be rewarded for it. X402 isn't sufficient, as it's still easily cheated. For now, a trusted intermediary still looks to be the most realistic option.
Also look at Storacha Forge, where each individual retrieval needs to be paid for.
FOC needs to have solid retrieval incentives, if it wants to keep users during upcoming growth phases.