App-paid storage

[vrypan]

Title: App-paid storage
Type: Implementation FIP
Author: @deodad, @varunsrin, @sds, @vrypan
Status: Idea

Abstract

This FIP describes a mechanism that will allow applications to pay for their user’s storage.

This is a raw idea, originally discussed here: https://warpcast.com/v/0xde06c50b. It is mostly put here as a placeholder, and may require significant changes before it can be considered as a candidate for implementation.

Problem

The current cost per storage unit model is one-size-fits-all, but doesn’t actually fit all use cases. Most notably, the fixed cost per user makes it hard to explore models like free trials.

Also, it does not align with the 1/10/100 model (post/reply/read) often found in social networks which indicates most users consume very little storage -yet, in Farcaster they have to pay for it.

Specification

Every delta submitted to the network has a user fid, u_fid and is signed by an app (app key, aka signer) with a_fid.

1. Applications pay per byte submitted. This means that an application can buy for example 100MB, and will consume it based on the bytes required by each message it submits (signs) to the network. There is no expiration.
2. Users can also buy storage. User storage is charged in bytes and expires after one year.
3. Hubs accept new messages only if a_fid has free storage allowance.
4. Deltas can be preserved for longer than a year (covered by app storage) if u_fid has enough free storage.

Implications

Applications can buy storage in bulk to allow their users to use the network. Apps are free to implement their own business model, and offer free trials, freemium, pay per use, pay per month or any other payment model they like, as long as they pay for the storage their users consume.

On the other hand, users that want to preserve their activity for longer than one year, they are free to buy additional storage. Applications can also buy additional storage on behalf of their users (this is already possible).

Storage costs can be more granular and be charged per byte (or maybe MB):

• Apps are capable of navigating the complexity of cost/byte, much like every web app does: They buy storage in advance, and add new storage as needed.
• Users who want to preserve their archive, can be presented with the exact cost for their usage, because it happens retroactively: Your current archive uses 10MB, and the cost to preserve is for one more year is X, my current archive is 123MB and the cost is 12.3X.

Limitations

Due to its dependency on time, this model is easier to implement if we have global ordering. But it could be implemented before global ordering, if we are comfortable with some assumptions (for example, trusting the timestamp in deltas).

Additional thoughts

This model could also be aligned with the design of Snapchain v2 that includes a “a public snapshot service”. This service can be expanded and work as an archival service, and get paid by user fees, while app fees can go to validators.