Starting from Qnect version 0.1.2 you will be able to make API calls to your own private node or to a private node of a friend or family member. API calls are what Qnect uses to communicate with the Qortal core. Setting up a private node will require some additional node setup for the person who is running the node and some setup in the Qnect app itself.
Failing to connect to a private node is usually due to any or all of the following reasons: your node is offline, your settings.json and/or port forwarding are not set correctly or the private node URL/IP address or port number that you provided to Qnect is incorrect.
In order to access a private node you'll need to white-list your devices IP's address in Qortal's 'settings.json' file and port forward your chosen API port in your router settings.
Connection settings:
There are two methods for setting up your node to allow API calls from outside IP addresses.
Method 1:
This is the easiest and recommended way to white-list your devices IP's.
Open the 'settings.json' file in the qortal folder and add the following line
"apiWhitelistEnabled":false
This will allow API calls from all IP addresses. This also means that if someone knows the IP address of your node and the API listen port that it is using, they will be able to make API calls to your node. This is not likely to happen and even if it does happen, sensitive API calls require an API key so the risks are limited. If you want to mitigate the risk of someone making (or spamming your node with) API calls you can use a different API port or use the second method described below.
Method 2:
The second method is more secure but also more complicated and restrictive and can cause API calls to fail if implemented incorrectly.
Open the 'settings.json' file in the qortal folder and add the following line
"apiWhitelistEnabled":true
This will only allow API calls from white-listed IP addresses. This also means that you will have to ensure that every device from which you are making API calls has a static IP address. It also means that you will not be able to make API calls from your mobile device through your mobile carrier since your phone is likely to have a different IP address on different occasions.
Next you will need to add the actual IP addresses which are white-listed and the localhost loop-back which will enable you to make API calls from a device on the local network.
Example:
"apiWhitelist": ["192.168.1.100/32", "192.168.1.103/32", "127.0.0.0/8"]
The first two entries are examples of IP addresses for devices on your network, you can find the IP address for each device in your router settings, which is also where you can reserve those addresses for each device (static IP address). The third entry is the localhost loop-back which is a recommended addition.
Now that you've taken care of the API white-list, the next step is to forward the API port for your node in your router settings. Since port forwarding works differently on every router you will have to find out how to forward the port on your router, try doing an internet search for 'port forwarding <your router model here>'.
If you want to use a custom API port (for example port 12345) you can add the following line to the 'settings.json' file
"apiPort": 12345
If you do not set a custom port your node will use port number 12391.
Forward the API port (default is 12391) for your node's IP address in your router settings. Be advised that your node's IP address must be static, otherwise your router could assign a different IP address to your node and your port forwarding settings will become irrelevant for your node's actual IP address.
Once you've correctly setup the API whitelist and port forwarding for your node's API port, Qnect will be able to connect to your private node from either your own local network or from an outside network. Tap the icon at the top left of the Qnect app bar to open the connectivity menu, then tap on 'Edit private nodes list' which will open the nodes edit screen. Here you can add a new private node or edit the nodes in your list. Click on the plus button to add the URL/IP address + API port to your private node.
To connect from inside your local network enter the following:
<your node's local IP>:<port>
Example:
192.168.1.100:12391
To connect from outside your local network (like 4G from your phone) enter the following:
<your WAN IP>:<port>
Example:
172.64.32.71:12391
Please note that the character between the IP address and the port is a COLON, NOT A DOT.
To find out what your WAN IP is you can do an internet search for 'my IP address' from a device that is connected to your local network. Please note that your ISP determines your WAN IP address and can change it at any time in which case you'll have to provide Qnect with the new WAN IP address.
Qnect assumes that your private node has QDN authBypass enabled by default. This means that your node does not require an API key to fetch QDN data, such as user avatars, from your node. To enable QDN authBypass add the following line to your 'settings.json' file
"qdnAuthBypassEnabled": true
Currently, Qnect only uses the bypass in order to fetch user avatars. If you do not want to enable QDN authBypass you can also choose to provide Qnect with the API key for your private node, you can do this by tapping the key icon next to the private node's URL in the private nodes edit screen. If a private node does not have QDN bypass enabled and your API key is missing or invalid, Qnect will not be able to fetch user avatars when using that private node.
Connecting to your private node is done through direct connection over http, which means that your API calls (some containing your API key) will not be encrypted and that your API key could be exposed if any third parties are monitoring your internet traffic. If you are not comfortable with this, it's best to either enable QDN authBypass or only connect to your private node from your local network and only use public nodes when you are outside of your local network. Qortal's public nodes use https which encrypts your internet traffic.
It is possible to setup your node over https, similar to the way Qortal's public nodes have been set up, this is not something the average user will be inclined to do and the aim is therefore to implement a more user-friendly method to encrypt API calls between devices and private nodes in the future.