# Use Jami on a LAN Due to the distributed nature of Jami, it is possible to use it over a [LAN](https://wikipedia.org/wiki/Local_area_network) network without any Internet connection. This allows you to continue to communicate with other people in the company/building/country without global Internet access. However, some services are external, so in this document we will explain some tweaks you may need. ```{contents} :local: :depth: 3 ``` ## Bootstrapping ### What is a bootstrap server? Jami uses the [DHT](https://wikipedia.org/wiki/Distributed_hash_table) technology to find other users. So, all the users you want to contact must be reachable on the same DHT network (for example, if the Internet is split between two buildings, users in the first building will be unable to reach the second building). To enter a DHT network, one must be able to reach at least one other node. This node is called a bootstrap server; it is the entry point of the network. By default, the **bootstrap.jami.net** bootstrap server is configured, but any node in the public DHT network can be a bootstrap server (it is a classic node, generally always online). If the Internet is cut, another bootstrap server is required to create a network. On a LAN network, there are two ways to configure a bootstrap server in Jami: ### Bootstrap server settings In the advanced account settings, the user can configure multiple bootstrap servers. The usual default bootstrap server is **bootstrap.jami.net**. The **bootstrap.jami.net;your.bootstrap.tld** bootstrap servers are also valid. The IP:port of another DHT node can be specified as a bootstrap server. ### Running a bootstrap server It's possible to run a DHT node to serve as a bootstrap server for Jami clients. In this case, the bootstrap server field in the settings must be replaced by the new bootstrap server. The documentation to run a DHT node is located on the OpenDHT wiki: . ### Local peer discovery Another way is to enable peer discovery. This will announce the bootstrap server on the network by broadcasting UDP packets (like a printer). So, UDP broadcast must be supported by the network in order to work. However, this method does not need to specify an ip:port in the settings, so it can be preferred. ## TURN server Another external service is the TURN server, used as a fallback for connections if the NAT server blocks all possible connections. Generally it is the **turn.jami.net** server but can be any TURN server (we use the [coTURN](/developer/going-further/setting-up-your-own-turn-server) server). On a LAN network, it may be ignored (because there will be no NAT server), but disabling it should be unnecessary (because it will not be used if unreachable). ## On mobile (DHT Proxy) A DHT proxy is used with mobile devices to save battery by avoiding synchronization. It is generally the **dhtproxy.jami.net** proxy but can be any DHT node with the REST API enabled. However, if the DHT proxy is using push notifications, it will depend on another external service (Firebase, APN, or a UnifiedPush instance). In this case, only the UnifiedPush instance can be self-hosted. For devices with the iOS operating system, it is basically impossible to work without push notifications, as the Apple operating system will kill any application as soon as it is in the background. So you are unable to disable the usage of push notifications. However, for devices with the Android operating system, you may want to self-host your proxy (with or without UnifiedPush support), or you can disable the DHT Proxy and enable "Run in the background" in order to use your local DHT network. ## Name server Finally, the last external service you may need is a **name server**. This is used to translate addresses (the 40-character fingerprint ID) to usernames. You may not have access to the **ns.jami.net** name server, but you can self-host a name server ([name server protocol](/developer/jami-concepts/name-server-protocol)) or only use IDs.