And so we destroy the simplicity of the protocol by creating a system that is far more complex and subject to more flaws, both in basic design and in operation.
No, going to fixed chunk size makes the protocol more simple and easier. The smaller the chunk the simpler for app devs to account for. Larger chunks reduce network accounting. Where’s the sweet spot for chunk size? We’ll know soon enough.
We’ll see where the devs go from here, but I still see far more problems than solutions.
Re: node joining, the sybil defense reason to make joining contingent upon the network’s need for space makes sense, but it could create some issues. Namely, it could keep the network very small until such unknown time (maybe years?) that storage on the network becomes popular. There are pros for this, but one con is that it does not allow for a huge scale (and attendant bugs) to really be investigated well ahead of such scale being needed. And that’s a serious risk.
So, in addition to the current
allow join when storage is <50% or
when member leaves, why not also allow for consistent network growth according to a steady schedule per which x randomly selected nodes are added from a large pool of waiting infants?
The sybil risk wouldn’t be any worse than allowing join only when capacity is needed, and the network can grow consistently rather than in spurts.
Yes, this and some other angles will need to be tried out in the early days.