Each QR code is a self-contained payload — no other codes needed. Scan any one with the web reader or the Android app.
Same payload as the standalone codes above, but rendered as a binary/byte-mode QR
instead of a tagdrop: URI in alphanumeric mode. The raw CBOR root array is framed
with a 4-byte "QDEF" magic header followed by the array's own leading namespace element
(a 5-byte CBOR byte string, QDEF-SPEC.md §3.5 — there's no separate discriminator item anymore,
the namespace is just the root array's first item, same as any Record's) and encoded directly
in the QR's byte mode — no Base41 encoding, no tagdrop:
prefix — which is denser but not human-typable or shareable as text.
The side-by-side comparison below shows the same content code in both carriers. The toggle above
switches all TagDrop codes page-wide between these two carriers.
A content code whose hidden override map is unlocked by entering a passphrase
— no separate key-code QR. The code embeds a random KDF salt (kdf_salt, CBOR key 38)
and algorithm hint (kdf_alg=1, CBOR key 37); the reader derives the AES-256-GCM key
via PBKDF2-HMAC-SHA256 (100 000 iterations) when prompted.
The passphrase for this example is: sunset.
A content code whose visible "cover" is a generic placeholder, plus a hidden
override map — AES-256-GCM-encrypted into the sector's content slot —
and a separate key code. Scan either one first: the content code
decodes immediately to its cover, while the override stays locked until the key code
is also scanned (in either order), per SPEC §9's "discovery, not declaration": no field
declares which content a key unlocks, so the reader tries it by trial decryption and,
on a match, replaces the cover with the hidden fields. The content code's
cache_id is random rather than content-addressed, so it can't be used as a
content-equality oracle.
Content too large for one QR is split into several equal-status
sector codes (SPEC §4.2) — there's no separate manifest
code anymore. Every sector carries the same sector_index/
sector_count and can be scanned in any order — even from
different physical locations — and TagDrop reassembles and checksums
them once complete. An optional parity sector
(SPEC §5) can also be added: a single full-XOR recovery code that
reconstructs any one lost sector, so a damaged or missing code doesn't
sink the whole drop.
A paper groups multiple files under one manifest. Scan the manifest QR first, then the file QRs in any order.
A paper manifest can reference raw QR files — codes whose content sits
directly in the QR symbol with no TagDrop encoding (a plain URL, vCard, Wi-Fi credential,
etc.). The manifest declares each raw file's slug, mime_type, and
the SHA-256 file_id of its raw bytes; the app recognises and caches these when
you scan each code. Files already cached from a previous scan are surfaced immediately when
you open the manifest, without re-scanning.
A paper of text/markdown pages — a cover/table-of-contents and three
chapters — that link to each other with ordinary relative links and share one
style.css (SPEC.md §7's stylesheet convention). Scan the manifest, then
every file, then open index.md and tap through: about as close to an
e-book as a sheet of paper gets.
Three independent paper manifests — one per "stop" — each with its own icon and
related hints to its neighbours. Useful for testing what happens when multiple pages
are scanned at different locations: separate map pins, shared collection grouping, and trail
navigation hints.
The QDEF (QR Data Envelope Format) specification that TagDrop's wire format is built on — Record framing, Type IDs, Compress/Split wrappers, namespace rules, and magic-header framing for byte-mode QR carriers. Raw source: QDEF-SPEC.md.