I will point out again that there is no material difference between Ethereum limited to running on tens of publicly identified machines and the NNS with only node providers given voting rights. Or between Ethereum as is and an alternate reality IC consisting of a single subnet replicated across thousands of anonymous nodes. I.e. the difference does not lie in the protocol.
I very well understand the goal of The IC to serve things the other blockchains canât.
The problem is tokenised open Web 3.0 dApps - the things Dominic keeps shouting from the rooftops The IC was specifically built for - arenât viable on a protocol with active governance of a ledger by humans. This is especially the case for governance by financial interests. States will absolutely not allow this.
So if weâre in a situation where the IC canât work without governance yet also canât work with governance then I ask the question do we have a viable project here? How is it going to work?
1 Like
Yeah if this content was a payment to a terrorist org Iâm pretty sure theyâd give a much bigger damn about it than copyright infringment.
Like if DeFi and Web 3.0 were possible on human governed ledgers itâd exist on AWS. Thereâd be no need for all the computational overhead, cryptography and economic incentives.
Right. Because everyone would rather hand over control to one CEO rather than a large group of people, or in your worst case, a group of competing nation states.
The CEO is answerable to shareholders. Thereâs literally no difference. This is especially the case when governance load would require delegation or devolution.
The point is moot anyway. Everyone wonât be allowed to hand over control to a group of people. Governments are well aware of the history of finance and wonât sit back and stay out of an impending disaster zone just because people quote new jargon at them to tell them âthis time is differentâ.
Yet there is nothing to stop him/her from making unilateral decisions. Just because there could be repercussions does not negate the fact that control lies with one individual.
1 Like
I will say again that I am very much convinced by the argument that any amount of moderation is an open invitation for censorship. And (maybe, although this is a bit of a stretch for me) that in an ideal world there would be no way to moderate content on the IC.
Iâm just not convinced by taking those argument to the extreme, via claims that other networks can avoid moderation just fine, so (skipping a bunch of steps) the IC must also do it. Now.
On the one hand, as @rossberg has pointed out, there are significant differences between transport protocols and physical networks, with associated states. On the other hand, there is functionality that still needs to be implemented before we can meaningfully talk about taking any stance other than following the law to the letter. And on the other other hand (or third, if youâre keeping count) I am personally still not convinced (although I would be happy to be proven wrong) that a network with the stated goals of the IC (performance and efficiency) can ever practically take a stance as radical as you are arguing for (because of the structure of the network required to make it fast and efficient).
So you have convinced me inasmuch as I honestly believe we should aim to get closer and closer to a state where the NNS doesnât need to intervene in any way in content moderation. Or change the state of the network. But partly because of where we stand now and partly because the IC is an incredibly complex beast as compared to literally anything else out there, I donât see how a hands-off approach could possibly work at all. If, as @LightningLad91 above pointed out, something goes south (and there are many ways in which it can and does right now) there is a big need for something like the NNS.
Looking at it from a different perspective, no one is going to take seriously a platform with continuous hour and day-long outages due to the fact that node operators USB drives in hand need to be involved in addressing each and every one of them. (Nor do I, as Iâve already said, see this to be materially different or in any way better than doing the same via the NNS.)
5 Likes
Yes my point is the difference is the governance structures and the incentives they create.
As others have highlighted there are several dimensions to this issue.
While a quick and pragmatic canister removal proposal would function as a short term solution this will have long term effects on the way courts handle node operators and perceive the IC as a whole.
Unfortunately legislators are for the most part responsive and wait for an issue to arise as we saw with the Old & Uber judgments. Let us not make the same mistake, this conversation is long overdue. Otherwise we give room to lots of speculation on the direction democracy and regulation will take within the IC.
In a sense it boils down to âwho gets toâ and âhowâ do we define the regulatory framework.
Echoing others, Node providers should benefit from the utmost legal protection. Prevention of their access to info of the cannisters they are hosting would aid in this, but Iâm uncertain of the degree to which this can be done with 100% accuracy. Government should never be able to force the hand of a node provider or weâre back to square one.
Similarly our governance system should function as a sieve where greater actions and decisions are only required if the previous protections failed to apply. Before strictly defining what cannot be, we should take the time to suggest what content is encouraged.
A barebones version could look like this:
-
Creation of any canister requires acknowledgement from the controller that âThe intent of this canister is to serve as a useful tool or service which will benefit the greater community in at least one of many ways. I.e a)Social interaction b) entertainment c) building and creativity d) problem solving
-
Canister controller is notified directly and given healthy timeframe to delete / remove contents related to claim
-
A random sample of the community (with voter reputation not token amount!) is invited to serve as a âjuryâ where the claim made is compared to the canister in question. Strong majority could execute a canister removal motion.
-
Canister controllers are given the opportunity to appeal the jury decision but must demonstrate substantial staking power to do so. As this greater appeal will take more time and attention from the community, those involved should be rewarded. An independent liquidity pool or the appellant will be the source of funds depending on the outcome. (Losing a case is always expensive there is currently no way around it)
The SNS may very much play a role further down the line before the ârandom sampleâ is called into question. Ultimately no matter the framework there will be quirks but it is crucial we lay the grounds now before we are blindsided by the next regulation/moderation case.
1 Like
2/3 should do the job. I think this would be a good step.
1 Like
When it comes to discussion of changing the definition of Simple Majority and Absolute Majority for certain types of governance proposals, I think it is necessary to clarify if we are talking about majority of votes cast or majority of total voting power. Simple Majority is defined in terms of votes cast, but Absolute Majority is defined in terms of total voting power.
It is already exceedingly difficult to achieve Absolute Majority unless DF and ICA vote and they have recently proposed a motion (NNS Proposal ID 34485 (internetcomputer.org)) to remove their default followee status for governance proposal. That proposal passed yesterday (Dec 15, 2021). Hence, it should soon be a very high bar to pass a governance proposal by Absolute Majority.
DF and ICA are free to abstain from governance votes and they will likely do that on many proposals that they believe is a conflict of interest or inappropriate for them to vote. If you look at the voting records for the last month or more, they have routinely abstained from voting on governance proposals. Any vote that is not cast is effectively a vote to Reject based on the definition of Absolute Majority. Hence, the votes to Adopt already have a higher bar than the votes to Reject simply due to the definition of Absolute Majority and the fact that everyone will not vote, even on really important proposals.
Looking at the voting history, the proposals that received the highest total votes that were not decided by liquid democracy (in other words, DF and ICA did not vote) were the people party proposal and the cannister safe upgrade proposal with 47.5M and 47.9M votes, respectively. These have been the most popular votes so far and this only amounts to 15% of total voting power that cast their votes. Hence, it is already exceedingly difficult to pass a governance proposal by Absolute Majority.
I personally do not see a need to change the definition of Adopt or Reject at all on any type of proposal. I like the fact that Simple Majority has a 3% minimum threshold of total voting power that must be met and there is a wait for quiet mechanism. I think this is sufficient to decide any proposal. To me the bigger question is whether or not certain types of proposals should be voted at all such as cannister removal. Iâm still on the fence about it.
Anyway, I think it is important to clearly define what is meant when talking about changing voting definitions. It is unlikely that 100% of total voting power will vote on governance proposals in the future, so that might require recalibration of our thought process.
2 Likes
Excellent point about simple majority vs absolute majority. I was thinking the potential new thresholds would be with regards to simple majority.
2 Likes
The more costly it is to remove content the least effective it is.
The least costly it is to remove content the most centralized it is.
4 Likes
You keep insisting on comparing the IC with glorified file sharing schemes. They are not at all similar. Even if you use pretty pictures to make your point.
Yes, the IC can store and serve static content. But it also does A LOT more. And node operators donât have any choice regarding what runs on their nodes. Nor can that content be arbitrarily moved around as is the case with file sharing (i.e. you canât remove a canister from one node on a subnet and have it run on the others).
Also, as a node provider with servers running in a third partyâs data center, you really-really donât have the ânode keeps forwarding infringing contentâ option. There is no legal pursuit, your servers just get unplugged. Very anticlimactic.
To simplify your colorful chart a bit, this is how it works with IC nodes:
Someone uploads infringing content
|
+ <------------------------------------+
v |
Node gets legal notice |
| |
v |
Node cannot take down infringing content |
| |
v |
Node cannot keep hosting infringing content |
| |
v |
Node operator submits NNS proposal |
| |
+-------------------+ |
v v |
Canister removed Canister not removed |
| |
v |
Node is unplugged by DC |
| |
v |
Copyright owner identifies other subnet node |
| |
+----------------------------+
I hope thatâs clear enough even if itâs not (in either sense) a pretty picture.
2 Likes
I didnât think my chart was that pretty but thanks.
Elaborate, what else does the IC does that is legally relevant?
In the case of the IC ânodeâ would be âboundary node,â their decentralization would render em legally autonomous. Added to that, some technical solution to make storage node operators unliable would be implemented, which would be what concerns your comment.
This is being discussed here so please come over and ask about any real issues you may find with that solution, Harrison and Jordan are way smarter than me and Iâm sure will be able to respond far better than I can.
As a side note, consider approaching ideas with a bit more charitability, if you want to keep engaging with me at least. Instead of saying âthis canât be done, youâre stupid and the IC is too complex for your solutions,â ask yourself how a solution could be implemented, what the relevant abstractions in the idea are, etc. And we may both benefit from it.
2 Likes
I have to strongly disagree here with you. 3% is way too little for any decision with far reaching consequences like removing/blacklisting a canister or changing who controls a neuron (ongoing proposal).
On the contrary, I believe at this stage Dfinintys hand should be forced on decisions like this. They might choose to wait for quiet, and follow a clear decision from the wider community (if any). But it will take a few years before the NNS, and IC for that matter, is decentralized enough to take Dfinity out of their responsibility to think long and hard about matters like these, and actually voice their opinion. If they canât come up with a clear opinion, maybe itâs time to eat your own meds and let everyone vote internally if a highly controversial issue arises? After all, I still trust Dfinity to have the deepest knowledge of what has to be done in the interest of the whole network, thatâs why I choose to follow their neuron in the first place.
Thatâs why I believe there has to be 50% of eligible votes cast, and a 2/3 majority for anything that has to do with neuron or canister ownership/control.
For everything else status quo could be fine, I guess.
2 Likes
I think quorum should even be much higher than 50% with some sort of algorithmic adjustment downwards over many days if no proposal passes, then adjusted to that % but always floating back up unless a motion passes to adjust lower.
For example in the case of a global war where 80% of neurons/icp holders die and keys are lost. It would adjust downward over some days or weeks and allow the survivors to change quorum rules and redistribute new keys to heirs etc
My sincere apologies. Got a bit carried away.
It was not obvious that you were talking about boundary nodes. Technically speaking this could be done for boundary nodes without problems (or rather with few problems, II principals depend on the actual URL of the app, so if you access the same app via different boundary nodes youâd end up with different principals).
But itâs quite possible that a determined copyright holder, who doesnât want to play whack-a-mole with what are basically proxies to content hosted on the IC, may end up going to the source of the problem and request that a specific IC node be taken down. Then the next, and the next. And I will point out that (a) which nodes host a given canister is public information; and (b) there is no way to hide that (if a boundary node can locate a canister, so can anyone else).
Meaning that this may be an interesting short-term solution, but unfortunately not a lot more than that.
As for node operators removing canisters from their nodes, thatâs not directly possible: a node is part of a subnet and all nodes on the subnet must execute the exact same messages on the exact same canisters. This is very different from a platform that stores static content: you can simply shard the content over a huge number of anonymous nodes, with none of them storing even a piece of the original content and require many of them to contribute in order to rebuild the original content. That way the content isnât located anywhere in particular (unless you consider 100 anonymous nodes that can be replaced at a momentâs notice to be a location). You cannot do something like that with an application (which is what a canister is): you canât arbitrarily break it into tiny pieces spread across 100 nodes and still expect it to work in any meaningful way.
And here I am having spent yet another 15 minutes on the forum instead of doing one of the dozen things I still have to finish by tomorrow.
4 Likes
As far as voting to remove abilities such as ability to remove a canister, such a proposal could be a really good symbolic vote. Practically speaking though, we could always vote to give the ability back to ourselves. Not a bad way to but force us to address the question explicitly though.
2 Likes