Content Filtering via Boundary Nodes

Developers
21

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
22

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
23

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
24

You are very much welcome!

1 Like