The things people ask first about a network that delivers eventually, seals everything, and needs no infrastructure.
No, and that's the point. Hop is delay-tolerant: messages are eventually delivered, with a lifetime measured in hours to days, not milliseconds. It's built for the moments a live connection doesn't exist. When a path happens to be live, delivery is quick; when it isn't, the message waits and keeps seeking a way.
No. Every payload is end-to-end encrypted (X25519 + ChaCha20-Poly1305), sealed to the destination's key. Relays carry ciphertext they cannot read; they only see the routing envelope. Only the recipient can open it.
Not for device-to-device. Two phones reach each other directly, over BLE and other local radios, with no tower or server. The internet is only used, when available, to bridge distant peer-to-peer islands or to fulfill requests to the public web.
Any size. Small messages travel as a single sealed bundle; larger ones are automatically split into ordered, individually-sealed chunks and reassembled on the far side. Even images and video stream through.
The message persists for its lifetime, 24 hours by default. On the cloud backbone it waits in a durable mailbox until the recipient reappears; on the device mesh, carriers hold and re-offer it. Nothing is dropped just because the other side isn't around yet, but a bundle past its lifetime is discarded, and a carrier that runs out of custody room evicts the lowest-priority copy it holds. Set a longer lifetime if your traffic needs one.
Not unconditionally, and we won't say otherwise. Hop is at-least-once within a bundle's lifetime, with idempotency: redundant copies that an acknowledgement later cancels. Exactly-once is impossible over a lossy, partitioned network, so messages carry stable ids and recipients dedup. What is not guaranteed: a bundle whose lifetime expires before a path appears is discarded, and a carrier over its custody cap evicts the lowest-utility copy it holds. Use the delivery ACK to know, and retry what doesn't land.
No. The SDK works fully peer-to-peer on its own, over the device's local radios (BLE and Wi-Fi/LAN). The hosted backbone is optional, it absorbs carry-and-forward and bridges messages across the world when any node touches the internet. You can also run your own private backbone.
Hop is designed for background operation, periodic beaconing to stay discoverable, OS wake mechanisms on BLE events, and best-effort background refresh, with cadence the OS tunes from usage. It leans on always-on nodes (a plugged-in device, a relay) as rendezvous rather than keeping radios hot.
Payloads are confidential by default, end-to-end encrypted, and identities are public keys, not phone numbers or accounts. Delivery is untraceable-by-default: a private bundle carries no cleartext recipient. It's addressed with a per-message recognition tag only the intended recipient can match, and offline mail is parked under a rotating mailbox tag, so an on-path relay stores and forwards ciphertext it can't attribute to a pair of identities. An observer can still see envelope size and timing, and a relay learns which node pulled a given mailbox, so this narrows the metadata surface, it doesn't erase it. Billing meters counts and bytes on the envelope, never content.
Many, the network that finds a way finds more than one. BLE is the primary local bearer because it's passive: devices discover and relay through each other in the background, with no pairing, no taps, no setup. That's a deliberate trade-off, lower throughput in exchange for always-on, invisible meshing. Alongside it, Wi-Fi/LAN carries high-bandwidth local transfers and the internet relay bridges across the world. The bearer is a pluggable trait, so the same sealed bundles ride whatever's available.
A pure-Rust core (deterministic, fully testable without a radio) bound across platforms through the C ABI (sdk/hop.h) and HopContract for iOS and Android. The bearer is pluggable, BLE and Wi-Fi/LAN today, with room for Wi-Fi Aware, MultipeerConnectivity, long-range sub-GHz radios, and others.
In two tiers. The hosted services (services/*: the relay, the endpoint, the gateway, and the telemetry, account and billing daemons) are source-available under FSL-1.1-ALv2 and convert to Apache-2.0 after two years. Everything you build on, the protocol core, the SDKs, the bearers and the drivers, is Apache-2.0 outright, so you can embed or self-host any of it with no strings attached. Either way the library is free and the device does the work. We monetize the hosted cloud backbone (usage-based) and commercial licensing, never the protocol itself.