We’re excited to share proposal #134902, which outlines our plan to add 17 additional API boundary nodes across various regions, bringing the total to 20 nodes. This marks a significant milestone in advancing the new boundary node architecture. With this step, the Internet Computer (IC) will feature a fully NNS-managed edge, enabling IC-native clients (e.g., agent-rs) to directly connect without relying on traditional boundary nodes.
Proposed Nodes
We propose converting the following 17 unassigned nodes into API boundary nodes:
The candidate pool included all healthy, unassigned nodes configured with both an IPv4 address and a domain name. From this pool, we selected nodes to ensure broad regional coverage, aligning API boundary nodes with the distribution of traditional boundary nodes. Additionally, we prioritized diversity in node management by choosing nodes operated by multiple node providers and located in different data centers.
Reason:
The proposal is correct, double checked that all the nodes are healthy and unassigned and in the specified DC’s. Great to see one of them 4p3lu from NP Zenith Code LLC who are already doing an amazing job with the IC-OS reviews, and hope to see them more involved in boundary nodes related proposals as well. @zenithcode
A very slight concern would be if the 3 nodes from Switzerland even though in different DC would have the same ISP that is the case for majority for EU’s DC’s, but this is another topic for general subnet management.
CodeGov has a team of developers who review and vote independently on the following proposal topics: IC-OS Version Election, Protocol Canister Management, Subnet Management, Node Admin, and Participant Management. The CodeGov NNS known neuron is configured to follow our reviewers on these topics and Synapse on most other topics. We strive to be a credible and reliable Followee option that votes on every proposal and every proposal topic in the NNS. We also support decentralization of SNS projects such as WaterNeuron and KongSwap with a known neuron and credible Followees.
Learn more about CodeGov and its mission at codegov.org.
When it comes to directly communicating to an API boundary node via an IC client, is that fully supported right now? As the creator of icp.net should i be making a change?
I seeing some docs about icp-api.io but am unclear if that should be the default or supported right now
Sorry for the delayed response: Just for me to understand what are you currently running through icp.net.
In general, you can now run your own HTTP gateways that directly connect through the API boundary nodes to the core of the IC. This means you do not have to rely on any centralized infrastructure. It is a bit more complicated to do that than just routing all your requests through icp-api.io. However, we have integrated tooling into agent-rs that helps you with that.
If you intantiate your agent with with_background_dynamic_routing(), it will automatically use the API boundary nodes:
let agent = Agent::builder()
.with_url(URL)
.with_background_dynamic_routing()
.await
.build()
.expect("failed to build ic-agent");
All you have to do is to provide a seed URL (e.g., icp-api.io) to bootstrap the agent (i.e., to fetch the list of all API BNs from the registry). After that, the agent runs health checks on all API boundary nodes in the background and measures latencies. When you send API calls (e.g., query and update calls), the agent picks an API boundary node that is healthy and close-by.
We also provide our implementation of the HTTP gateway (ic-gateway). You can download/build it yourself and run that as well.
Those are both resources just to get you started. Let me know if you have any further questsions and also what you are planning to do with icp.net.
I guess it was more of a question of is this openly supported so that other clients besides agent-rs can implement it, vs it being internal/beta stages. If it is, is there documentation for it?
Also would this just be for implementing an HTTP gateway? my thought was that if there is no browser because its just an agent wanting to talk directly to the IC, wouldn’t we just want to bypass the httpgateway and just go straight to the API node directly? Or is there something about the HTTP gateway that is beneficial even for API clients that communicate from an app?
