Random Beacon gathers short snapshots from a wide variety of independent live public feeds, including seismic, adoption, observatory, weather, water, air, traffic, grid, transit, and satellite sources, through a bounded server-side refresh and emits a beacon only when one or more streams qualify for the request. The app does not show the underlying feed locations, private nonce, counters, prior digests, raw buffers, or source code, and it does not ask your browser to do the entropy work.

How the Beacon Qualifies Data

• Sources are grouped into families (seismic, observatory, weather, and so on). For each request, the order in which a family's sources are tried is decided by a SHA-256 hash keyed with the private server nonce, so an outside observer cannot know which sources were consulted.
• Sources are fetched in small batches until three qualify per family; remaining sources are skipped and reported as not fetched.
• A fetched stream must supply at least 768 usable UTF-8 characters and must differ from that stream's previous fetch, compared by SHA-256 fingerprint, so frozen or cached data never contributes.
• A window position inside the stream is derived from the private nonce, the request counter, and the prior beacon digest. Three contiguous 256-character buffers are read there, and the stream qualifies only when all three buffers differ from one another.
• Only the second buffer from each qualifying stream enters the beacon calculation.
• Streams that are unreachable, too short, repeating, or unchanged since their prior fetch are reported as not used, with the reason.
• If no stream qualifies for a request, the app shows a graceful no-beacon state.

How the Beacon Is Formed

• The ingredients are SHA-256 hashes of: the private server nonce, the request counter, the previous beacon digest, the selected output language, each qualifying second buffer, and a summary of all fetch fingerprints.
• These hashes are concatenated in a fixed order and hashed once with SHA-256 to form the 256-bit beacon digest.
• The digest is expanded to 256 output bytes by repeatedly hashing it together with a fixed context label and a block counter.
• The new digest is stored and mixed into the next request, so every beacon is chained to the entire history before it.
• The output is shown as language-selected UTF-8 characters, base 16, base 8, and base 2, and each representation reports its character length.

Cryptographic Security Argument

• A secret key anchors everything. The server holds a 256-character nonce generated once by the operating system's cryptographically secure random generator, stored outside the web root and never displayed. Source ordering, window positions, and the digest itself all depend on it.
• Outputs are one-way. Every ingredient passes through SHA-256 before and during digest formation, so a published beacon reveals nothing about the nonce, the feed contents, or the server state, by the preimage resistance of SHA-256.
• Unpredictable even to a full observer. Someone who watches every public feed the beacon reads still cannot compute the output: without the nonce they know neither which windows were sampled nor the keyed inputs to the final hash. The construction behaves as a keyed pseudorandom function over fresh public data.
• No repeats, and history accumulates. A strictly increasing counter guarantees every request hashes a distinct input, and chaining each digest into the next means present outputs inherit the accumulated unpredictability of all past runs.

Privacy and Transparency

The page reports which pseudonymous buffers qualified, which did not, why, and a source page link for each pseudonym. It deliberately avoids showing raw feed URLs, raw source buffers, private state values, stack traces, or implementation code to the browser.

Prior Random Beacons

• Random Beacon Version 1 — retired; description kept for the historical record.