# An exploration of Wi-Fi Aware for Bitchat (and other ad-hoc networks)

*Thanks to Andrija Novakovic, Kobi Gurkan, and Natalie Mullins at [Bain Capital Crypto](https://baincapitalcrypto.com/), as well as [chee](https://chee.party/) and [amplice](https://x.com/amplice_eth) for discussions and feedback. This work was my final research project at Bain Capital Crypto.*

Bitchat is an open source peer-to-peer mesh communication network started in the summer of 2025 by Jack Dorsey. It's available on iOS, Android, and MacOS. Others have explored beyond this, with a [terminal](https://github.com/ShilohEye/bitchat-terminal) client and a self-powered [ESP32-based mesh relay node](https://x.com/markkasaurus/status/1949971774579343756?s=46&t=hFDA11cDUM5ttic0XRCSzA). In theory, Bitchat enables cross-platform peer-to-peer messaging even when there's no cellular or Wi-Fi network available. In practice, it's [not proven to be reliable](https://primal.net/saunter/testing-bitchat-at-the-music-festival) in an offline environment. However, I believe it could be, and it's clear that the team agrees and is actively working toward that end.

I haven't seen a discussion of [Wi-Fi Aware](https://www.wi-fi.org/alternative-topologies) in the docs or repo discussions*, so the purpose of this note is to initiate a discussion of Wi-Fi Aware as a potential transport for Bitchat and other mobile ad-hoc networks (MANETs) with some reasons I think it's worth considering, along with the results of my preliminary investigation. I've published a separate guide for cross-platform implementation of Wi-Fi Aware [here](https://grjte.sh/cross-platform-wifi-aware).

*\*Note: since first drafting this, an [issue proposing Wi-Fi Aware support](https://github.com/permissionlesstech/bitchat/issues/907) has been opened in the Bitchat repo, but there has been no discussion yet.*

## For a robust ad-hoc network, Bluetooth (probably) isn't enough

Bitchat's offline messaging is enabled by its use of a Bluetooth Low Energy (BLE) mesh, built using the Generic Attribute Profile (GATT) specification, the most common protocol for sending and receiving short pieces of data over a low-energy link.

As a transport, Bluetooth has a number of advantages. It's nearly ubiquitous on mobile phones and laptops, the devices that users turn to for messaging. It's also available on a huge number of IoT devices, making it easy to expand mesh coverage with fixed (non-mobile) devices that act as message forwarders. BLE in particular is optimized for low power expenditure. For example, the batteries of sensors that use BLE to communicate can last anywhere from 6 months to several years. All of these benefits come together to offer a transport that, in the presence of many devices running the service, could support a reliable wide-area p2p mesh for messaging.

Unfortunately, Bluetooth on mobile phones tends to have a short range of roughly 10-30 meters, which means that in order for a network of predominantly mobile devices to be sufficiently well-connected that messages will make it from their source to their destination, there needs to be a very large number of devices connected to the network throughout the target coverage area. This is perhaps one reason that Bluetooth mesh networks continue to have relatively low adoption, despite a number of them existing over the years ([Firechat](https://en.wikipedia.org/wiki/FireChat), [Bridgefy](https://bridgefy.me/), [Briar](https://briarproject.org/), etc.)

The solution, which the Bitchat team has already begun exploring (as well as other teams like Bridgefy and Briar), is to add support for other transports. With its ubiquity and low power requirements, BLE makes an excellent primary transport to form the backbone of the mesh. Bitchat has added [Nostr](https://nostr.com/), which enables global transmission via peer-to-peer relay in the presence of an internet connection. Bridgefy has added Wi-Fi Direct, which enables p2p Wi-Fi connections, but Wi-Fi Direct has the downside of inefficient device discovery. Wi-Fi Aware, on the other hand, was specifically designed for efficient peer discovery, even when devices are on the move.

**I propose that Wi-Fi Aware, a standard supported by Android since 2017 and newly adopted by Apple for iOS (2025), could be a powerful additional transport for extending the range and improving the throughput of an open p2p mesh network like Bitchat in the absence of internet connectivity.**

## Wi-Fi Aware as a secondary transport for ad-hoc networks

Wi-Fi Aware is a standard by the Wi-Fi Alliance for creating direct p2p Wi-Fi connections between two peer devices using the [Neighbor Awareness Networking (NAN) protocol](https://www.researchgate.net/publication/275673964_Enabling_always_on_service_discovery_Wifi_neighbor_awareness_networking). It's designed for low-power peer discovery between mobile devices, so in this sense it's well-suited to an ad-hoc mobile network where users (and their devices) are expected to be moving around and connecting to nearby devices on an "ad-hoc" basis. After discovery, a device can open direct peer-to-peer Wi-Fi connections with anywhere from 2 to 8 peers.

### 5x range and 100x throughput for the same power expenditure?

A good [overview of Wi-Fi Aware](https://www.ditto.com/blog/cross-platform-p2p-wi-fi-how-the-eu-killed-awdl) by Ditto details the historical development of peer-to-peer Wi-Fi and the arrival of cross-platform support for the framework. It also includes comparisons between Wi-Fi Aware, Bluetooth, and AWDL (which is essentially Apple's closed-source precursor). My only disagreement with their numbers is in the effective range of BLE for mobile devices. Since Wi-Fi Aware is mainly supported on mobile phones at the moment, this is the most relevant comparison (especially in the case of MANETs), and in general Bluetooth range on mobile devices is around 10-30m, which is consistent with the rough tests of Bitchat that I ran, both indoors and outside.

#### range

The range for discovery and connectivity with Wi-Fi Aware is typically ~50-100 meters and can be over 100 meters in open air, which is more than 5x the typical range that phones can achieve with Bluetooth Low Energy (~10 meters). Both technologies depend on line-of-sight, and the signal significantly weakens when there are obstructions, but the unobstructed range of Wi-Fi is much larger.

We did some rough tests in the Bain Capital Crypto offices in NYC to get a sense of the range comparison between BLE and Wi-Fi Aware. (I've listed the ranges below in feet because the building plans I used to estimate distances were in feet.)

While testing unobstructed outdoor line-of-sight messaging on a balcony using Bitchat (with BLE as the transport) and a modified version of Bitchat that connected over Wi-Fi Aware, the BLE connection capped out just shy of 30ft, while the Wi-Fi Aware connection easily succeeded along the full 112ft length of a balcony. Additionally two devices were able to connect from the 10th floor balcony to the sidewalk across the street (estimated ~150ft).

Indoors, the Bitchat range over Bluetooth LE was similarly small, capping out below 30ft, while the Wi-Fi Aware range succeeded both directly down a ~130ft hallway as well as across ~110ft through a wall.

After verifying that the range of the Wi-Fi Aware implementation between our devices was reliably ~4-5x that of the BLE version, we didn't do further testing to explore the full limits (theoretically higher than what we validated), but it would be interesting to see the results of more rigorous tests.

#### throughput

As noted by Ditto, Wi-Fi Aware can offer data throughput that is nearly 100x that of BLE. On Wi-Fi 5 hardware, throughput is in the range of 100+ Mbps, and on Wi-Fi 6 it goes up to 250+ Mbps. In comparison, BLE sits at a max of "max ~1.36 Mbps app" with a much more typical value of "0.2–0.5 MB/s."

#### power expenditure

One of the most interesting things I found in my explorations, especially in relation to an ad-hoc network like Bitchat, is that during my tests the power expenditure for device discovery was similar between the two transports.

Both Bluetooth Low Energy and Wi-Fi Aware are optimized for power efficiency. However, BLE is the connectivity-technology of choice for low-powered devices, so I expected it to perform significantly better.

It's hard to find good reference data, so to get a rough benchmark, I compared the regular Bitchat implementation with one in which I replaced the BLE mesh with a Wi-Fi Aware mesh, and then I ran both versions on a Google Pixel 7 and recorded it for 5 minutes.

To keep rough parity, I did the following for both tests:
1. I kept Bluetooth and Wi-Fi turned on.
2. I kept the Bitchat app open and the screen active. (Bitchat has done optimizations for running the app in the background using a power manager module, and I did not implement an equivalent one for the Wi-Fi Aware version)

I also considered it worthwhile to look at the discovery and messaging phase separately.

##### Discovery

For discovery, Bitchat (BLE) operates by active scanning, while my forked Bitchat (Wi-Fi Aware) uses the built-in optimized NAN discovery mechanism of Wi-Fi Aware.

Surprisingly (to me at least), in two separate tests, the power expenditure came out to be nearly equivalent across the two implementations.

Bitchat over BLE discovery trace:

Bitchat over Wi-Fi Aware discovery trace:

Of course, it's possible that there are more performance optimizations available with BLE than with Wi-Fi Aware, and it's also clear that turning off Wi-Fi completely (in the Bluetooth case) would save power, but these rough benchmarks suggest it could be worth investigating further.

##### Messaging

To get a rough feeling for comparison when devices are actively connected, I took a debug trace on the same Pixel 7 while actively messaging with another device within the bitchat app.

In this case, we see a significant difference in the power expenditure of the two devices, as expected. The energy used by the Wi-Fi Aware implementation was about 4.25x that of BLE, and you can see the majority of that shows up in the CPU Big, Cellular, and WLAN consumption in particular.

Bitchat over BLE chat trace:

Bitchat over Wi-Fi Aware chat trace

#### comparison summary

As noted, the Bitchat (BLE) version had been somewhat optimized, while the Wi-Fi Aware version was not optimized at all. This was also an incredibly rough-grained test. However, it can indicate an approximate expectation of comparative power expenditure between the two technologies.

What I found interesting is that given the near-parity in the cost of peer discovery, there are likely many situations where the power expenditure trade-off during active messaging for the sake of ~5x (or more) discovery range and ~100x (or more) bandwidth is worth it. This is especially true given the increasing capabilities of mobile phones, which are no longer the low-powered devices they were when phones began supporting Bluetooth in the early 2000s.

### Support is lacking, but that's ok (and it's improving)

Support for Wi-Fi Aware is much, much lower than for BLE, though it has just increased dramatically with Apple's recent adoption of the technology for iOS devices. Now, any iPhone 12 or newer running iOS 26.0 (or newer) supports Wi-Fi Aware version 4. On the Android side, Wi-Fi Aware has been supported for over 8 years, nearly since Wi-Fi Aware version 2 was released, although manufacturer support varies.

However, with Bluetooth as the primary transport, as in the case of Bitchat, inconsistent support doesn't present the same challenges that it would for a purely Wi-Fi Aware-based application. Instead, Wi-Fi Aware can act as a supplemental transport, when available, to extend range and increase bandwidth.

Moreover, we can hope that Apple's move indicates a change in the winds, especially if Wi-Fi Aware begins to get more adoption and use. Perhaps in the future we will see a growth in support from Android phone manufacturers, and perhaps support will even move beyond mobile phones to tablets, laptops, or IoT devices. I've discussed [cross-platform developments](https://grjte.sh/cross-platform-wifi-aware) in more detail separately.

## Adding Wi-Fi Aware to Bitchat: the easy win

The simplest improvement to Bitchat using Wi-Fi Aware would be to simply start using it for direct messages when the two peers are within Wi-Fi range and both devices support Wi-Fi Aware.

In this case, when the user enters the direct message screen, the device can check to see if it has already discovered the other peer on Wi-Fi Aware. If so, the two devices can negotiate to open a Wi-Fi connection using a passphrase computed from their keypairs (already shared during peer announcement). This opens a high-bandwidth encrypted connection between the two peers, and nothing more is required.

Direct messaging is likely to be a case where increased bandwidth is most impactful, if users want to have an active conversation or share a significant number of pictures, video, and voice messages.

To demonstrate the idea and approach, [I've implemented a working prototype](https://github.com/grjte/bitchat-android) in a fork of Bitchat Android.

## Challenges to using Wi-Fi Aware in an ad-hoc network

As I've alluded to, there are a variety of challenges to using Wi-Fi Aware in a the context of a mobile ad-hoc network. They're not necessarily insurmountable, but solving them requires careful consideration and design. The three main challenges are:

1. Current cross-platform (in)compatibility
2. Pre-pairing requirements for devices (iOS)
3. Asymmetric connectivity and capability

I present them in more detail below, and a [separate guide](https://grjte.sh/cross-platform-wifi-aware) (also linked previously) discusses implementation details related to these challenges on both iOS and Android.

### Challenge 1: cross-platform (in)compatibility

The first challenge is that despite the fact that both the iOS and Android developer APIs now support Wi-Fi Aware version 4, the hardware-level support is not commensurate. iOS supports Wi-Fi Aware version 4 (and only version 4) on iPhone 12 and newer running iOS version 26.0+, as well as iPads from the last several years. Unfortunately, while many Android phones now support Wi-Fi Aware version 3, I haven't been able to find an Android device which supports the pairing requirement for version 4.

This does not necessarily kill the case for Wi-Fi Aware. For Android, Wi-Fi Aware seems to be blocked by required updates to the chip firmware (the Android API and Hardware Abstraction Layer updates have been made). Hopefully hardware manufacturers will catch up to Apple at some point. The other updates in the stack and the history of Wi-Fi Aware spec adoptions suggest we'll see this in the next couple years.

In the meantime, Android devices can connect to each other using the older supported version of Wi-Fi Aware, and iOS devices can connect to each other. Wi-Fi Aware connectivity between mobile devices on the same OS could still act to increase discovery range or offer improved bandwidth across parts of the mesh, if with a reduced effect size compared to the potential of a cross-platform implementation.

Hopefully this challenge will be resolved by improved device support in the near future.

### Challenge 2: device pairing

Pre-pairing devices, as required by Apple's implementation, presents a significant challenge to the usefulness of Wi-Fi Aware in the setting of an ad-hoc network like Bitchat.

However, for a network aiming to be more local in scale, perhaps within a community that may have in-person pairing opportunities, it's not insurmountable. The pairing only needs to be done once, so for individuals who already know each other or spend time in person, it's not hard to facilliate one-time pairing for improved direct messaging bandwidth and range.

Even in the Bitchat setting, if a group of friends pair their devices before going into a crowd, then not only could they benefit from stronger connectivity and higher bandwidth messaging amongst themselves, but their connections could act to strengthen the range and connectivity of the larger mesh.

With Bluetooth as the backbone, smaller local groups could connect over Wi-Fi Aware and then be connected to other similar Wi-Fi Aware networks by other transports.

This challenge is the most limiting of the three, but it's specific to iOS (either iOS-iOS or the future iOS-Android case), and it doesn't remove the utility of Wi-Fi Aware as a transport in these settings. It simply requires a bit more coordination and prejudices the use of stronger connectivity towards a group that is pre-approved by the user.

### Challenge 3: asymmetric connectivity and capability

This challenge is perhaps the most interesting and requires the most research to overcome.

After peer discovery, devices connect to each other by opening a NAN Data Path (NDP) connection. NDP connections are the full Wi-Fi connections that are created between members of the Neighbor Awareness Networking (NAN) cluster after peers discover each other and negotiate to open a server-client network.

The connection, once opened, is a bi-directional connection (as opposed to the asymmetric nature of BLE's GATT spec where the "server" and "client" have to execute differently during messaging), but when the devices open these connections one of them must act as a server and the other must act as a client, and unfortunately these roles are subject to device limitations.

Each device is only allowed to have one open "client" connection. In the early support for Wi-Fi Aware, devices could only support 2 concurrent NAN Data Path (NDP) connections total. In these cases, each device could have one server connection and one client connection. In newer phones, devices support up to 8 NDP connections. As many as 8 of these can be connected to the device's server socket, but every device is still restricted to a single client connection.

In other words, while devices can theoretically offer much higher connectivity, it's impossible to form a mesh because of the restrictions on the connection type. At best, a spanning tree could be formed.

Connectivity is limited by:
1. The inability of a device to connect as a "client" to more than one peer at a time
2. Old devices that support a maximum of 2 concurrent NDP connections

In theory, clusters of devices could be formed, where a device with the capability for 8 NAN Data Paths acts as a hub, and the connected devices use their available "server" connection to link across to another cluster. Maximizing connectivity for this specific set of capabilities and restrictions is a direction for further research.

A final interesting note is comes from Ditto's overview which noted that Wi-Fi Aware version 5 might add primitives for mesh networking, which could simplify this situation significantly.

> **Extended Mesh Networking:** Currently, Aware focuses on finding peers and setting up links; v5.0 might add more mesh networking primitives – e.g., forwarding data through intermediate nodes or coordinating groups of devices more intelligently. This could turn clusters of phones into true mesh networks for group connectivity without infrastructure.

## Conclusion

Despite the challenges and drawbacks outlined above, such as cross-platform incompatibility and lack of support, the Wi-Fi Aware framework offers an opportunity to improve the connectivity of offline mobile ad-hoc networks. It's interesting to consider both in the case of a small private group, such as a family sending messages during a crowded event, and in the case of an open global mesh, such as Bitchat, especially given the private messaging and group messaging layers that Bitchat provides.

We'd love to chat to anyone exploring these problems in ad-hoc networking and p2p communications or related topics of local networks/data/compute. If this is you, please reach out to [@grjte on X](https://bsky.app/profile/grjte.sh) or [@grjte.sh on Bluesky](https://bsky.app/profile/grjte.sh) or to Bain Capital Crypto by [email](https://baincapitalcrypto.com/contact/), [Bluesky](https://bsky.app/profile/baincapitalcrypto.com), or [X](https://x.com/BainCapCrypto).