Content Filtering via Boundary Nodes

This is a great post Diego!

Thank you for sharing this in the forum! (RT’d on Twitter)

I’m going to share the Twitter Space link (just discussed today)

We had a great discussion with leaders in the IC Ecosystem! Thank you to Diego, Andra, Jan, Lomesh, Jordan Last, theguy.icp, IC Biebert (Aaron) and my Co-Host Daniel for taking the time to speak on this topic!

The Swop Twitter Space - IC Boundary Nodes & Censorship

4 Likes

Wow epic post. If only you had these answers last year when all the maxis were popping off about how we shouldn’t ban mario cart. Such an elegant design. Bravo.

2023 is the year of the IC!! Ahoy Diego!!

6 Likes

Will Boundary Node providers need to get paid more than typical consensus node providers? It seems like quite a bit of work to be a boundary node provider with the need for constant monitoring if canisters are violating some policy. Once the IC replaces AWS how can BN providers reasonably scan the entire IC for canisters that are violating their policy? Even for the most conservative BN providers it feels like a never ending game of whackomole.Over and above this, as a conservative BN provider I would need to educate myself as to all the laws all around the world!

@diegop Since the Http gateways are being split off, what protocol will the API Boundry Nodes use for API calls? Will it still use HTTP/CBOR or something different?

Few users in the US and Switzerland who cannot see the canister asked that I share what the website looks like, so a friend in India was able to screenshot it for me.

Here is what users outside the US and Switzerland would see:

2 Likes

I am not aware of any change, so I have asked @raymondk (Sr. Engineering Manager of the boundary nodes team) to reply.

2 Likes

What about countries where you need a gambling license in order to operate?

Hi @Gekctek, there are some details in this boundary node roadmap forum post: Boundary Node Roadmap

The short answer is that the API boundary nodes will continue using the current http/cbor API that is used today to talk to the ic0.app/api endpoint.
The http gateway’s primary function will be to terminate TLS and serve the service worker.

4 Likes

@dfisher Clarification…when you say “boundary nodes”, do you mean “http gateways” (which wont get remunerated) or “API Boundary nodes” (which are remunerated)?

I assume the latter.

But to answer your question, I am not aware what the remuneration table for those will be. I expect some supply/demand to be a part of it, but thats me speculating.

For http gateways, i expect many people to run them for their own access… but if there are not enough, I would also expect the design is revisited and iterated upon.

1 Like

agreed! Great Twitter Space

1 Like

For the non technical, do you mind explaining the difference EL5 between http gateways and API Boundary Nodes?

Do you mind also explaining how it will be possible to keep up with all the illicit canisters? Is that a difficult problem to solve?

2 Likes

This article is great. Sorry for the trouble. I know this project is heading in the right direction. Also I was able to use dfx without a vpn this morning thanks to your upgrades. I’ve also cleaned up the canister in question to avoid any future problems.

2 Likes

Fwiw, I am a strong believer that cases like this allow for a strengthening of the network. Allows community to come together and improve the network. My classic example is standup comedians. I believe standup comedians get INSTANT feedback. Not laughing is feedback.

The best standup comedians are borne from thousands of joke iterations, so you can always tell the ones who worked at small clubs all the way to the HBO special. Each set and joke that bombed is another opportunity for iteration.

Similarly, each case where community has to decide improves the network for the big time.

Thank you for taking the time to layout the issue.
Presently, a BN has implemented enforcing the national policy (e.g. no gambling apps accessible to Switerland and US). You have said this architecture was selected to protect the blockchain.

If the number of BN increases (e.g. home boundary nodes) there will be a wide view of the risk calculus. Meaning, some one will permit serving the app. Would this not mean that the block chain would be put at even greater risk?

Good question. In the new architecture, the risk would be on the HTTP Gateways being blocked themselves. The intent of the design is that there CAN BE many risk calculi, but maximizing access to the blockchain* is not at risk. If a HTTP Gateway were blocked, more would be spun up trivially.

The current BN architecture implements a filtering policy that permits the IC blockchain to operate and keep regulators happy because it implements a single policy that complies with state regulation/law.

If multiple BNs serving a region do not implement the same policy the regulators will quickly realize that engaging a BN is ineffective. It is likely that they will then pursue other options that you were attempting to avoid.

1 Like

Sure let me try. First let me post the more technical definitions:

  1. “HTTP gateways”: provide an endpoint to the users that terminates TLS, serves the service worker and translates the users’ HTTP requests to API canister calls. Anybody will be able to run any HTTP gateway they want without needing any NNS proposal. These nodes will NOT be rewarded with ICP.
  1. “API boundary nodes”: provide an endpoint that handles API canister calls by routing them to the correct subnet and replica node, and provides caching and rate-limiting to protect the IC. These nodes will be allowed into the IC via NNS proposal and will be rewarded with ICP for their work (like consensus nodes).

Here is my ELI5:

  1. HTTP gateways:
  • Anybody will be able to run them. Basically routers that when a user/browser/dapp hits a domain like “monkey.dapp” or “david-fisher.io” routes the request to the API Boundary Node.
  • HTTP Gateways do not know which subnet a canister lives in, they just pass the request on
  • HTTP Gateways are not paid in ICP
  1. API boundary nodes
  • Receive requests from HTTP Gateways
  • These are paid in ICP and are approved by the NNS DAO
  • These know which subnet a canister lives in
  • They do common server tactics to make sure the IC is safe and not overloaded with requests

Was that helpful?

2 Likes

Hey @dfisher while I was writing my answer, I saw that @diegop posted his. I took a little bit a different approach and tried to explain the basic task of both the API Boundary Node and the HTTP Gateway:

To answer your question, let me first focus on the replica nodes that host the actual canisters and then bring the API Boundary Nodes and the HTTP Gateways in the picture.

Replicas expose an API to interact with the canisters that they host. Think of a simple counter canister, for example, which allows to obtain the current value (query) and increase the count (call) through the API.

If you wanted to make an API call to increase the count, you would have to first figure out in which subnet the canister is running. Then, you would have to find all the replicas that are part of this subnet. Only then, you could submit the API call to one of the replicas. This process is called routing.

The API Boundary Nodes take care of that for you. You can think of the API Boundary Nodes as forming the edge of the Internet Computer. You can submit your API call to any of these API Boundary Nodes and they will make sure the right replica node inside the Internet Computer receives it.

API calls are specific to the Internet Computer and only applications built specifically for the Internet Computer support them. Our goal, however, is to make the canisters accessible for anyone using their standard browsers, which only “speak” HTTP(S).

That’s where the HTTP gateway enters the picture. It provides an HTTP endpoint that acts as a gateway to the Internet Computer by translating the HTTP requests from the browsers into API calls.

To sum up: the API Boundary Nodes handle all API calls to make sure they arrive at the right replica, while the HTTP gateway translates the HTTP requests from the users’ browsers to API calls that the replicas can process.

Note: I tried to explain the difference at a very high-level and therefore simplified and left out a lot of details. If you want to know more, check out the Boundary Node wiki page and the forum post on the future Boundary Node architecture. Let me know if you have any questions or I didn’t explain something properly.

6 Likes

Thank you for a highly professional and very well structured response, also congratulations for doing social listening efficiently and finally for tackling difficult issues head on with the community.

2 Likes

You are very much welcome!

1 Like