FIP-17: Extending Storage Expiry

[varunsrin]

Title: Extending Storage Expiry
Type: Implementation FIP
Authors: @danromero , @horsefacts, @sanjayprabhu, @varunsrin

Abstract

Make it easier for existing users to stay on Farcaster by extending storage units for another year. Reduce the size of new storage units to offset some of the load on hubs.

Problem

Storage units expire exactly a year after they are rented. A user who doesn’t pay rent for a second year will see their casts, reactions and links removed from the hubs. This creates two problems:

1. Users are more likely churn due to the additional fee and transaction.
2. Clients must do additional work to handle accounts with expired storage.

The first storage units will begin to expire on Aug 28, 2024. Expiring storage was proposed to keep state growth in check because we weren't sure how hubs would scale. Since storage isn't a major short term issue on hubs, we shouldn't enforce this expiration and hurt the user experience.

Specification

We propose giving existing users an additional year of free storage to avoid any impact to the growth of Farcaster. We also propose resizing storage units issued in the future to counter balance this change and keep state growth in check.

Storage units that are already rented will be valid for two years total. All units rented before Aug 28, 2024 0:00:00 UTC will:

1. Be valid for two years (63072000 seconds) after registration.
2. Have no change to message limits

Type	Limit
Casts	5000
Reactions	2500
Links	2500
UserData	50
Verification	25
Username Proof	5

Storage units rented after this FIP will be valid for one year total. The units are also 40% smaller to help keep state growth under control. This was previously discussed in FIP: Reduce Storage Limits which is being rolled into this FIP. Storage units rented on or after Aug 28, 2024 0:00:00 UTC will:

1. Be valid for one year (31536000 seconds).
2. Have message limits that are 60% lower.
3. Have the cost reduced from $3 to $2

Type	Proposed Limit
Casts	2000
Reactions	1000
Links	1000
UserData	50
Verification	25
Username Proof	5

Impact to users

Impact is positive for existing users who get an additional year of free storage. The impact may be slightly negative for a small percentage of new users since the storage limits are smaller. We don't think this will have a significant effect on the users signing up - most people don't exceed their limits, many of those that do are fine with older data expiring and the small minority that wants to preserve older data can purchase more units.

Impact to developers

Impact is positive for all client developers since they do not need to handle the case where a user returns with no storage. Other developers should see little to no impact.

Impact to hub runners

Hub runners should not see a big difference in storage over the long term. Some storage will be freed up immediately due to unit resizing, but storage reclaimed from churned accounts will be delayed for another year.

Rationale

1. Why not consider <technical_solution_x> instead which is better?
We’re prioritizing the simplest possible solution here since it lets us focus shift focus back to the two main problems for Farcaster — hub sync stability and user growth.

2. Why not make all storage units in the future valid for two years?
We want to retain flexibility to price storage yearly — it’s not clear what the right long term solution is and we don’t want to commit to something that will ossify the system.

3. What happened to FIP: Reduce Storage Limits?
That’s effectively combined with this one now, with some changes.

4. What happened to FIP: Residual Storage?
The FIP was approved but not yet implemented — with the delay in expiry it only needs o be implemented before Aug 29, 2025.

Release

1. A minor release 1.XX will be cut with these changes on Aug 15th or Aug 16th.
2. The release will be min versioned on Aug 26, 2024 PT, during working hours.
3. The new limits will take effect on Aug 28, 2024 at 0:00:00 UTC.

[cboscolo]

How should apps treat User Data, Verification and Username Proof data for users that don't pay to extend their storage?

For example, FID-XXX doesn't pay to extend storage. Then a couple months after storage expired decide they want to cast some more, do they need to resend all of their User Data, Verification and Username Proof?

[varunsrin]

FIP-14 has a proposal to avoid having users rebroadcast all this data: #139

[Pfed-prog]

A potential feature to export data, for example, to ipfs?

[varunsrin]

You can write a script to automate that if you want, no protocol change needed

[manan19]

In support of this, given all the tradeoffs.

It would've been nice to prune the data from inactive users, but I understand it's difficult to agree on inactivity at the protocol level.