Well why the hell are they even bothering with it then? Clueless?
(another plausible answer is that LN works perhaps only with a fully centralized coin, so perhaps that is where Blockstream has been paid $75 million by the banksters to lead us to, but I am hoping that is not the case)
(or alternatively, the banksters have paid Blockstream to clusterfuck Bitcoin, whether Blockstream realizes it or not)
Control freaks inherited from Mozilla such as the HTML5's Ian Hickson prototype now in control of Bitcoin too. I've been
butting heads with these control freaks for more than a decade.
They conflated the framing and data layer for Websockets for example even after I explained that to them.
They'd rather do it wrong than to not be the one in control of the doing.
And gmaxwell got his ass handed to him by myself in that debate on the Ogg container format for which he was the co-inventor of one of the key codecs:
Doing so would also increase the overhead for the format by 20% or so. As mentioned, accurate indexes are not small-- and many things compromise by just not providing accurate indexes; which then leaves applications linearly scanning or not permitting sample accurate seeking.
I assume the 20% estimate is only for when the optional index is present. So it is presumed someone would use an index only when that 20% was justified by their use case. Again I argue you should not remove degrees-of-freedom and hinder the optimization of use cases which you did not envision because no group or person is omniscient.
And how is not having the index any worse than not allowing an index. I fail to see the logic. Seems you are arguing that the receiving end will expect indexes and not be prepared for the case where indexes are not present. But that is a bug in the receiving end's software then. And in that case, there is no assurance that software would have done the index-less seeking more efficiently for the status quo of not allowing an index. None of this makes sense to me.
Also I don't understand how you calculate 20% increase in file size for adding an index. For example, lets take an average 180 second song consuming roughly 5MB for VBR encoding. Let's assume my users are satisfied with seeking in 1 second increments, so that means means I need at most 180 of 22-bit indices, so that is only 495 bytes which is only a 0.01% increase! On top of that I could even compress those 22-bit indices into relative offsets if I want to shrink it by roughly 75% to 0.0025%.
Note that doesn't mean these guys aren't smart and expert in some areas.
In Blockstream's case, taking into account SideChains and LN, I am thinking they follow the
Rude Goldberg principle of design. In Ian's case, I think it is "simplicity is beauty at any costs" or something like that.
Note Brendan Eich has been doing well with EMCAScript (Javascript) apparently. I've had no experience with him so it is not a blanket accusation towards Mozilla, but rather apparently some of the people who have gravitated to open source standards work apparently due to the political control.