Proposal: Host the SNS at an alternative domain to avoid existential risk to existing NNS stakes

Governance
,
1

Proposal: Host the SNS at an alternative domain to avoid existential risk to existing NNS stakes.

The following thread is meant to discuss a possible proposal for how to host the SNS user interface due to possible existential threats. I had a very nice dinner with some of the engineers and I discussed my concerns about the upcoming SNS integrations. There was no violent disagreement with my concerns, so I figured I’d throw this out for broader discussions. I’m happy to be talked out of my concerns or to find an explanation as to why these concerns are not as significant as I think they are, but I think we should talk through them before we find ourselves with a Luna Protocol running on the SNS facing serious regulatory or legal issues.

Schedule:

July 2nd - Dissuasion on the forums

July 6th - Edited Proposal and proposal funding.

July X - Proposal

Reason for the proposal:

The NNS uses internet identity to identify a user’s principal. That principal is tied to the domain name. If the NNS.ic0.app domain name was to be blocked by regulatory authorities or forced to be blocked by boundary nodes via legal threat, users would lose access to their funds. Adding access to SNS tokens to the NNS site exposes existing users to the actions taken by SNS daos which are unpredictable and of much higher volatility than decisions on the NNS due to the potentially smaller focus, distribution, and niche of the individual daos.

Current proposal text(pending discussion) - The SNS interface should be hosted at an alternative URL than NNS.ic0.app due to

Existential threat. The SNS UI should be hosted at SNS.ic0.app.

Justification:

The SNS can bring a powerful new model of dao and app financing to the IC. For all the good that will likely be generated, the platform is not without risks. Once an SNS protocol is approved it will be joined at the hip with the NNS and the entire system will be affected by unpredictable moves inside those daos.

Apologies to the named platforms here, but I felt concrete examples worked better. The following is just fantasy and should not be considered any kind of criticism of the amazing work these platforms are doing.

Scenario 1: Openchat is added to the SNS via a public vote. The code and contracts are verified. There is great rejoicing. An unknown group in Russia creates a lottery bot on openchat and begins running lotteries and marketing to Swiss citizens. The open chat SNS opens a vote to censor the bot and it fails due to anti-censorship bias in the token holders. The Swiss government votes to block the openchat domain name. Because openchat tile holders are profiting from the activities of open chat they also decide to block the access of token holders’ funds. The most direct way of doing so is to block NNS.ic0.app. Swiss citizens can no longer access the NNS(without a VPN).

Scenario 2: Dscvr issues a governance token in the SNS. A user created a channel devoted to helping assist women in need of proper medical care get to states in the US or nations that provide that care. Some procedures are made illegal in the US and a conservative activist government begins enforcing and shutting down sites that help provide access. The dscvr dao votes to leave the portal up due to the will of the token holders. The US government targets both dscvr itself and its funding mechanism tied to the NNS. US citizens lose access to NNS.ic0.app and can no longer get their principle validated(even if the app pops up at an alternative URL your principal would be different due to how the II works).

These are just two possible examples of how SNS daos will begin to make decisions, both on moral and financial grounds, that will affect other systems in the ecosystem and many of these effects are in the governance not in the code, so they can not be reviewed or predicted before adding the token.

Reason for this solution: hosting at an alternative URL gives existing users a choice as to the exposure they would like. Possibly a negative black swan will not appear, but it is difficult to say that the risk exposure doesn’t drastically change when more tokens are added to the NNS. The NNS “feels” like an official DFINITY site and even if it is managed as a dao, blowback against the NNS could be perceived by an uninformed press as negative ICP news.

Negative: Current accounts at NNS.ic0.app would need to send ICP to accounts at SNS.ic0.app to interact with SNS tokens. May affect useability.

Alternative proposals:

  1. Delegate SNS hosting to a 3rd party and host it at an alternative domain via icx proxy. Reason: this further insulates the ic0.app domain name from regulatory and legal threats. It also limits exposure. Perhaps host the SNS ui at supernova.com now that the hackathon is over. Possibly found a 3rd party shell company in the bvi to own/run the icx proxy to complicate regulation.
  2. Punt a while down the road and require all NNS-connected SNS connected tokens to run in application mode for several months. Pro: safer Con: less usable
7 Likes
2

