Interface Overview
Currently the interface is divided into two parts:
- A navigation bar on the left hand side(1),
- A section that shows contents of the tab selected on the navigation bar(2).
The home page is relatively empty right now, with a banner on top that shows the peer ID of this instance.
You can select the text and copy the ID and paste later.
This page shows overall status of your instance.
This tab tells you how many peers this instance currently has direct connection to.
OwlNest won't actively seeking for peers to connect unless told via kadelima(DHT) bootstrap functionality, or there is enough peers in the DHT by manually connecting peers with their addresses, more on its dedicated section. So this count would be 0 at startup.
This tab is where things get interesting. Here you can tinker with your network topology.
mDNS, as the name suggests, is a DNS service, but only on your local network without a central DNS server. It will periodically send multicast query messages and wait for potential hosts to respond, then identify them.
Here the mDNS functionality will only identify other OwlNest instances, or more specifically, other instances that is using libp2p as their networking stack and also using libp2p implementation of mDNS. More on how libp2p works with mDNS here.
You can click into the tab to see peers that have been identified by mDNS. Note that OwlNest won't automatically connect to those peers, with the exception that the peer is added to local DHT and a DHT network walkthrough(aka bootstrapping) is being performed.
You can press ESC on your keyboard to return to previous page.
Kad is short for Kadelima. We won't get too deep into the technicals in this page so more on the algorithm on Wikipedia. Basically, it's an address book that can be exchanged between peers.
Due to the fact that there are few OwlNest instances out in the wild, we will take advantage of IPFS DHT network for the moment, hence most peers you see in the address book and connect to will be IPFS peers. They will help us maintain obsevability of OwlNest nodes.
There are two modes for managing DHT:
- Client: only listens on the network without publishing records on local instance.
- Server: actively publish records on local instance while activly seeking for new records on other peers.
You can browse the local address book here, and search for a specific peer with the search bar on top. Note that by pressing the button to the right of the search bar you will refresh to get the latest record on local peer. The address book will not reflect latest network landscape unless there are ongoing bootstrapping requests.
Once there are entries in the address book, you can click on it to show more of the record, including the address of the corresponding peer.
You can copy the ID and/or its address by double-click on the text. Selection is not allowed.
You can issue a query that informs all peers participated in this DHT network to look for a specific peer with its peer ID. If the peer with the given peer ID is not found(not reachable), its logically closest neighbors are returned.
Logically closest peers are those whose peer ID gives smallest binary result when performing XOR computation with the given peer ID. Logically closest peers are not necessarily physically closest, nor most easily reachable, but most suitable for finding shortest routing path, which is the purpose of using kadelima algorithm.
You will see two button named "insert default nodes" and "bootstrap", and below is a section that tracks events generated by kadelima management process under the hood.
Once the button "bootstrap" is pressed, and there are enough peers in local DHT, bootstrapping process is started.
Local instance will connect to those peers and send messages to fetch their view of the network. Then the address book on local instance will be updated. New peers that are not contacted will be contacted, fetch their view of the network, update the address book, and continue. Eventually local address book will have a relatively complete view of the network, with all participating peers and their publicly reachable addresses.
This also means a lot of resource will be consumed, including network bandwidth, CPU cycles and memory.
You will need at least one other node in local DHT to start bootstrapping.
Because we are using IPFS DHT network, the default nodes are from IPFS bootstrapping nodes
OwlNest uses the same underlying networking stack as those IPFS, which is libp2p.
A lot of features IPFS nodes support are present on OwlNest, including identify, Kadelima, ping, Peer ID and relay.
They will help us maintain a relatively healthy network with peer discovery and NAT traversal(hole-punching) without many OwlNest nodes in the wild. We should be grateful for their contributions.
There are plans to intergate IPFS deeper into OwlNest.
OwlNest will periodicly contact peers in the network to see the outgoing network address of local instance, compare what they observe and what local instance sees to determin if there is NAT between local instance and remote instance.
There are 3 different NAT state:
- Public: the addresses observed by remote is the same as what local instance is using, which means there appears to be no NAT in between.
- Private: the addresses observed by remote is different from what local instance is using, which suggests there is NAT present.
- Unknown: Confidence score is simply the number of peers reporting the same NAT state.
The description of UPnP can be found here on Wikipedia.
OwlNest uses UPnP to negotiate public IP address with the gateway of your local network.
There are two different status:
- Available: the gateway successfully assigned a public network address for local computer.
- Private: the gateway can't assign a public network address because itself is also on a network not publicly reachable, or the gateway is not found or doesn't support UPnP. Click the tab for more information.
There are some limitation in upstream UPnP support. It will report gateway not found when there are multiple gateways present.
Here you can make connection to other peers, listen on different IP addresses, list connected peers and browse relays.
You can dial a peer using multiaddr, specs of multiaddr format can be found here.
For example:
- You want to dial a peer on IP 192.168.1.100 port 11111 using UDP transport without knowing the peer ID, you can dial
/ip4/192.168.1.100/udp/11111 - You want to dial a peer on IP 10.0.21.3 port 8348 using TCP transport without knowing the peer ID, you can dial
/ip4/10.0.21.3/tcp/8348 - You want to dial a peer on IP 10.0.21.3 port 8348 using TCP transport with peer ID, you can dial
/ip4/10.0.21.3/tcp/8348/p2p/peer-id-of-the-peer-here - You want to dial a relayed peer through relay on IP 10.0.21.3 port 8348 using TCP transport, you can dial
/ip4/10.0.21.3/tcp/8348/p2p/peer-id-of-the-relay/p2p-circuit/p2p/peer-id-of-target-peer
The "events" below shows all connection activities, including successes, failures and disconnects.
You can listen on an IP address and port with multiaddr.
For example:
- You want to listen on IP 192.168.1.100 port 11111 using UDP, you can listen on
/ip4/192.168.1.100/udp/11111 - You want to listen on IP 10.0.21.3 with a randomly picked port using TCP, you can listen on
/ip4/10.0.21.3/tcp/0 - You want to listen on all IP addresses with a randomly picked port using TCP, you can listen on
/ip4/0.0.0.0/tcp/0
Active listeners will be listed below in "Active Listeners" section. The list is refreshed after a listen command is issued, and at an interval of 5 seconds. You can also manually refresh the list by clicking the refresh button.
The list includes listeners on relays.
You can see all peers local peer has connections to, check its protocol stack and all supported protocols.
By double-clicking the peer ID, you can copy it.
Clicking on the blank area of an entry, you can expand the entry to see its protocol stack and all supported protocols. If it's blank, it means the peer doesn't support idnetify.
You will typically see two different protocol stacks:
-
ipfs/0.1.0is for IPFS nodes -
/owlnest/0.0.1is for OwlNest nodes.
You can also disconnect from that peer by clicking "Disconnect".
Relays are one of the most important features of libp2p and OwlNest. This allows you to connect to peers who are behind NAT or even a complete separate physical network as long as there is a peer in between.
All traffic through the relay is strongly encrypted, only the sender and receiver can decrypt the data(E2E encncryption).
The list is ordered by RTT(Round-Trip Time) of all connected relays. You can expand the entries by clicking the blank area, or copy the peer ID by double clicking its peer ID.
You can see all addresses you can listen on on that relay after expanding the entry. Click the "Listen" button to listen on the peer.
You can also see if any peer is advertised on the relay, as long as it supports /owlnest/advertise protocol. If it doesn't, this section will not show up. By clicking "Advertise Self", other peers can see your peer ID being advertised on the relay through /owlnest/advertise protocol. You can also "Remove Advertise". Please note that the result is not immediate, you may need to wait for a few seconds for it to take effect. You may also need to refresh the list to see the result.
This tab shows some protocols you can interact with. We will continue to add more interesting protocols for our users.
Messaging protocol(/owlnest/messaging) can be used to send short text messages between peers, similar to IM chats.
By expanding the entry, you can see a list of all peers that supports this protocol. By double-clicking the peer ID, a new window will show up and you can start a chat with that peer. However there will be no notification for the peer receiving the messages. Your chat history is saved in memory and will be cleared after restarting the program. OwlPort-Desktop currently has no data persistency layer or databases and we will add this feature in the future.
File transfer protocol(/owlnest/blob) can be used to move large amounts of binary data effeciently.
By dragging the file on top of the newly created window, its path is read and you can put in the peer ID you want to send to, the click "Send" to send your file. The other peer need to accept the file to start the actual transfer.
The file is saved in your "Download" directory for Windows users. This will be made configurable in the future, as we find a proper UI layout.
You can terminate the transfer at any stage. For the sender, clicking Cancel will stop sending bytes of the file immediately; for the receiver, clicking Cancel will stop new bytes being written into the file immediately. Once either end canceled the transfer, the other end is informed and the transfer is completely terminated.
This tab is currently empty, as we're still in an early stage of development. You can contribute to this repository to speed it up! Or by simply yell that you want a new feature to get the project going!