The current Pay-as-you-go/Streams model is not giving a good user-friendly experience. Users usually want stability and predictability. Storage is a long-term service, and as a user, I would prefer paying upfront for 1 year of storage for the files I store.
With the current model, the user journey would be:
I would query the Storage Provider to tell me how much it would cost me for 1 hour, and make my own calculation on how much BNB I would have to provision to cover for 1 year.
This brings another problem in the user journey since the payment is being done in BNB in streams, it’s hard to provision for 1 year, as BNB is a volatile asset. BNB might be worth half of it’s price in 3 months, and instead of having enough BNB for 1 year as initially provisioned, I end up with 6 months - which is not a good user experience.
For the above issue, there could be two solutions:
Upfront payment for a longer period in BNB, without using streams.
Continue having stream payment, but give the option to pay in BUSD, and when the payment is made. And if BNB are required for the system to work, a smartcontract can be automatically triggered to buy BNB from the market with the deposited BUSD. In that way, you can easily integrate Credit Card payment on top of it, as you only need an on-ramp solution to send BUSD to a particular address.
If BUSD is a viable solution, let’s assume I’ve made a payment for 6 months, in case of bad SP performance, the mechanism of moving to another SP should happen automatically. From a user perspective, you don’t want him to handle the hurdles of doing technical things such as moving his files from one SP to another. He only wants the service to work, which should be solved at the protocol level.
I understand your concerns regarding the current Pay-as-you-go/Streams model in the Greenfield storage network. It is true that users typically prefer a more stable and predictable experience, especially when dealing with long-term storage services. I appreciate the suggestions you’ve provided for improving the user experience.
For the payment stream, a user could take advantage of the programmability offered by Greenfield via BNB Smart Chain; smart contracts could be employed to convert BUSD to BNB, as required by the system, ensuring seamless operations and providing a more stable and predictable payment method for users. This option could provide users with the stability and predictability they seek, while leveraging the programmability of Greenfield via BNB Smart Chain
Regarding the automatic migration to another storage provider (SP) in case of poor performance, I think you are right; handling this feature at the protocol level would be ideal. End-Users should not have to deal with technical aspects like transferring files between SPs. Incorporating this functionality into the Greenfield protocol could significantly improve the overall user experience and increase the platform’s reliability.
In case an SP is put in Jail, I believe the system should automatically migrate to elect a new primary SP.
Automatic conversion through BSC is a very interesting idea. I don’t think SP can be put in jail and in case of poor performance is just slashed. I don’t think this can be done automatically as each SP will have its own T&C, and before migrating, users will have to accept and agree to the T&C of the new SP. So it’s up to users to migrate the content, but can definitely be done through some scripting/dApp.