we are working on SEV-SNP enabled boundary nodes, but we don’t have a fixed timeline yet.
We have a first working prototype of requesting and creating the certificates and corresponding private keys such that the keys never leave the boundary node. The next step is turning this prototype into production-ready code.
However, we also need the right hardware, which supports AMD SEV-SNP. Right now, we are in the process of procuring the machines, which takes time due to the supply chain problems/chip-shortage.
It’s great to hear that you are working on nodes to enable the use of other services. I think calling these nodes, as you suggest, integration nodes is a great idea as they integrate other/external systems/services in the IC.
I think brand safety should be set to a minimum (child pornography and a couple of unacceptable things), but if we are not against censorship and/or violence imposed at the whim of governments (such as gambling) What makes us different from AWS?
I agree. The current rules are too restrictive, and the rules should be set by the community and BN operators, not some dude at DFINITY.
@rbirkner@diegop What is the status on community-owned Boundary Nodes? BNs and nodes that can’t be onboarded by anybody in a decentralized way makes the IC little better than a slower, more restrictive, AWS.
Is it technically possible to add a VPN or other encryption to canister that doesn’t register the location of the user or puts them all geographically in the least restrictive country/area?
This is not how it works. The canister has no say in this. It is done by the boundary nodes, which are the servers that route requests to the right nodes which then run the correct canister code for that request.
You can read up on how the boundary nodes work on this page
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.
Something to note here is that community owned boundary nodes will still be responsible for the content that’s served through their domains. Ultimately the decision to block canisters is out of the hands of the boundary node operators, unless they are willing to deal with law enforcement, spam lists, certificate authorities and TLD operators. Having the community decide what should or should not be served through a boundary node is very dangerous for the boundary node operator.
You are also free to host your own service worker for a canister: Internet Computer Loading. If you do this, then you are responsible for the content that’s served on that domain.
Unfortunately, there’s not much that can be done about this by the IC in the short term since internet infrastructure itself is very centralized.
The team has started to work on the new architecture. We are currently focusing on building the API Boundary Nodes. However, it will still take in the order of months until we can fully rollout the new architecture: bringing the API Boundary Nodes under the management of the NNS and deploying them in data centers of different node providers is a major undertaking.
HTTP gateways are a subset of all gateways and we might want to think about how the architecture can support gateways which expose protocols other than HTTP. For example supporting event and messaging paradigms such as XMPP or MQTT. Even a shift in terminology or diagrams to indicate the possibility of 3rd party gateways that support other protocols might be useful in terms of encouraging innovation in this area.
That’s a very good point! HTTP Gateways are just one gateway that maps an existing protocol to Internet Computer API calls. One could, for example, also think of a DNS Gateway.
I will update the figure in the coming days accordingly!
Is there a standard or minimum server hardware specification for the IC Boundary Node architecture under development? Or if nothing specific as yet it would be interesting to know what server platform the engineering team is using to develop the node architecture
we don’t have a specification yet, but I can tell you what the specs of the current boundary nodes roughly are: 8 core CPU, 32 GB of memory and ~500GB of disk.
The timeline is not fixed yet. We probably start deploying the new API boundary nodes towards the end of the year. Once we get closer to it, we will provide updates with all the information.
Sounds great. Are you planning on letting 3rd party developers create modules for boundary nodes? I assume the boundary node admin will be selecting which modules they want to install, like SMTP, DNS, etc. But it will be great if devs can create modules/docker images, which provide all kinds of servers/ gateways, why not a real-time game server that communicates with canisters and also provides quick responses? An SNS DAO could be publishing these modules.
Anyway, I want to get into the queue for boundary nodes and experiment with them, if there is such functionality. Probably even if there isn’t, the boundary node software is running inside a container and nothing stops the admin to launch more containers that use the boundary node to connect to IC?