anon0mesh

anon0mesh provides a peer-to-peer app & infrastructure for secure, offline transaction relay and encrypted messaging without any centralized servers.

Targeting Off-Grids communities, privacy oriented groups, low internet coverage (including unstable connection) and in case of emergency.

It enables the creation of decentralized mesh networks over Bluetooth Low Energy, with confidential computation powered by Arcium for privacy-preserving Solana operations.

The protocol is compatible with both standard private P2P messaging and confidential tokens transfer over Bluetooth.

Network participation is represented by ephemeral peer identities using Nostr cryptographic standards.

Each mesh session has its own lifecycle: peers discover each other, relay packets with TTL-based flooding, and synchronize state when connectivity permits.

While developing anon0mesh, we ran into several fundamental problems that required creative solutions.

Here’s what we learned:

BLE Connectivity Issues

Bluetooth Low Energy turned out to be far less reliable than we initially expected. Connections would drop constantly, and packet loss was unpredictable. The real headache was maintaining any kind of routing consistency when nodes were essentially appearing and disappearing at random. We ended up using a flooding approach with TTL (time-to-live) counters to prevent packets from circulating forever. Each message gets a unique identifier so nodes can recognize duplicates and drop them. When retrying failed sends, we added exponential backoff basically waiting progressively longer between attempts to avoid hammering unstable connections. The system also monitors connection health and tries to reconnect automatically when peers drop off.

Signing Transactions Offline

Getting Solana transactions to work without internet access was tricky. The main issue is that transactions normally expire pretty quickly, and they rely on recent blockhashes that we obviously couldn’t fetch while offline.

There’s also the problem of coordinating who actually broadcasts the transaction once someone gets back online.

Our approach was to use Solana’s durable nonces these are special accounts that let you create transactions that don’t expire in the usual way. When someone signs a transaction offline, we store it locally with metadata about how long it stays valid. Then whichever peer reconnects first takes responsibility for broadcasting it. It’s a store-and-forward pattern, similar to how old delay-tolerant networks worked.

Adding Private Computation

We wanted to use Arcium’s confidential computing features, but that created tension with our decentralized architecture. How do you verify transactions privately when there’s no central server and peers are constantly joining and leaving?

The solution involved using Arcium’s multi-party computation infrastructure. Sensitive operations like checking balances or validating transactions happen in isolated execution environments where the actual data stays encrypted. The mesh only sees encrypted payloads and results never the underlying private keys or transaction details. This preserved both privacy and the peer-to-peer nature of the network.

Managing Ephemeral Identities

We used Nostr keypairs for peer identity, but there’s an inherent tension between authentication and privacy. If you use the same keys across multiple sessions, you become trackable. If you use completely random keys every time, you can’t establish any trusted relationships.

The compromise was session-based ephemeral keys that rotate between mesh connections. These provide anonymity for casual interactions. But peers can optionally anchor to a persistent identity when they want to establish trust with specific nodes. We borrowed Nostr’s event signing format but made the identities session-scoped rather than permanent.