Re resources #1
Comments
"sustainable funding" is a very perspectival wording; obviously developers of core-js had failed to convince BitShares development investors at this time to fund their work using the worker system, that's a very normal thing to happened as it is a choice; BitShares development investors are having the choice between deciding to fund any work through the worker system or through a private "one-to-one" grants and also have the full choice to stop it.
Paying developers from the "reserve pool" using the worker system is a decision of BitShares development investors; hence it might impact the value of BTS negatively in every single payment as it deducts value from BTS, so a proper return of investment planning should always take a place before funding any work from "reserve pool" to make sure an equal ROI is achieved after these payments; in your specific case I highly doubt that your proposed improvements can achieve 1% as ROI of that 17% available funding, perhaps other BitShares development investors can see something else.
Eco-system was driven intentionally to limit the growth on the expense of corruption existence within the DPOS voting mechanism which I call BitShares 5.0 Purge. As we are promoting a free market; we do not mind Binance founder to invest in BTS nor Binance users to invest in BTS; that's their choice and we will not interfere with that, BitShares 5.0 Purge was about preventing DPOS voting mechanism to vote up workers that wouldn't have ROI which we'd achieved.
Thanks for the suggestions; as we are growing and participating more into grants we are aiming to participate in more partnerships with other parties for the sake of funding the development contributions. |
The reference bitshares-ui uses core-js, and indeed the Bitshares development community failed to take action to fund his career at a time of crisis in his life, and consequently he ended up in a slave labour gulag for 10 months which degraded his health significantly. If core-js goes commercial, how do you propose to replace his work? Did anyone reach out to him to create a BTS WP? Or did we all just collectively choose to ignore his pleas for funding in our terminals when working on the UI?
To be clear, your example of allocating approx $70k (1%) could cover 1 mid level react developer at current market rates for the estimated duration of the task. The proposed reference wallet overhaul is not about introducing insignificant cosmetic changes, but rather focuses on the long term security, performance and reliability of the reference UI code of which the vast majority of Bitshares users utilise, even your own company bases its web UI on said reference code. IMO the cost to the network from inheriting vulnerabilities and incompatibilities from inaction could easily exceed your 1% estimate, further waiting until deadlines pass to tackle a multi-thousand hour task could push costs far above 1%. I'm now leaning towards the sunsetting of the reference web UI if we take no action, directing users away from the web UIs to modern secure wallet applications in order to sustain future usage without imposing unnecessary risks onto users. Potentially significantly reducing traffic to iobank ui. If the reference UI as you say is unable to sustainably grow the reference pool with collected fees, then action needs to be taken by the committee to plan how to grow collected fees when updating fee schedules.
I'm not saying Binance founders/users shouldn't be able to invest in BTS, what I'm saying is that the max supply cap set nearly a decade ago is fundamentally outwith their control since they intentionally choose to store BTS outwith the DPOS voting mechanism. I would support growing the max cap if the reserve pool was to dry up entirely & I refer to the lack of participation in DPOS at the moment because such proposals could be proposed and supported with substantially less funds than binance holds.
I fundamentally disagree, the 5.0 upgrade was about preventing entities purchasing voting weight & preventing the coercion of vote weight proxying for sharedrop purposes; there were at least 2 groups who did this, beos and cnvote, both for the creation of new cryptos at the cost of acquiring substantial control over the bitshares network at a significantly reduced cost (than purchasing the BTS themselves). See: IMO it wasn't about preventing individual WP's from wasting funds, but rather about eliminating fundamental attack vectors against governance by potentially adversarial groups, which was avoided by creating the 5.0 release. |
They cannot simply change the same exact package from open source to commercial in one day as code is already open source and many entities are using it; perhaps maintaining the code wouldn't be possible in case they'd stopped the support but we would have enough time to replace any packages or come up with solutions to dead packages.
We are not very different from other entities who are utilizing many open source packages without funding their coders; I don't mind funding for luxury in a later stage but at this stage it is very wrong imo; I am not also saying every investment in reference wallet UI codes should be stopped, what I am trying to say is simply BitShares development investors should not be funding something that has no immediate return of investment at this stage, with current roadmap we're trying to stabilize the economy of BitShares after the impact of 5.0 purge. Please join @BitSharesDev over telegram if you're interested further in discussions as we always welcome positive discussions. |
Sure, we can easily keep the current version, however this may result in long term browser incompatibilities and deny us access to new JS functionalities.
Indeed, maintaining a fork of core-js is an impossible task for us, it'd require an expert vanilla JS dev.
Packages in scope for replacement in this scenario:
Several of the above are not actively maintained, so they would need to be replaced. The current deadline we are currently operating under is 7 months, however the core-js commercialization may occur far sooner than that.
Indeed, we collectively demonstrated bystander apathy when prompted to save his life. Just because most of fortune 500 did the same doesn't mean we didn't act improperly and callously. Sure, we may only account for mere seconds of gulag time allocated to the dev if divided among all npmjs users, but that's not the point nor does it make it more palatable.
The referenced compute environment & package uplift issue is not by any means a luxury, but rather a boring maintenance task to passively improve the UI.
Again, I disagree that the referenced task has no immediate return on investment. Let's take a quick glance at Google PageSpeed Insights for wallet.bitshares.org
From the above we there are several takeaways:
By tacking the uplift task, we would aim to improve performance (closer to 100s), improve SEO (aiming to get pages actually indexed), and cut dead code from the code stack making it far easier and cheaper to maintain in the future. The above takeaways directly improve ROI. Check out this SEO blog post for more info on how poor performance degrades our bottom line. The org site is at least optimized, if you put the new bts.exchange web wallet through the same test it performs far worse:
The above stats indicate that the org web wallet is significantly more performant than the new exchange page, this will negatively reflect upon BTS despite the core being better than most cryptos out there. |
|
Further looks like multiple security vulnerabilities are being reported & no funding exists to reward their discovery: bitshares/bitshares-ui-staging#1 Securing wallets from vulnerabilities isn't a 'luxury' neither. Further backing the sunsetting of the web wallet interfaces, unless security isn't a priority for your customers? |
|
You can try to contact any BitShares committee members privately to convince them to fund your development direction; this isn't an area for development discussions. |
|
Rather than deny proper funding to witnesses and developers, support BSIP 88: https://github.com/bitshares/bsips/pull/296/files Not that you have BTS best interests at heart though, that's long been clear to everyone. |
Open source development is incredibly difficult to contribute towards without sustainable funding; a clear example of this is core-js which failed to achieve sustainable funding despite millions of daily users, leading to significant physical and psychological harm to its lead dev.
Are resources really that scarce? The reserve pool contains approx 17% of total supply, yet no worker proposal has been funded since AFAIK mid 2019 or earlier. Leaning into austerity measures during a downtrend has proven to be a fundamentally flawed neoliberal tricke-down economics measure; IMO spending your way out of a downtrend is more appropriate than to copy flawed western conservative economic policies.
Obviously I agree that some of the historically funded worker proposals may have sucked, however, I disagree that historically bad WPs should impede future development funding, especially when the focus is now on substantial required improvements to highly utilised BTS software; software which several gateways utilise as a reference. At a certain point without direct action it'll become more appropriate to instead direct users to actively maintained mobile & desktop wallets and to sunset the bitshares-ui web wallet interface.
Further, the max supply cap of 3.6B BTS is a single mandatory/hard fork away from being raised to further grow the potential reserve pool pot. The vast majority of BTS funds do not participate in the DPOS voting mechanism, so we can't assume non-voters are on-board with the economics proposed by those who left the ecosystem a long time ago.
Further, more funds on-chain going to active community members & developers strengthens decentralization against those who choose to store it all on CEX (see binance holding hundreds of millions of BTS yet providing no proof of reserves on CMC for BTS whilst being a direct competitor to BTS in both CEX and DEX terms).
Do we compete on an equal field with other foundations? We're not on the Blockchain Grants website despite having a fully functioning worker proposal funding mechanism built into the chain, nor do we compete with graphene forks on-chain funding or CEX backed competitor DEX funding.
The text was updated successfully, but these errors were encountered: