We keep saying that Jami’s most distinctive and innovative characteristic is the fact that it doesn’t require a server to relay data between users. There are many advantages associated with that, including increased privacy, light infrastructure, high scalability, no bandwidth restriction (other than that of your Internet connection), no size limit for file transfers, and more. This is all true, but while servers are not required, they are still used in five specific cases: push notifications, the OpenDHT proxy, bootstrap, name server, and TURN.
The first three cases where a server can be used for Jami are all related to OpenDHT, the technology allowing Jami devices to find each other on the Internet without a server. Computers use IP addresses to communicate with each other online, but it is usually dynamic and therefore changes over time. OpenDHT provides a way to identify devices on the network with a unique ID and to retrieve their IP address without knowing it beforehand, allowing them to communicate reliably even if it changes. However, it needs to run continuously in the background to keep connections to the network opened and listen to changes for alerting the user of a new call or message.
This can be a problem on mobile devices because maintaining those connections can take a toll on battery and data usage. Both Android and iOS have a built-in mechanism for delivering push notifications to them through either Google or Apple’s servers. While it is not aligned with our goal of making Jami completely distributed, it is the only way to notify mobile users while the Jami app is not in the foreground. That is why we created the OpenDHT proxy, a server that listens for changes on the OpenDHT network and sends notifications to Jami devices through Apple’s or Google’s push notification servers. No personal data is ever sent this way, not even in encrypted form. The proxy only alerts your devices that something new happened and they do the rest by retrieving the information through the OpenDHT network. It is also possible to use the proxy without push notification. However, it is less reliable because both Android and iOS may stop the app at any time.
The third case where a server is used is the bootstrap. Each device running Jami is a node in the OpenDHT distributed network. However, to establish the first connection with it, devices need to know at least one other peer beforehand. The bootstrap server is simply an OpenDHT node that we maintain and keep online at all times. Jami is configured to join the network through it when it connects for the first time. You can see this parameter in Jami’s advanced settings. The default value is “bootstrap.jami.net”. You can run your own bootstrap by following these instructions for building and running an OpenDHT node on a server.
The name server is used for resolving Jami usernames. Jami accounts all have a forty-character long unique ID, but since this is impractical for humans to remember, we created a way to associate it with a username. We store them on a blockchain to keep Jami as distributed as possible (this page offers more details on the Jami blockchain), but a server is necessary for accessing it through the Jami application. When you search for a username on Jami, the app makes a request to the name server to get the ID that is associated with it. You can see how this works by searching for any Jami username on the name server directly through your browser at this address: http://ns.jami.net/name/anyjamiusername. Jami can work without this if you directly use your friends’ IDs to reach them, but usernames make the process of adding a new contact easier. You can also setup your own name server and even run a node on the Jami blockchain.
The last case is the TURN server. It is used by Jami only in situations where a peer-to-peer connection cannot be established to relay data between users. This has already been explained in a previous article, but in summary, Jami relies on a technology called ICE to connect devices when their users communicate. When one or both users are behind a firewall, it can be difficult to establish a direct link between them, which is where the TURN server comes into play as a relay. TURN is an Internet standard and we supply one that is configured by default in Jami, but you can use your own if you want to by changing this parameter in the advanced settings of Jami and following these instructions.
While we do everything we can to free Jami from servers, in some cases they are unavoidable. However, we go out of our way to make it so our users don’t depend on us to communicate. The bootstrap, TURN, and name servers can all be configured in the advanced Jami parameters and users can use their own if they wish. Furthermore, the data that users choose to share is always transmitted through entirely peer-to-peer connections, except when a TURN server is necessary. Even then, it is fully end-to-end encrypted and never stored elsewhere than on the end-users’ devices.
By François Naggar-Tremblay – Jami product manager
