Imagine fifty people in a bar. Each of them has a phone in their pocket. They all want to use a social app to see who else in the room is up for a conversation.
The way every dating and social app works today is: every one of those fifty phones sends a request to a cloud server — somewhere in Virginia or Oregon or Ireland — that says "I am in this bar, here is my location." The cloud server then sends back "here are the other 49 people who also told us they are in this bar." If anyone sends a message, that message also goes through the cloud — phone A talks to a data center, the data center talks to phone B. The two phones are six feet apart, and the bytes between them take a 6,000-mile round trip.
Mesh networking is the opposite arrangement. The phones talk directly to each other. The cloud server, if it exists at all, only handles things the phones genuinely can't — identity verification, signup flow, push notifications when the app isn't open. The conversation between two people in the same room is a literal radio signal that travels across the room.
This isn't a futuristic idea. The plumbing has been on every phone for fifteen years. What's new is that the platforms (Apple, Google) have started exposing it as a real API that consumer apps can use.
The plumbing: BLE and Wi-Fi Aware
Two protocols matter:
- Bluetooth Low Energy (BLE). The older one. Ships on every iPhone and Android phone made in the last decade. Range is about 30 meters line-of-sight, throughput is around 1 Mbps. Fine for small messages, advertising presence, exchanging keys. Not great for media.
- Wi-Fi Aware (sometimes called Neighbor Awareness Networking). The new one. Apple shipped first-class API support in iOS 26, and Android has had it since version 8 (under-used). Similar range to BLE but much faster — around 150 Mbps. Good for photos, video, anything chunky.
Most mesh-first apps use both. BLE handles discovery and the initial cryptographic handshake; Wi-Fi Aware kicks in once two phones have agreed to talk and there's real content to move.
The radios are doing a thing called "ad-hoc networking." There is no router, no access point, no SIM card. Two phones notice each other's radio signals, agree on a protocol, and exchange bytes. The internet is not involved. Your carrier is not involved. The cloud is not involved.
Why this matters for social apps specifically
Privacy conversations about messaging apps usually focus on encryption. Are the messages end-to-end encrypted? If yes, the conversation is safe — only the sender and recipient can read it. This is true and important, and it's why Signal and iMessage are so much better than ordinary SMS.
But end-to-end encryption only protects the content. The metadata — who talked to whom, when, where they were physically located — still passes through the server. The server doesn't know what you said, but it knows you said something. To whom. At 9:42pm on a Tuesday. From a venue at 123 Main Street. That metadata is a complete behavioral dossier even without the message contents.
End-to-end encryption protects the message. Mesh networking protects the existence of the message.
In a dating or social app this matters more than almost anywhere else. The metadata is the product. A list of who pinged whom at which bar, on which night, in what order, with what response times — that's a behavioral graph richer than anything Tinder explicitly asks you to fill out. Even if the server is operated by people who are trying to be ethical, that data exists, which means a future subpoena, breach, acquisition, or pivot can reveal it.
If the messages literally never reach a server, none of that data exists to be revealed.
The hard parts (what we're spiking)
Mesh networking is not a finished, drop-in product. It's a research-grade engineering problem dressed up as a feature. The hard parts:
Discovery without a beacon
How do phones find each other without a server announcing them? BLE advertising packets help, but a naive implementation broadcasts a stable ID that turns into a passive-tracking vector — anyone with a BLE scanner could log "phone X was here at time T." We rotate ephemeral session IDs on every app launch so the broadcast can't be used to follow someone across venues.
Identity that survives reinstalls
If someone gets blocked, they shouldn't be able to reinstall the app and reappear. But the phone's MAC address rotates on every Wi-Fi join, and the BLE radio rotates its ID too. We use a phone-hash plus a photo-embedding-derived identity to make blocks survive reinstalls without needing a stable phone identifier.
Encryption over an untrusted radio link
BLE has been broken many times. Pairing-mode eavesdropping, KNOB attacks, BlueBorne — the protocol's security history is a list of CVEs. So we don't rely on BLE's own encryption; we run libsignal's X3DH key agreement and the Double Ratchet algorithm on top of BLE, the same primitives Signal Messenger uses. The radio is treated as an untrusted transport. Whatever it sees is ciphertext.
Routing when phones move out of range
A bar is a fluid network — people walk in, walk out, walk between rooms. Messages need to be deliverable even if the recipient stepped outside for a smoke. The cloud server, in mesh networking, still has a small role: it stores ciphertext for offline recipients and delivers it the next time they come online. It can't read anything — it's just a relay for encrypted blobs.
What this changes for users
When mesh is the default transport, three things change at the user level:
- You vanish when you walk out. No "Amar was at this venue last Tuesday" record exists, because the only people who knew were the phones in the room, and they don't remember you after the radio signal stops.
- No social graph by default. The "who knows who" map that every centralized social app maintains as its core asset literally cannot exist when the conversations never touched the server. A breach can't leak what was never collected.
- Performance gets weirdly good in the place that matters. Messaging the person across the bar via radio is faster than messaging them through Virginia. Latency drops to single-digit milliseconds. The app feels different when distance doesn't cost time.
What it looks like in Maybe
We are not all the way there yet. Today's v1 uses GPS-based proximity to determine "is this person in the same room as me." Messages are routed through a server, but encrypted end-to-end with libsignal. The mesh layer is the hardest engineering problem in our plan, so we're spiking it from day one — but the first beta will ship without it.
The roadmap:
- v1 (Summer 2026 beta): GPS proximity. Server-routed E2E messages. Ephemeral session IDs.
- v1.5 (late 2026): BLE discovery. Server still routes messages, but the "who is here" set comes from radio, not GPS.
- v2 (2027, iOS 26+ required): Full mesh. BLE for handshake, Wi-Fi Aware for messages. Server reduced to identity directory + offline-message relay.
The pace is intentional. Each layer of the architecture has to be solid before the next one ships, because the trust model only works if every link is.
The future
It's worth saying explicitly: mesh networking is going to be the next ten years of consumer apps. Apple shipping Wi-Fi Aware as a first-class API in iOS 26 is the platform-level move that makes this category viable. Google will follow. Once one social app does this well, the rest will have to — because users will notice the difference.
The companies that built their business on collecting behavioral data will resist this for as long as they can, because the data-broker line item on their P&L disappears when the messages stop passing through their hardware. They will frame the resistance as "we need centralized data for safety" or "decentralization is bad for users" — variations on the same protectionism.
That's fine. The new apps will eat them.