Varun Srinivasan pfp
Varun Srinivasan
@v
An interesting Farcaster idea: what if apps paid for storage, not users? - Apps buy a chunk of bytes. - Free to allocate to casts, reactions, follows in any way. - Free to assign to users in any way (fixed rate, free) - Lower cost by avoiding "unused storage" h/t to @vrypan.eth @deodad and @sds
24 replies
50 recasts
139 reactions
vrypan |--o--| pfp
vrypan |--o--|
@vrypan.eth
Let's have a placeholder for this: https://github.com/farcasterxyz/protocol/discussions/200
1 reply
0 recast
0 reaction
vrypan |--o--| pfp
vrypan |--o--|
@vrypan.eth
In this proposal, apps can not free space. They have to buy more, because it is used "on submission", and comes with one year retention for every delta submitted. Users can buy additional space to preserve their archives after one year.
1 reply
0 recast
0 reaction
Varun Srinivasan pfp
Varun Srinivasan
@v
we should try to preserve the model where apps can free space.
1 reply
0 recast
0 reaction
vrypan |--o--| pfp
vrypan |--o--|
@vrypan.eth
why?
1 reply
0 recast
0 reaction
Varun Srinivasan pfp
Varun Srinivasan
@v
1. there are many cases where you want to delete older data (e.g. this user is spammy, i no longer want to pay for them) 2. apps should be able to reclaim space when this happens and reuse it elsewhere
1 reply
0 recast
0 reaction
vrypan |--o--| pfp
vrypan |--o--|
@vrypan.eth
For spammy users, apps can cut them off, and they can't post any more data. They can also throttle users. Deleting user data just because is not a good idea imho. And also, if you allow apps to delete and reuse, you are exposed to... spammy apps. Finally, in a globally ordered env, it's much harder to actually reclaim this space. There will be nodes keeping the blocks, even if their content has been deleted.
2 replies
0 recast
0 reaction
Varun Srinivasan pfp
Varun Srinivasan
@v
1. Disagree. Should be able to delete, not hearing a good argument for why this is a bad idea. 2. If you want to penalize spammy apps by raising the cost, just increase the cost of writing data by making storage more expensive or tighten up rate limits. 3. Not true. We can prune most blocks, see the snapchain doc.
1 reply
0 recast
0 reaction
vrypan |--o--| pfp
vrypan |--o--|
@vrypan.eth
My app, for legitimate reasons, submits 10k likes per day, then the next day deletes them all, and starts over again. Is this not taxing the network much more than an app that just submitted 10k likes in 2 months? In my pov, an app has to pay for network usage (storage, sync overhead, everything), and this is what my proposal describes. Re snaps, I did not realize that we will only keep the latest snap.
1 reply
0 recast
0 reaction
Varun Srinivasan pfp
Varun Srinivasan
@v
You can make the same argument for why users should not have reclaimable storage. But they do today, and this issue isn't that problematic.
1 reply
0 recast
0 reaction
vrypan |--o--| pfp
vrypan |--o--|
@vrypan.eth
The current cost structure makes users who don't use the network so much pay for the ones that do. It worked for the early adopters, who use the network a lot, but it's problematic when onboarding content consumers (the 100x). But yes, you can make this argument where we are now. But if we're planning for 100x these minor problems will become 100x more important. I think that something along the lines of what I'm proposing is better because it aligns usage costs with network costs: Apps pay for submitting data (which includes storage, sync, compute) and users pay for preserving data (which is mostly storage). The same proposal could work if we allowed apps to free space, but it creates a mental model for app devs that a way to optimize their costs is to throw away user data. I'd rather they are forced to optimize in advance. For example, throttle and monitor, instead of delete.
0 reply
0 recast
0 reaction