Hello everyone,
First and foremost, we, the DFINITY Foundation, want to thank you all for the spirited discussion over the last week. We are completely blown away by the passion around this topic and the well-thought out responses you’ve shared here in the forum and on the Twitter Spaces discussion last week (thank you @lastmjs and @bob11 for organizing). Please know that we have read every post, and many team members were also able to join the live discussion on Twitter.
We understand that conversations are still ongoing, but we wanted to start a thread here to summarize some of the most salient points to ensure they were heard correctly and answer some of the outstanding questions we found in the forum thread related to the incident.
We are also in the process of writing up a longer blog post discussing some of the larger, more systemic issues discussed in the thread and how we believe the Internet Computer is uniquely positioned to solve them. Please be on the lookout for this very soon.
Feedback Summary
Below is a summary of a few of the themes we have synthesized from community feedback. We thank you again for your input, and we will involve ourselves in the conversations that are forming around each of these, and, in cooperation with the community, scope any items to be added to DFINITY’s roadmap. We have linked to relevant forum threads for each topic, and for those without an active thread, we will plan to put forth new posts in the forum soon to begin some of these discussions.
Better protections for node providers
This sentiment was expressed across the board, and several of the potential solutions put forth (e.g. node shuffling, secure enclaves, etc.) are either actively being discussed or are already on our public roadmap. We are also researching some of the technical aspects of suggestions put forth in the original thread, such as the possibility of sending a notice to and/or taking action directly against a canister controller.
Relevant thread(s): Plausible deniability for node providers
Potentially open to guidelines, but not an AUP
The AUP was merely a suggestion to get the conversation started, and your concerns with this particular type of policy have been heard. We will continue to engage in community-led conversations around this topic to see what emerges. Even when the appropriate technical solutions are identified, we still believe there will need to be an accompanying process, documentation, etc. to explain how this will work to the community.
Token holders would appreciate expert guidance and filtering (especially as frequency of these kinds of issues increases)
We agree that reviews like this require expertise that most token holders more than likely do not have, and that as the network scales, there may be too many proposals to review (e.g. 100’s or 1000’s per day). There were also concerns flagged around gray areas within IP disputes and the lack of token holder expertise to properly evaluate these issues. We will also take the suggestion of the thread to explore different weights for these types of decisions (e.g. requiring a higher-than-normal voting power) and/or boosting neuron power for those involved in the review process (while acknowledging that there are conversations ongoing that propose solutions not related to NNS proposals).
More notice required before a proposal is submitted
Many of you were concerned that there was not enough time for discussion before the proposal was put forth. For issues such as this where “off-chain” legal timelines are a concern, our intent is to waste no time to let the community know of the issue. In this particular incident, the proposal was put forth quickly due to associated DMCA timelines. To address some of the concerns raised by the community, shortly after the incident, a motion proposal was put forth and approved to increase the minimum voting period for proposals to 4 days.
Delete / uninstall canister via NNS can be dangerous
Several people in the threads have discussed that the delete / uninstall proposal type can be dangerous, especially if the content being removed is high-value (e.g. an NFT hosted in a canister). We are actively researching suspend and wake-up mechanisms for canisters to provide more optionality in these situations (while acknowledging that there are conversations ongoing that propose solutions not related to NNS proposals).
Boundary nodes as censors
In the last 48 hours, a proposal and discussion has emerged around the idea of boundary nodes acting as censors, as well as a variation related to DNS as censors. The DFINITY team is actively tracking and engaging in this conversation.
Relevant thread(s): Boundary Nodes as Censors, DNS as Censors
Questions related to the Incident
Below are a few questions related to this incident specifically that were raised in the original thread. We hope this provides some clarification as to what happened.
How did Nintendo track down the node provider?
A Nintendo bot traced it back to a data center running one of the boundary nodes. They were able to identify the boundary node provider via the IP address associated with the boundary node.
What does a node provider have the capacity to do in a situation like this?
There are two types of nodes: the boundary node that routes traffic to a specific canister from the internet to a replica node of the subnet hosting that canister. No node provider can remove a canister by itself. They can of course switch off the node, in which case they would forfeit their node provider rewards. This obviously will not solve the problem of the canister being deployed on and replicated across the network, but it allows them to comply with any legal notices. The only other option they have (currently) is that they can submit an NNS proposal to delete / uninstall a canister, just like anyone else.
What would prevent someone from re-deploying the questionable content?
At the moment, not much, other than the minimum fee to create and deploy a canister of 2T cycles. It would likely become a game of whack-a-mole. Several ideas have been raised around penalizing principal IDs, creating a registry of flagged canisters or Wasm modules, or sending notices directly to a canister controller. Other solutions are also being discussed as part of the threads mentioned above (e.g. boundary nodes / DNS as censors).
We thank you again for your feedback and all of the productive discussions. Stay tuned for new forum threads in the coming days to address some of the topics and technical proposals discussed here as well as the blog post.