2. How it works now & How it we think it should eventually work
The first thing to note is that this experience is the current state of the world. The current user and developer experience are a mix of:
- short term implementations that are knowingly imperfect
- long term design needs necessary for the health of the IC.
In short, there is a gap between the long term design and the implementation. Let’s tease those apart.
2.1 What is Content Filtering?
Content Filtering is when a Boundary Node does not serve requests relating to a canister. The canister’s code and state remains on-chain and intact.
Examples of content filtering:
- BN in Germany does not serve a gambling dapp to Switzerland-based users because online gambling is illegal in Switzerland, but it does serve the gambling dapp to Netherlands-based users where online gambling is legal.
- It does not matter whether the BN is in Germany, Switzerland, Netherlands, Mexico, India, US etc… What matters is where the user requests are from.
Content Filtering does not:
- Delete or modify the canister in question. It remains on-chain with its state preserved.
2.2 Why does the BN care about what content it serves and to whom (e.g. “content filtering”)?
There are two levels to this question:
- Why the IC needs content filtering in the first place
- Why does the content filtering live at the boundary node level
Let’s go into each of these:
2.2.1 Why the IC needs content filtering options
There are detailed threads on content filtering such as in this forum post, but here is a slight simplification:
In today’s world, servers (or data centers) get takedown notices from entities (e.g. countries, companies, etc). If a server does not comply, the server is typically removed from a data center and/or the domain in question is blocked by ISPs. For example: Swiss ISPs may block a server in the US if it considers it problematic (e.g., because it is a gambling site)… eliminating access to Swiss users of that server. Rather, than naively have an “all or nothing” strategy for content on the infrastructure edge of the IC, it is healthier to address the problem directly by:
- Enabling boundary nodes to choose what content they serve. This ensures that the decision to comply (or not) with the local laws belongs solely to the boundary node operators. The ones that choose to comply may have higher probability to remain online or accessible in the environment they are in or for the communities they want to serve. This maximizes the number of servers online and number of users getting access to IC content.
- Making it easier for people to run their own servers so that there are enough variety of policies and nodes that users can find access to the canister of their choice. This maximizes the probability of any given canister being served.
2.2.2 Why does the IC’s content filtering live at the boundary node level
As mentioned in this post from February 2022, the design intent is (emphasis my own):
“At a high level, the plan is to make boundary node operators responsible for deciding whether to forward requests to specific canister smart contracts. This will enable them to filter access to canisters, for example in response to takedown notices that legally oblige them to stop serving content or face sanctions and fines. Since boundary nodes generally serve specific geographies and jurisdictions, this makes it possible that canisters will be accessible in some places, but not others, depending upon where legal action occurs. Having boundary nodes limit access to canisters, on a case-by-case basis, is seen as superior from a decentralization perspective to having node operators attempting to remove or freeze canisters by submitting proposals to the Network Nervous System (a special DAO that automates the management and governance of the Internet Computer blockchain network by the community).
Each operator of boundary nodes will be responsible for defining their own policy and practices. As a boundary node operator, DFINITY is developing its own policy, which will be made public in the coming days and defines in what circumstances it may decide to refuse to route HTTP requests to a canister on the blockchain. Currently, while subnet blockchain node machines are run by independent node providers from data centers around the world, boundary nodes are run exclusively by the DFINITY Foundation, which has allowed it to help protect the blockchain.”
Since then, DFINITY’s Boundary Node policy has been made public.
Worth noting that post is a result of a significant brainstorming with the IC community where the community proposed choosing Boundary Nodes as the way to handle Content Filtering. This was what the IC community wanted to do (as a matter of fact it was against DFINITY’s original proposal).
2.3 What are the main differences between the current implementation and the long term design?
The boundary node roadmap goes into further detail, but I will lay out the basics:
Soon, “boundary nodes” will be split into two::
-
“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.
-
“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).
A clear and immediate consequence of this upcoming work: If this were complete, in the recent example of canister vrnyn-miaaa-aaaao-aaaba-cai, even if DFINITY’s HTTP gateways did not serve canister vrnyn-miaaa-aaaao-aaaba-cai to US or Swiss users, the canister developer (or anyone really) could spin up their own HTTP gateway and serve the content vrnyn-miaaa-aaaao-aaaba-cai themselves.
2.4 Which entities run Boundary Nodes currently?
While consensus nodes are fairly decentralized (with increasing number of nodes and node providers), as of January 2023, only DFINITY runs BNs. Worth stressing again that the BNs do not affect anything on-chain.
The reason has to do with security: until the boundary node roadmap to replace “boundary node” architecture is complete, it is not secure (yet) to have more entities running boundary nodes (I am skipping the technical details for simplicity).
And yes, DFINITY as the only entity running BNs is an intermediate phase that will soon be over (ETA Q2 2023) and anyone in the community will be able to run their own HTTP gateways or API boundary nodes
2.5 How will more “HTTP gateways” and “API Boundary Node providers” help?
Few obvious benefits:
-
The thesis is that in a world with hundreds or thousands of HTTP gateways providers, if a user is looking for canister X, there will be some HTTP gateway provider that is willing to serve that canister (perhaps it’s the canister’s developer themselves).
-
As an additional measure, users will be able target directly an API boundary node with an IC-native client (e.g., browser extension), which doesn’t exist yet, but could be built by any community member. Using a browser extension, one will be able to access a canister under icp://canisterid.
-
iOS or android apps will be able to directly communicate with the API boundary nodes, so they will not need to trust the gateways nor the boundary nodes but can verify canister data directly using the ICP public key.
2.6 If a canister developer does not trust other HTTP Gateway providers to serve a canister, would it not be easier for the developer to run their app on a single server instead of deploying to the IC and run their own HTTP gateway?
Simple: a canister developer can rely on the tamperproof qualities of the IC and its consensus… while relying on their own HTTP Gateway to guarantee access.
As an example, users may trust a lottery or defi smart contract on the IC because it is executed on multiple consensus nodes, but they may not trust it if it ran on one machine entirely in control of the developer.
2.7 How close is the IC to the new architecture?
As of January 2023, the Boundary roadmap is here and the IC is months (not weeks, not years) from having the new architecture composed of HTTP gateways and API boundary nodes.
Q1 2023:
- The team starts implementing the new boundary node architecture that decomposes boundary nodes into “HTTP gateways” and “API Boundary Nodes”.
Q2 2023:
- New architecture with HTTP Gateway and API Boundary Nodes is shipped
Q3 2023
- Architecture will be managed by the NNS (API Boundary nodes are approved by NNS DAO).
2.8 If I want to create a dapp that is always accessible no matter the policies of BNs, what do I have to do? Are there any temporary solutions?
The obvious answer is “wait for the new architecture that does it right” then a developer can roll out your own HTTP Gateway (Or you can also provide an IC-native client that directly targets the API Boundary Nodes). Then you would not need to rely on anyone but yourself. In fact… unlike consensus nodes, which are rather beefy machines running in data centers to keep up with consensus, the design intent is that HTTP Gateways be so simple they could run from people’s homes.
However, the DFINITY R&D has come up with a few temporary workaround (and are looking into some more):
- A user could use something like a browser-extension. One can always directly target a boundary node with an IC-native client (e.g., browser extension), which doesn’t exist yet, but could be built by any community member.
- A developer who wants to go the extra mile could use IC Front (GitHub - dfinity/icfront ) and set up a custom domain so they do not go through ic0.app (DSCVR does this for example).
And we are looking into others…