Review PDPOffering fields

[wjmelements]

Many of these fields in the current schema can be capability keys. Capability keys are flexible but the typing of productData (eg PDPOffering) cannot safely change after launch. We should be sure about which fields are universally mandatory and make the others capabilities.

We should also increase the capabilities limit somewhat.

[wjmelements]

Currently is this

    /// @notice PDP-specific service data
    struct PDPOffering {
        string serviceURL; // HTTP API endpoint
        uint256 minPieceSizeInBytes; // Minimum piece size accepted in bytes
        uint256 maxPieceSizeInBytes; // Maximum piece size accepted in bytes
        bool ipniPiece; // Supports IPNI piece CID indexing
        bool ipniIpfs; // Supports IPNI IPFS CID indexing
        uint256 storagePricePerTibPerMonth; // Storage price per TiB per month (in token's smallest unit)
        uint256 minProvingPeriodInEpochs; // Minimum proving period in epochs
        string location; // Geographic location of the service provider
        IERC20 paymentTokenAddress; // Token contract for payment (IERC20(address(0)) for FIL)
    }

I want to remove storagePricePerTibPerMonth and compress the bools to a flags bitmap (leaving room for 254 future flags). The other fields look fine.

[wjmelements]

Via #266, we are also considering ipni peer ID.

[jennijuju]

We discussed it from product side and prefer to keep the pricing as a mandatory field for pdp offering - if the SP doesn’t want to set it, they can pro-claim it to be 0. This gives the network more price discoverability without needing to push for standards, which may be harder for tooling adoption.

[wjmelements]

We discussed it from product side and prefer to keep the pricing as a mandatory field for pdp offering - if the SP doesn’t want to set it, they can pro-claim it to be 0. This gives the network more price discoverability without needing to push for standards, which may be harder for tooling adoption.

"PerMonth" is a pretty bad standard because months have 28-31 days.. Needs a calendar library to support it. Price per epoch, the very basis of Payments, would change month to month. Unless we want to define a month to be 1/12 of a year of course.

[jennijuju]

We discussed it from product side and prefer to keep the pricing as a mandatory field for pdp offering - if the SP doesn’t want to set it, they can pro-claim it to be 0. This gives the network more price discoverability without needing to push for standards, which may be harder for tooling adoption.

"PerMonth" is a pretty bad standard because months have 28-31 days.. Needs a calendar library to support it. Price per epoch, the very basis of Payments, would change month to month. Unless we want to define a month to be 1/12 of a year of course.

Let’s put it per epoch or per day to address your concern, which I see the point, and services/app can derive any monthly / annual price from it if needed

[rvagg]

Currently capabilities are awkward to fetch, you can get keys but have to follow up to get values. If we move more things to capabilities then I'd like nicer ways to eth_call to get everything in one go

[wjmelements]

Currently capabilities are awkward to fetch, you can get keys but have to follow up to get values. If we move more things to capabilities then I'd like nicer ways to eth_call to get everything in one go

On-chain though, it is much cheaper to fetch from a capability than the PDPOffering, because if want to read one item from the PDPOffering, you have to load the whole thing.

[wjmelements]

We discussed it from product side and prefer to keep the pricing as a mandatory field for pdp offering - if the SP doesn’t want to set it, they can pro-claim it to be 0. This gives the network more price discoverability without needing to push for standards, which may be harder for tooling adoption.

"PerMonth" is a pretty bad standard because months have 28-31 days.. Needs a calendar library to support it. Price per epoch, the very basis of Payments, would change month to month. Unless we want to define a month to be 1/12 of a year of course.

In FWSS, EPOCHS_PER_MONTH = 2880 * 30; so a month is defined as 30 days. If we are happy with that definition of month, we don't need to change this.