Support seamless switching between FilCDN addon and basic tier without data/proofset re-upload/restore

[jennijuju]

Problem statement

A uscase was raised: If a client starts with FilCDN and later wants to downgrade to the basic tier (direct SP retrieval, no CDN), how can this transition happen seamlessly, ensuring continued data accessibility and correct billing, without requiring new data uploads or restores?
Similarly, what’s the flow if a user starts on the basic tier but later wants to add FilCDN for their existing data?

So the use stories are:

• As a client, I want to be able to upgrade or downgrade between FilCDN and the basic tier for my data (i.e., opt in or out of CDN acceleration) without having to restore or re-upload my data.
• As the service/protocol, I need to properly update and track payment rail(s) and charge the correct rates based on the user’s selected tier.
• As a SP, I want to be automatically and accurately informed when a client changes their service tier (e.g., opts in or out of FilCDN), so I can update my service commitments, adjust retrieval behavior and payment expectations, and ensure that I’m only proving and serving data for which I’m being compensated.

Proposed solution

Id propose propose enabling in-place updates to proofset metadata to reflect tier changes (e.g., adding or removing FilCDN), and adjusting the associated payment rails accordingly.

• The client initiates a request to change the service tier (upgrade or downgrade).
  As this affects the SLA, the client must explicitly sign an authorization message for the metadata update, ensuring non-repudiation and auditability.
• On receiving the signed request, the service updates the proofset metadata in place, ktoggling the FilCDN flag on or off and recording the change in state
• The payment rail configuration is updated in sync (e.g., switching billing rate, terminating or starting FilCDN-related payments as appropriate).
• The system emits a relevant contract event that informs FilCDN, Curio, and any indexers of the tier change.

By doing so:

• Roots/data remain in place; there is no need for the client to re-upload or for the SP to duplicate data.
  If storage service continues under a different tier, only the metadata and payment context change.:
• Less friction for clients and SPs, tier switching is fast, efficient, and minimizes risk of data unavailability.
• Keeps protocol and service states synchronized and auditable.
• Reduces the need to recreate proofsets or handle bulk root migrations, improving UX and operational simplicity.

[Chaitu-Tatipamula]

i would like to take this up, can you assign it to me?

[rjan90]

Hey @Chaitu-Tatipamula! Thanks for your interest in picking this up! Just a heads up, @Hany-Almnaem also expressed interest in picking this up earlier today in Slack.

I mentioned to him that we’ll align on the approach during tomorrow’s engineering sync and address any open questions then. Since he reached out first, I’ll plan to assign it to him if he’s still interested after our discussion, I hope that’s okay with you.

In the meantime, we’ll also review other items on the project board and see if there’s something else that might be a good fit for you. I’ll circle back with suggestions tomorrow.

[juliangruber]

As a SP, I want to be automatically and accurately informed when a client changes their service tier (e.g., opts in or out of FilCDN), so I can update my service commitments, adjust retrieval behavior and payment expectations, and ensure that I’m only proving and serving data for which I’m being compensated.

For the SP, the noticable change would be that on upgrade, a new payment rail between client<>SP is created, for incentivizing retrieval service from SP->FilCDN. On downgrade, this payment rail will be deleted, or not paid into any more.

[juliangruber]

I worry about the complexity of not only implementing buying a plan (when you create a proof set) but also implementing migrating between plans, and the state change complexity involved. For every plan that exists, there needs to be an implementation for a migration to any other plan. Right now we just have two plans, but add withIPNI to the mix, and it gets more complex.

What about instead you always fully delete the existing subscription, and create a new one, but somehow get the same ids/references as before? Would that make state management more risk free?