virtual-radio

Open voice and video channels that behave like radio. A channel has a place, a reach and rules, and who hears you depends on where you both are and what the channel allows. Like Google Wave, it is one design spec, one wire protocol (VRP/1) and several independent implementations: a Node reference host and client, a <virtual-radio> web component, a Python client written from the spec alone, and native iOS and Android apps. It runs at radio.cartercole.net, where you sign in with Kith.

Who hears you

Channels are tied to admin regions, polygons, circles or a radius that follows a person, with separate transmit and receive distances per channel and per role. Half or full duplex, with a floor queue, priorities and preemption; push to talk or open mic. The host computes each person's rights on a channel with one exact procedure, rerun whenever an input changes: bans, roles, mutes, the device's profile, territory blocks, then position. Listening priority ranks channels like z-index, so an announcement ducks a lot channel until it ends.

An operator grants territories, each grant signed, and a holder may subdivide its own. A paying authority can block radio in its area, and every block is attributed and published. Signed channel plans hand out namespaces and number ranges the same way, and a radio checks a plan back to the operator by itself, then tunes by number.

• Speakers and monitors. Receive-only devices locked from the host to audio or video channels. On a monitor the highest-ranked live camera takes the screen.
• Files over the radio. Every radio in reach when a post goes out gets its own download ticket, and nobody else can ask for one. The sender learns who heard it and who downloaded it, unless a receiver turns receipts off.
• Edges. One host can run many edges. A radio measures the nearest and connects to the fastest, and each channel lives on the edge closest to where it is, so media is forwarded once.

Proof of place

A position is a claim, so the spec adds beacons: devices at known places that broadcast signed adverts and time how fast a client answers a challenge. An answer cannot outrun light, and light covers 150 km for every millisecond of round trip, so a fast enough answer shows the client was near. The spec is plain about what that buys. Round trips timed in software over Wi-Fi or Bluetooth rule out another continent; only ranging done in radio hardware, such as UWB, Wi-Fi FTM or Bluetooth Channel Sounding, gets down to a building. A secured locale demands proof to transmit, and the client keeps a signed receipt it can hold, reveal later or let the beacon report.

Stated honestly

• Positions are claims unless a beacon proves them, so territorial control is a policy tool on honest clients, not a barrier. A web page cannot produce a proof at all; that needs a native client.
• Private channels are not end-to-end encrypted. The host can hear them.
• State is in memory. A restart loses channels made at runtime, blocks, admin edits and files, and an edge that was down does not catch up on what it missed.
• The WebRTC forwarder is JavaScript, sized for a venue rather than thousands of viewers.
• The repository has four commits. Kith sign-in, files, multi-edge hosting and the deployment itself are in the working tree and not committed yet.