Agree with that.
if the decision is not to sponsor the account storage fees anymore, who then needs to pay/deposit for it ? users, dApps ?`
I agree with @bluesign that the various types of fees are confusing to most people, and that combining them into a single transaction fee would be preferable.
The transaction fee could be calculated based on the number of bytes written and the total number of bytes locked by an account.
@luca’s proposal to burn the tokens instead of recovering them when space is freed makes sense too.
The FLOW token price would more accurately reflect chain usage.
If we move forward with a single unified fee, per transaction, would that fee be burned?
Disclaimer: I’m on the Flow team, but I wasn’t involved in creating this proposal and I am just sharing my personal opinions. These are also just my intuitions, so I may be completely wrong. 
Remember that this is still just a proposal, so nothing is set in stone! Everything is still up for discussion, so don’t think that the Flow team has already made this decision. We make decisions like this as a community. 
I agree that storage fees are not the best UX in the world, but the proposal to just add storage fee costs to transaction fees to pay when a resource is created for the first time is basically already how Ethereum does things, and that has clearly not stopped people from creating insane amounts of data. That is probably an argument for increasing the creation fees for resources, but I don’t think it is an argument for getting rid of storage fees. I believe Ethereum suffers from state bloat partly because there is no incentive to free up storage. If users can get FLOW back by freeing up storage in their account, then that encourages them to get rid of any useless data that they might be storing, which helps prevent state bloat.
Another comment in regards to the complaint about forcing the owner to pay for storage instead of the creator. In Flow, an account isn’t able to store an object unless it either explicitly stores it itself or has indicated that it is willing to store it by creating a public capability to deposit a specific type of object in their account. This is already different from every other ledger-based blockchain where all data related to a contracts are stored in the contract’s account, so it is hard to compare it to other chains anyway. I think having the storage deposit opens up more possibilities for wallet pricing and account management. Think of it kind of like using gmail or another hosted email service. When you sign up, you pay up front for a specific storage limit or you don’t and get the free limit, and you can’t go over that limit unless you either free up space on your phone or pay more for a higher limit. There are a bunch of really useful tools to help users free up space in their emails without thinking much about it. Presumably, there could be something like that for Flow accounts in the future that wallets can integrate. Users seem to be fine with this model for a lot of web2 services because they’re easy to use. I don’t see why we can’t have something similar for web3.
We would just need to get wallets, especially Dapper Wallet, to only pay for the account minimum balance for their users and make any further increases a paid option, but that’ll be difficult, but still possible! 
Please be nice when telling me that everything I just said is wrong.
Hi @all, can we meet at one of the following times for a further discussion on this? I can share the invite once we agree on a time. Thanks
the problem is “state bloat” is “never” caused by active user. @kshitij.chaudhary shared storage sizes above, almost 90% of total storage is used by either empty/puppet/non-active accounts. Those users will never ‘pay’ for upgrade you mentioned, and they will never empty those accounts ( as they cannot get the minimum storage fee back ). But we are now suggesting to punish active users.
Thanks @flowjosh for the great reply and for pointing out the Ethereum example when applying the creation fees for resources.
While thinking more about it, what if the creation fee wouldn’t be burned, but instead would be put somewhere in a special general vault?
Then if people will decide to free up some of their space by burning some old NFT, they would automatically receive the amount paid for the creation back to their wallet.
In this way, it could almost incentivize people or small projects to be “garbage collector” that would perhaps turn some profit out of it, while benefiting the whole blockchain with their service.
Moreover, it could be treated as a net zero-sum (amount paid for creation = amount paid back on destroy), but it could also keep a certain amount and burn it forever, as a general fee for using the network.
I think from a user point of view is fundamental to know that if he has 1.2FLOW in his wallet, he can spend 1.2FLOW on anything he wants. Having this uncertainty on how much extra will someone have to pay to use the things he buys will lead to terrible user experiences and to lots of confusion (1.2 FLOW + 0.1 FLOW for storage = 1.3 FLOW => TX failed).
It would make much more sense to still apply the concept of “staking” the FLOW for storage (instead of burning it), but I would just associate and tie it to the actual resource that generates that storage, and not the wallet that holds it.
Anyway, just throwing ideas around and I am happy that the discussion is bringing a lot of interesting point of views to the table.
Unfortunately I won’t be able on Wednesday, but in case it will be done on Tuesday I will be happy to join! @kshitij.chaudhary
In the preceding scenario:
The transaction fee could be calculated based on the number of bytes written and the total number of bytes locked by an account.
A user will be penalised for bloating the chain.
The more data he stores, the higher the cost of his future transactions.
Because the FLOW token is decoupled from the storage cost, it can still be burned per @Luca 's suggestion.
Another method for removing unused data is to assign a TTL (time to live) to data stored.
When minted, tokens would have a predetermined TTL.
The initial fee for the TTL could be included in the transaction that creates the token.
Users would need to send periodic touch (as in unix touch) transactions to keep (some of) their data alive.
Hi team, here are the meeting details. Hope to see you all there!
Community Discussion - FLIP 66 Storage Fees
Wednesday, February 15 · 12:00 – 12:45pm (ET) // 9:00 – 9.45am (PST)
Google Meet joining info
Video call link: https://meet.google.com/qtf-mkfp-oay
Or dial: (US) +1 484-746-4248 PIN: 479 482 861#
More phone numbers: https://tel.meet/qtf-mkfp-oay?pin=9213308814584
Hey, yes. The time shown is in ET. Updated the post to reflect both time zones. Thanks and see you!
@kshitij.chaudhary Can you post a recap from the meeting on wednesday? I wasn’t able to attend because I was giving a presentation for the hackathon
Hi everyone. Here’s a brief summary of yesterday’s community discussion.
@kshitij.chaudhary all great points but I think currently we dont suffer any attack, and we have long road to have this attacks causing any threat to system.
Maybe let’s not rush things, we wait for you to finish all economics model, including tx fee increase, storage fees final proposal, inflation percentage, flow token price prediction etc.
Maybe you give us a estimated time to model this economical system, we wait and evaluate as a whole?
Because I believe without having a bird eye view of a complicated economical system, we will not be able to see effects of the parts. I think there is a saying about blindfolded people describing elephant, I feel our situation is a bit like this.
There are a lot of topics waiting almost a year, like inflation rate, staking rewards adjustment etc. Rushing stuff doesn’t benefit anyone here. Storage fees comparing to inflation rate and tx fees very minor.
Btw I personally feel like you do what you decide, but you keep other stuff open for discussion always, but it never discussed.
we were supposed to discuss inflation rate at august 2022 , after flip on july 2022 decided to keep it at same percentage. But that conversation died out.
Tx fees after variable transaction fees are introduced would be discussed to increased and modeled, but it died out
That’s a good point, and actually, this is something we touched on a bit during our discussion on Wednesday, but no further action has been decided.
It would be great to have a broader view of the FLIPs related to protocol economics to understand the overall impact on the Flow ecosystem participants (wallets, dApps, users, …) before taking any final decision.
the discussion stopped here?
Hi everyone, based on the feedback received and discussions over the last few weeks, the FLIP has been updated (same link) to recommend a 100x increase in storage fee instead of a 1000x increase. We plan to take this proposal to voting, but meanwhile, look forward to your thoughts and continued engagement.
Very interesting discussion.
When will this be put to vote?
When will the txn fee discussion be brought up?
Hey, is there an update you can share?
It was very promising to finally see some quality engagement from Flow with its community, would be great to keep the momentum going!
Hi everyone, brief update - we’ll soon be publishing the next FLIP (revisiting transaction fees) so folks could review, discuss and vote on the two FLIPs together. Thanks for your patience, and look forward to your continued participation