A Connext node is an implementation of the Connext protocols. Anyone who is using Connext in any way should most likely be running a node.
Nodes take in the following:
There are two primary node implementations available right now, both written in Typescript:
In general, nodes expose very similar interfaces and behave very similarly. There are a few notable differences, however:
Passed in via node.config.json file
Passed in via constructor.
Takes in a mnemonic and supports creating multiple signers by passing in an index. See more below.
Communicates with iframe-hosted signer over RPC interface through postMessage API.
The server-node's HTTP requests are wrapped into a JS client. This can be installed into a standalone Node.js program by installing the @connext/vector-utils package. Minimally, the client is instantiated like so (assuming a local setup similar to make start-node or make start-duet):
The client has wrapper methods for the server-node's REST interface, which implement the interface IServerNodeService.
Note: because the browser-node exposes a TS interface directly, there is no need to do this in the browser.
In most cases, the server-node manages a single private key and signs all channel operations with this key.
However, server-nodes also possess the ability to handle many different signers in the same stack concurrently. You can do this by specifying an index param in the connect method.
This functionality is possible in the server-node by deriving private keys from the mnemonic in the server-node's config (more info). By default, the server-node creates an engine at the index path "0" for convenience.
Below is an example of creating a new Engine instance. The index param is an integer between 0 and 2147483647 (2^32):
The response to this request contains a signerAddress and publicIdentifier. Additional calls to the server node must include the publicIdentifier to specify which engine to use.