[x-complexity]

> Don't forget that tweets are not just tweets. In 2016 Twitter handled 3000 images per second (around 20GB per second). The number undoubtedly increased since then. There's also video.

> Good luck storing those on blockchain :D

I'll admit that a normal blockchain would be impossible to store that level of transactional data. Of course that doesn't mean that it isn't possible to store it in a decentralized manner: It does, however, require different methodologies to make it work.

Currently, the best attempt at this comes from both Filecoin & Arweave, but they're both coming at the problem at different angles [1]: Filecoin tries to solve the storage problem as a "Pay for X storage for Y time" problem, whereas Arweave is trying to solve it as a "Pay to store X storage forever" problem.

Going by Arweave's current stats [2][3], it is possible that the network could be able to handle that level of content generation with a high enough node count. In fact, a stress test of sorts is currently underway, as there's an attempt to try and store the Russia-Ukraine conflict on the network [4].

[1] https://coinmarketcap.com/alexandria/article/the-decentraliz... [2] https://viewblock.io/arweave/blocks [3] https://viewblock.io/arweave/stat/cumulativeWeaveSizeHistory [4] https://www.forbes.com/sites/stevenehrlich/2022/02/25/a-bloc...

[dmitriid]

> I'll admit that a normal blockchain would be impossible to store that level of transactional data. Of course that doesn't mean that it isn't possible to store it in a decentralized manner

Translation: blockchain a) doesn't solve this problem, and b) isn't required for this

[x-complexity]

> > I'll admit that a normal blockchain would be impossible to store that level of transactional data. Of course that doesn't mean that it isn't possible to store it in a decentralized manner

> Translation: blockchain a) doesn't solve this problem, and b) isn't required for this

Clarification: The data structure of a typical blockchain that is regularly talked about (single-chain, no shard/web) definitely cannot store that level of data. In order to reach that level of data throughput, better data structures are required to do so.

Single-chain blockchains are great in terms of determining transaction finality, but are poor in terms of data storage. This doesn't mean that research into decentralized & computationally-assured data storage techniques shouldn't be pursued.

[dmitriid]

> This doesn't mean that research into decentralized & computationally-assured data storage techniques shouldn't be pursued.

No, it doesn't, for one simple reason: blockchains is not the only such tech, and "computational assuredness" probably isn't really a requirement for this.

[x-complexity]

> > This doesn't mean that research into decentralized & computationally-assured data storage techniques shouldn't be pursued.

> No, it doesn't, for one simple reason: blockchains is not the only such tech

Again, reiteration must be applied here: The standard single-shard reference-to-previous-block data structure that is the initial blockchain structure is non-conducive towards decentralized data storage. As stated beforehand:

> > The data structure of a typical blockchain that is regularly talked about (single-chain, no shard/web) definitely cannot store that level of data. In order to reach that level of data throughput, better data structures are required to do so.

> , and "computational assuredness" probably isn't really a requirement for this.

Towards the latter half of your statement, if computational assurance is not required, then standard trust-based storage solutions can be implemented instead.

HOWEVER (and it should be stressed with extreme emphasis on the word), in that scenario, concerns about the centralized nature of such a storage solution CANNOT be launched by critics: It was their criticism of decentralized storage solutions that caused the shift towards standard trust-based storage solutions, and thus they cannot criticize the move towards the latter. Otherwise, their criticism is not out of technical concern, but out of personal opinion.

[dmitriid]

> concerns about the centralized nature of such a storage solution CANNOT be launched by critics: It was their criticism of decentralized storage solutions that caused the shift towards standard trust-based storage solutions, and thus they cannot criticize the move towards the latter. Otherwise, their criticism is not out of technical concern, but out of personal opinion.

This sounds like a rant devoid of meaning.

Yes, there are centralized solutions. Yes, there are decentralized solutions. Yes, critics have full right to criticize both, because both have their failings.

This has literally nothing to do with whatever ideological angle you're trying to force.

[x-complexity]

> > concerns about the centralized nature of such a storage solution CANNOT be launched by critics: It was their criticism of decentralized storage solutions that caused the shift towards standard trust-based storage solutions, and thus they cannot criticize the move towards the latter. Otherwise, their criticism is not out of technical concern, but out of personal opinion.

> This sounds like a rant devoid of meaning.

> Yes, there are centralized solutions. Yes, there are decentralized solutions. Yes, critics have full right to criticize both, because both have their failings.

> This has literally nothing to do with whatever ideological angle you're trying to force.

The ideological angle in this case is: "N solutions have a mixture of good & bad, but at least one of them is required for system S to function. Critics that criticize N-1 of N solutions cannot criticize the usage of the Nth solution when that is the only other solution left, after catering to their desires for (1...N-1) of N solutions to not be used."