Suggestion to Protect DAOs

If an SNS frontend canister is linked to a custom domain, it should be impossible to link that domain to another canister without a 67% DAO vote. It may not stop the domain owner and probably founder pointing the domain to another site but it will stop them pointing it to another IC site.

Not sure if this happens.

2 Likes

Hey @jamesbeadle

You raise a good point, which has lead to quite some discussions within the boundary node team when the first SNSes launched.

Unfortunately, there is nothing we can really do:
At the moment, no DAO can own or control a domain name. Hence, there is always someone that owns the domain and has full control over it.
We could think about introducing some special mode in our custom domains service that restricts changing of the domain to canister mapping as you suggest. But that also doesn’t really work because:

  1. If the owner of the domain is lazy, they point it to some other hosting services (outside of the IC). However, I am not sure users would even notice/be able to tell that this is not hosted on the IC.
  2. Anybody can run their own HTTP gateway with a custom domain and nothing prevents them from pointing the domain then to whatever canister they want.

The only real solution to the problem is having an on-chain naming system: Technical Working Group: Naming System

2 Likes

Is there no way the IC can ‘own’ domains, and people transfer them into the Internet Computer. Just like you link out to say other chains, can’t you integrate with the DNS service. Even using a centralised entity like you do for verifying bitcoin is clean could be used to hold domain names.

Also another thing would just be uniquely mapping to .ic0.app, almost clean enough to work on it’s own.

Is there no way the IC can ‘own’ domains

This depends on the registrar. I am not aware of any registrar that allows a DAO to register a domain. So, the closest to “the IC owning” a domain would be to register a domain, get an API key and then control the domain from the canister with HTTPS outcalls and the API key. However, whoever registered the domain would still be in control and you might not want to put the API key into the canister.

Also another thing would just be uniquely mapping to .ic0.app, almost clean enough to work on it’s own.

I don’t follow. Can you please elaborate.

Sorry if you put something in a tag it disappears, using braces instead {domain}.ic0.app, for example openfpl could have openfpl.ic0.app, still not completely clean but better than a canister id

1 Like

I’m not sure if that’s been suggested before but it’s a great idea. I think it deserves it’s own thread.

We integrate with custom domains in dynamically created canisters and it’s really hard to do right now.

The issue is that there has to be an HTTP outcall every few hours to check with the IC boundary nodes. That call costs a lot (in our case ~0.20$ to 0.30$ in total) and has a lot of edge cases that have to be dealt with.

1 Like