I’ll be interested in hearing what others have to say, but here are some preliminary questions and thoughts…

  1. Why would this be an issue with SNS vs NNS instead of dApp1 SNS vs dApp2 SNS vs dApp 3 SNS vs … vs NNS? For example, why would you be ok with DSCVR SNS and OpenChat SNS being on the same domain?
  2. If experts agree this is an issue, then what solution is the best choice from the end user experience? I really like the idea of having a single app to go to to participate in SNS and NNS governance. I wouldn’t want to have to go to a different exchange to trade each individual crypto or a different app store to download each individual app for my phone. I would rather know that this is a problem that does exist and then pursue a solution as opposed to self imposing a solution to a problem that might exist. So perhaps based on my limited knowledge today, I would prefer to focus on whether or not there is a problem and engage the assistance of experts to clearly define it. If a solution space is needed, then I’d prefer an end user focus.
3

then what solution is the best choice from the end user experience

Maybe have a single index of all SNSes that redirects to the specific domain? In theory the index shouldn’t be banned, CMC lists all cryptos and has never had issues afaik.

2 Likes
4

Bluntly, as of now, I own no DSCVR or OpenChat tokens at the moment. If I did I’d be more concerned about it. In fact I think we can expect an increasing resistance to experimental projects on the “central” approved SNS subnet as the value there increase. The small experimental projects are going to have a much harder time getting “listed” in year 3 than in year 1. Yet another reason to require running in application mode for a certain time with an upgrade pathway.

I think a unified interface is great, I’m just not sure I want it to be “THE DFINITY and ICP TOKEN INTERFACE”. I’d rather have Interface1 run by an American company, Interface2, run by an EU country, IterfaceN run by X…etc, etc. In the same way that ETH is protected by running multiple clients built in different languages, these apps are going to be more robust if they are supported by multiple vendors each with their own take on useability(this is also how new/cool features emerge). In theory, if the SNS interface is a SPA Svelt app and the repo is open-sourced it would be trivial to deploy it to multiple places. The risk you pick up is “continued support” risk.

The option in the other direction is to enhance II so you can port your principal to another domain. That would greatly reduce the risk…not sure if delegation supports this or not.

1 Like
5

I see if needs to be some assessment from the experts on this matter. If it’s not too serious, you can leave SNS in the control panel a separate section for SNS and Neron SNS. it will bring a seamless experience to the end user. they won’t have to run around managing their investments and votes. In my opinion, SNS is like a Launchpad system in Binance, but SNS inherits the same good things that NNS brings. However, I have a proposal that projects that want to participate in fundraising on SNS need to be approved by the community through votes from the proposal on NNS.

6

I wrote last year on this - “Depending on the nature of the complaint and the jurisdiction, the representations to take down could be mild or severe, legal or illegal including intimidation, coercion, state sanction execution and even military action.”

If an entity perceives attacking a component (software/hardware/cansister/people) will advance their interests, it may be targetted. There are many routes to get an app cancelled - contractual, the courts, domain registrars,etc. Additional methods outside of the traditional remedies are used by governments when they seek to protect their national interest.

I think you are raising a valid concern in that the NNS holds the eggs and it is all in one basket. The remedy of having different domains is insufficient in my opinion and needs to be bolstered by the full gamut of dentralization services. Analyzing an attack tree would be useful and I believe it would show that web3 decentralization, DNS diversity, routing diversity, legal ownership diversity, jursidictional diversity, controllerless /blackholed, etc. would be required. In the end, it only slows down and does not stop deplatforming. If people are involved in the process they are ripe for coercion.

Enormous pressure will be placed on the NNS to deplatform. If they do not, there will be pressure placed to deplattorm/block the NNS.

I think it is conceivable that a government instructs:

telecom providers not to route to a domain
domain registers to point to a sinkhole
webhosts to not host web3

If the problem persists - they will start to go after node/data centre hosts outside of their jurisdiction.
it is pretty easy - there are only 6 nations involved.so just look at the trade agreements held by these nations, the economic impact if someone slows down regulations/borders, and who has something to trade for giving assistance. This is hardball that is the reality of an interwoven geopolitical mosaic.

I think the discussion around takedowns is a non starter given the discussion last year on DMCA.

Thanks for raising the issue.

3 Likes
7

This is why I think as long as nodes can only be hosted in data centers the network will never truly be censorship resistant.

1 Like
8

Wouldn’t decentralized CA & DNS solve this in the long term? If this existential risk doesn’t present itself in the short term, perhaps we can wait for that long-term solution.

1 Like