Today we are releasing the Tavern Protocol as an open specification under CC-BY-4.0. It is a decentralized, privacy-first standard that defines how any device can participate in a proximity mesh for human discovery. No single company should own the way people find each other in the physical world, and starting today, no single company does.
Why We Need an Open Protocol for Human Discovery
Social discovery has been captured by platforms. Every major service that connects strangers operates as a walled garden: proprietary algorithms, locked-in identity graphs, and business models that profit from keeping people scrolling rather than meeting. The result is a paradox where we are more connected than ever on screens and more isolated than ever in physical space.
Proximity is different. When two people share a coffee shop, a park bench, or a train platform, there is already a shared context that no algorithm needs to manufacture. The only missing piece is a signal layer that says "I am here, I am open, and here is something about me" without sacrificing privacy or requiring a specific app installed on a specific platform.
That signal layer should be a protocol, not a product. Email did not succeed because one company owned it. The web did not succeed because one browser controlled it. The next layer of human connection deserves the same openness. The Tavern Protocol is our proposal for what that layer looks like.
A protocol for finding people should be as open as the protocol for finding websites.
Five Design Principles
Every decision in the Tavern Protocol traces back to five non-negotiable principles. If a proposed feature violates any of them, it does not ship.
- Zero-Knowledge Proximity. The network must enable discovery without revealing location. A device broadcasts presence, not coordinates. No server ever learns where you are. Proximity is proved by the physical limits of Bluetooth range, not by GPS telemetry.
- Encounter-Based, Not Search-Based. You cannot query the mesh for a specific person. There is no search bar, no directory, no way to look someone up. Discovery happens only when two devices are close enough to exchange beacons. This is not a limitation; it is the core feature.
- Ephemeral Identity. Beacon IDs rotate. There is no persistent public identifier that follows you across encounters. Your identity within the protocol exists only for the duration of an encounter and is cryptographically unlinkable to past encounters by any outside observer.
- Mutual Consent. No information is revealed unilaterally. Both parties must complete the handshake before any meaningful data is exchanged. If either side drops out at any stage, the encounter terminates and both sides learn nothing about the other.
- Interoperability. The protocol is transport-agnostic at its core. The reference implementation uses Bluetooth Low Energy, but the specification defines clear interfaces so that Wi-Fi Aware, ultrasound, NFC, or any future transport can participate in the same mesh.
The Protocol Stack
The Tavern Protocol is organized into six layers. Each layer has a single responsibility and communicates with its neighbors through well-defined interfaces.
| Layer | Responsibility |
|---|---|
| Physical | Radio hardware, antenna characteristics, power management |
| Transport | BLE GATT service, advertising frames, relay fallback, mesh forwarding |
| Encryption | Key exchange, authenticated encryption, beacon ID rotation |
| Handshake | State machine governing encounter progression and mutual consent |
| Resonance | Semantic matching of interests, traits, and intent vectors |
| Application | Transmissions, Glyphs, encounter lifecycle, user-facing primitives |
Each layer can be implemented independently. A minimal device might implement only Physical through Handshake and relay the upper layers to a companion device. A full implementation covers all six.
BLE Transport Layer
The reference transport uses Bluetooth Low Energy, which is available on virtually every smartphone, smartwatch, and an increasing number of IoT devices shipped in the last decade.
GATT Service
The protocol defines a custom GATT service with a 128-bit UUID. It exposes two characteristics: one for beacon broadcast (read/notify) and one for handshake negotiation (write/indicate). This keeps the Bluetooth footprint minimal and avoids conflicts with other BLE services running on the same device.
Advertising Payload
Each advertising frame fits within 41 bytes:
Bytes 0-1 Protocol version (uint16)
Bytes 2-17 Rotating beacon ID (128-bit)
Bytes 18-19 Transmission slot hash (uint16)
Bytes 20-35 Ephemeral public key (X25519, compressed)
Bytes 36-39 Timestamp offset (uint32, seconds from epoch mod 2^32)
Byte 40 Flags (consent state, relay capability, mesh hop count)The 41-byte payload fits within a single BLE 4.2 extended advertising frame, so no fragmentation is needed. Older BLE 4.0 devices can still participate by splitting across two consecutive advertisement frames using a sequence bit in the flags byte.
Relay Fallback and Mesh Forwarding
Not every device can maintain a continuous BLE scan. When a device marks itself as relay-capable in its flags byte, it agrees to store and forward beacon frames for nearby devices that are in low-power mode. Mesh forwarding uses a simple TTL-based hop count (maximum 3 hops) to prevent broadcast storms while extending effective range in dense environments like conference halls or transit stations.
Encryption Layer
Privacy is not a feature bolted on after the fact. It is the foundation the rest of the protocol stands on.
Key Exchange
When two devices decide to progress beyond passive beacon detection, they perform an X25519 Diffie-Hellman key exchange using the ephemeral public keys from their advertising payloads. This produces a shared secret that is never transmitted over the air. Each encounter generates a fresh keypair, so compromising one encounter reveals nothing about past or future ones.
Authenticated Encryption
All data exchanged after the key agreement is encrypted with ChaCha20-Poly1305. We chose ChaCha20 over AES-GCM for two reasons: it performs better on devices without hardware AES acceleration (which includes many smartwatches and IoT boards), and it is immune to timing side-channel attacks that plague software AES implementations.
Rotating Beacon IDs
The 128-bit beacon ID in each advertising frame rotates every 15 minutes by default, derived from a device-local secret using HKDF-SHA256. An observer who records beacon IDs over time cannot correlate them to the same device without knowing the root secret. The rotation interval is configurable per-device, with a minimum of 60 seconds and a maximum of 60 minutes.
The Handshake: Six States of an Encounter
The handshake layer is a deterministic state machine that governs how two devices progress from strangers to an encounter. Every transition requires explicit action from both sides.
IDLE ──────► PING_SENT ──────► HANDSHAKE
▲ │ │
│ (timeout) (both accept)
│ │ │
└──────────────┘ ▼
REVEALED ──────► ENCOUNTER ──────► COMPLETED
│ │
(either revoke) (cooldown)
│ │
└──► IDLE ◄────────────────────────┘- IDLE. The device is broadcasting beacons but has not initiated or received a ping from this particular peer.
- PING_SENT. A resonance score exceeds the local threshold and the device sends an encrypted ping. If the other side does not respond within a configurable timeout (default 30 seconds), the state returns to IDLE.
- HANDSHAKE. Both devices have exchanged pings. The X25519 key exchange completes and a shared session is established. No personal data has been revealed yet.
- REVEALED. Both devices opt in to share their Transmission (a living broadcast of who they are right now). Either side can revoke at any point, which terminates the session and returns both to IDLE.
- ENCOUNTER. The two participants are actively in an encounter. They can exchange messages, trade Glyphs, or simply exist in shared awareness. The encounter persists as long as both devices remain in range and consented.
- COMPLETED. The encounter ends, either by mutual close or by leaving range. A cooldown period prevents the same pair from immediately re-triggering, reducing beacon noise in shared spaces.
Every state transition is logged locally with a cryptographic commitment (a hash of the session key and transition type) so that either party can later prove an encounter happened without revealing its content. This is the foundation of the Glyph reputation system.
Application Layer: Transmissions and Glyphs
Transmissions
A Transmission is a living broadcast that represents what you are about right now. It is not a profile. It is not a bio. It changes as often as you want. A Transmission might be "looking for someone to discuss the book I just finished" in the morning and "open to grabbing coffee with a stranger" in the afternoon. Transmissions are short-form (280 characters maximum), optionally tagged with interest vectors that feed the Resonance layer, and encrypted at rest on the device.
Transmissions are only revealed during the REVEALED state of the handshake. They are never broadcast in the clear. A passive observer scanning BLE advertisements sees only rotating beacon IDs and ephemeral keys, never content.
Glyphs
Glyphs are one-word reputation tokens exchanged at the end of an encounter. After an encounter completes, each participant can optionally send the other a single Glyph: a word like "thoughtful," "funny," "kind," or "inspiring." Glyphs accumulate over time and form a reputation mosaic that is controlled entirely by the encounters you have had, not by followers, likes, or algorithmic amplification.
Glyphs are bound to encounter commitments, so they cannot be forged. You cannot give yourself a Glyph, and you cannot give one to someone you have not actually encountered through the handshake. The protocol enforces this cryptographically, not socially.
Why Open Matters
By releasing the Tavern Protocol as an open specification, we are making a deliberate choice about the future of proximity-based social interaction. Any device that can broadcast and receive BLE frames can participate: smartphones running Serendipity, smartwatches with custom firmware, Raspberry Pi boards at community spaces, purpose-built hardware badges at conferences, or devices that do not exist yet.
Interoperability means that a person using Serendipity on iOS can encounter someone using an independent implementation on Android, or someone wearing a custom hardware badge that implements the protocol on an nRF52 chip. The mesh does not care about the app. It cares about the protocol.
This also means that the Tavern Protocol can outlive Serendipity the company. If we disappear tomorrow, the specification remains. Anyone can fork it, extend it, build on it. The CC-BY-4.0 license requires only attribution, not permission. We believe the protocol for human discovery should be a commons, not a competitive moat.
The mesh belongs to everyone who participates in it. The protocol is the guarantee.
What Comes Next
The full specification, including formal state machine definitions, byte-level payload diagrams, test vectors for the encryption layer, and reference pseudocode, is available at /protocol. We are also publishing a reference implementation in Rust that targets both mobile (via FFI bindings) and embedded (no_std compatible) platforms.
We invite researchers, developers, hardware makers, and anyone who believes that finding people in the real world should not require surrendering your privacy to a platform to read the spec, build on it, and help us make it better. File issues, propose extensions, challenge our assumptions. The best protocols are shaped by the communities that use them.
The Tavern Protocol is released under CC-BY-4.0. Read the full specification at serendipity.app/protocol.