EOSIO Telegram gov channel summary 1/2 July 2018 - EOS Amsterdam Telegram

Daniel_EOSIOAmsDaniel_EOSIOAms Posts: 8 Brand New

1/2 July 2018

A referendum for choosing which Constitution will be ratified, might be coming soon. Doc_Worm said a couple of BP’s have been working on this as a combined effort.
Steve Floyd from EOS Tribe gives some details at 11:00 in this video; a worker proposal system, referendum system and voting system in one platform:

Tank Commander Swift RTFM! has mentioned yesterday that we need a gov system, whose backbone is entirely economically incentivized. According to his opinion the current system relies too much on assumptions about what is ‘good’ and ‘wrong’. Those assumptions are far too Western. The East seems to prefer organized voting with game theory. Perhaps there should be a Western chain and an Eastern chain. User Martin replied by saying the best definition of a decentralized system is whether the network can be forked. No matter who takes over the chain, another will pop up because it’s open source. Perhaps there will be dApps that are able to migrate to migrate to other chains easily, which will help decentralize the base layer and make the set of BP’s and gov model compete with less friction.

Leon Krings questioned what kind of ricardian contracts (which include human legal language) are to be found on the base level. The BPs could be the ones with enough background knowledge to inform the users, but they are probably afraid to do so because of B1s decision to vote for BPs that openly support the new Constitution.

There is a notion in the proposal for a new constitution by user Emma, which states that a member may only publish information to the Blockchain that is within their rights to publish. User Samupaha posted that this is something that can’t be controlled by code, because it would need human judgement to know whether an account has the right to publish certain information or not. Therefore this is subjective information.

Jetse Sprey replied that Ricardian contracts that can fully be executed by code must be standardized matter such as simple end user licences or exchange of money. Anything more complicated is hard if not impossible to code in such a manner that there is no room for interpretation. There will be gray areas, for human interactions are often too subtle to capture in simple yes or no’s. BP’s position can be limited in this. In the dApp layer where the grey stuff is, it seems to be advisable to have some sort of mandatory arbitration to keep the ecosystem healthy. DApp devs should be shielded, otherwise they’ll end up in unpleasant situations in every jurisdiction on the planet. Both parties should have a say in the choice for arbitration. If one party want arbitration, the other party certainly doesn’t, that’s the dilemma. One has to agree to this in the constitution for this to work, at least some sort of document to use EOS.

HeadiEddie mentioned that if dApps were working properly, there would be no need for bonds. If the bonds are removed, the customer risk increases. Fixes are socialized by requiring BP’s to fix the bug, which simply isn’t their responsibility or capability. BP’s would then become the liable party for the code that was ‘fixed’. Sprey replied that bonds are inconvenient. They make sure the winning party gets paid, but economically they’re bad. Everyone has to hold back some money to make sure they’re able to put up a bond if someone sues you. That’s a lot of money that doesn’t go into dApps or community work.

Sign In or Register to comment.