Security and responsible disclosure

Last revised 11 September 2026. No independent audit has been carried out.

No independent security audit of Yapmesh has been carried out yet. The protocol is written down and the core library is public so that one can happen. Until then, treat Yapmesh as promising, not proven.

What Yapmesh protects

  • Content of direct messages, voice notes, private files, calls and receipts. Sealed to the recipient's key. A Signal-style Double Ratchet gives forward secrecy and recovery from a compromised session key, and X3DH prekeys make the very first message to a contact forward-secret as well. Delivery and read receipts are sealed like messages, so a relay cannot tell them apart. Sender authenticity is the frame signature.
  • Content of private and fenced groups. Encrypted with the group's current epoch key; each sender has its own key chain per epoch, so one message key never unlocks the ones before it. Files are encrypted before they are cut into chunks. A member who leaves, is removed, or walks out of a fence never gets the next key.
  • Who is in a group. Membership is a signed roster; a join to a private group needs a proof from the invite secret; an admin's removal is a signed ban.
  • Who you are talking to. A 60-digit safety number, computed exactly as Signal's, can be compared in person or scanned; a changed key is shown, not hidden. A contact card forwarded by a friend arrives marked unverified until you check it.
  • Integrity of everything. Every frame is signed; a forged or altered frame is dropped before it is looked at. Every file chunk is verified against the file's Merkle root before it is stored. A "delete for everyone" is honoured only from the original sender's key.
  • Everything at rest. Threads, contacts, groups, cargo, presence, votes, blocks and reports are encrypted on the phone under a random data key wrapped by the hardware keystore. Identity keys and sessions live in Android's secure storage.
  • Internet reach, when you use it. Relays see a tag derived from keys the pair already share, rotated hourly, and a relay-side key derived fresh each day; beacons are sealed and signed; frames tunnelled through a relay are sealed like any direct frame. A relay cannot read, forge, or make a phone accept anything the normal receive path would refuse.
  • The installer (yapmesh.com edition). A build received over the mesh is installed only if its signing key matches the running app's.

What Yapmesh does not protect

  • Metadata to a radio neighbour. Any phone in range sees your hello beacon: a display name (empty while you hide), which rungs are up, the app version, the battery level, the names of your direct neighbours, and the highest presence tier you answer at. It sees that frames of a certain size move between certain keys at certain times. Hiding removes your name from the air, not your presence.
  • Traffic analysis. A relay phone sees sender key, recipient key, hop count and size for every direct frame it carries. Over time, who talks to whom is visible to anyone who stays in range or collects many phones' logs. Yapmesh does not pad, delay or mix traffic.
  • Your IP address, if you switch internet reach on. A public relay, an MQTT broker, a STUN server, a push distributor, a spool and the contact you connect to directly each learn the IP address your phone uses, and a relay can count how often a tag is active. Tor is the answer to that and is specified but not built. Everything else about internet reach is off by default and per-contact.
  • A compromised phone. Malware, a malicious keyboard, or a person holding your unlocked phone sees what you see. The app lock is a door on the phone, not encryption; messages keep arriving and being relayed while it is locked. Encryption at rest protects a copy of the files, not a running phone.
  • The Nearby room, the drop zone, SOS and open groups. These are signed and readable by everyone in range, by design. An open group's key is public.
  • A LoRa channel. Meshtastic's default channel is encrypted with a key everyone has, so it is public in practice: Nearby-room messages on it are readable by any board in range, and sealed messages show their headers to every board that forwards them. A private channel key is set in the Meshtastic app, not in Yapmesh.
  • Presence proofs and geo fences. GPS can be spoofed; Yapmesh treats a mock location as outside but cannot detect every spoof. The anchor fence (a radio link to a designated phone, plus a tap or a sound for a room or a table) is the kind to trust in a hospital or an office.
  • Hand-carried rungs. A message sent by SMS is sealed, but your carrier records that you texted that number and when. A message shared through another app is sealed, but that app sees you shared a piece of text.
  • Link previews. Off by default; on, your phone fetches the page, so the site sees your IP address. The preview is drawn from what the page says about itself and can lie.
  • Bad files. Nothing scans for viruses. The app refuses or holds files from strangers by your policy, sniffs the real type of a file before the OS opens it, warns in red about programs, scripts and archives, and throws away a blocked sender's files. A contact can still send you something harmful, and you can still open it after the second confirmation.
  • Abusive text. The filter is a word list on your phone, easily fooled and easily switched off. It is a comfort, not a control.
  • Denial of service. A phone can flood the air with valid-looking frames; quotas, the seen-cache and the mule limits reduce the damage but do not remove it. Radio jamming stops everything. A relay can drop your traffic; another relay is used.
  • Screenshots and copies. Retention, fences and "delete for everyone" remove data from phones that obey the protocol; they cannot stop a member from photographing a screen, or a phone tampered with before it left.
  • Loss of the phone. Your key lives only on the phone. There is no recovery; contacts must verify your new key in person.

Cryptography used

Ed25519 signatures; X25519 key agreement with a sealed-box construction; X3DH with signed one-time prekeys; HKDF-SHA256 and HMAC-SHA256 in the Double Ratchet; ChaCha20-Poly1305 for ratchet messages; XChaCha20-Poly1305 with a random 24-byte nonce for group boxes and for the at-rest vault; SHA-256 Merkle trees over 16 KiB chunks; HMAC-SHA256 presence tokens per 15-minute epoch and rendezvous tags per hour; secp256k1 Schnorr signatures for the Nostr relay envelope only, derived per day and never used on a Yapmesh frame. All from audited-primitives libraries; Yapmesh invents no primitives. Details are in the specification, sections 3, 4a, 5a, 7, 8, 8a, 8b and 9, and the threat model.

Current build caveats

  • Builds on the developer's desk are signed with a development key. No release-signed build has been published yet; the fingerprint that will be published here must match the app's About screen.
  • Everything marked "built, not yet field-tested" on the home page has passed unit tests and compiled into the app but has not run on real phones. As of this revision that includes internet reach, spools, the LoRa rung, Wi-Fi Aware, prekeys, safety numbers, the abuse filter and file safety.
  • The Play edition and the yapmesh.com edition are signed with different keys, so one cannot update the other.

Reporting a vulnerability

Email [email protected] with "Security:" at the start of the subject, or follow security.txt. Say what you found, how to reproduce it, and which build. You will get an acknowledgement within seven days, a fix or a public note within ninety, and a public thank-you in the changelog if you want one. You are free to publish after ninety days, or earlier once a fix ships. There is no bug bounty; there is no company. A PGP key for encrypted reports has not been published yet; until it is, a Yapmesh contact exchange in person is the only sealed channel to us.

Safe harbour. Testing against your own phones, your own relays and this website is welcome and we will not pursue it, provided you do not test against other people's phones, run denial-of-service attacks on a live mesh, or access, keep or share other people's data.

In scope: the protocol specification, the core library, the Android app in both editions, the browser client, the relay package, this website. Out of scope: the Android OS, Google Play Services' Nearby Connections, Bluetooth and Wi-Fi stacks, Meshtastic firmware, the public relays and STUN servers, and social engineering of people.