What changed, draft by draft

Every draft of the specification as it was published, newest first, and what it changed: what its section “Changes” says, then the sections it added, changed, renamed, removed and renumbered against the draft before it, read from the two texts (a renumbering alone is not a change). Each draft keeps its page; the specification is the current text.

Draft 0.6

Read draft 0.6 · not merged yet

What the text says

• 0.6 (2026-10-30): the draft that readies the text for 1.0; still /v1/ and schema 1, as a draft. Every 0.5 route and field stays, with the additions below; four points narrow what a document or a request may be, each marked (narrower): no server or client of this text wrote them, and the schemas, which keep schema 1 (§ 3.5), now refuse them.
  • A core with no open question (Annex C, criterion 2). What § 2 to § 14 and § 17 left open is settled:
    • JSON is I-JSON (§ 2.3, L-2.3-1): no member name twice, no unpaired surrogate, no byte order mark; integers between −(2^53 − 1) and 2^53 − 1, so size is no longer "a 64-bit integer" (narrower); a request document that is not I-JSON gives 400.
    • Times are RFC 3339 in UTC with Z, no offset (narrower), a fraction of 1 to 9 digits read by every reader; dates YYYY-MM-DD (§ 2.3, L-2.3-2, L-2.3-3).
    • Hex digests are lower-case everywhere, and a path's SHA-256 of another form gives 404 (§ 2.3, L-2.3-4).
    • Names are compared and searched by Unicode's canonical caseless match, written in NFC; ids, codes and listed values exactly (§ 2.3, L-2.3-5, L-2.3-6): q "searches names" (§ 6.2), which said neither how nor in what, keeps the apps whose name holds it, and a manifest's paths "the same when case is ignored" (§ 8.2) are compared that way.
    • Nothing is an empty page (items [], next null), never an error; an empty file has its SHA-256 and gives 416 to any range (§ 2.3, L-2.3-7).
    • Routes and queries (§ 2.4): paths exactly as written, a trailing / another path, no redirect from a server and none followed by a client (L-2.4-1, L-2.4-2); a parameter given twice gives 400 (narrower) (L-2.4-3); an empty value is absent, so that the templates this text writes (?platform=&type=) work as they are (L-2.4-4); a parameter a route does not know is ignored (L-2.4-5); HEAD on every GET route but a pairing's poll and the event stream (L-2.4-6); a request document sent as anything but application/json gives 400 (L-2.4-7).
    • Listings (§ 6.2): the order of name, added and release (the title's release, newest first, those without one last), ties by id as bytes; q of 256 bytes at most; a page_size that is not a positive integer gives 400 (L-6.2-6); total optional, exact when given; limits.page_size 1 to 1000 (§ 4.2).
    • What is missing (§ 6.3, L-6.3-2): installed may be empty, want is one or more of base, update and dlc, anything else 400 (narrower); an unknown app_id is ignored, one listed twice counts by its highest version.
    • Changes (§ 6.4): an app whose file changed is removed, then added under its new id.
    • Files (§ 6.6): If-Range honoured (L-6.6-6), as Annex B.4 relied on; several ranges may get the whole file, never multipart/byteranges (L-6.6-7).
    • Titles at once (§ 7.2): an id asked twice is answered once; no id gives 400. Saves (§ 9.1): newest first per title, the order of the titles the server's; a backup without kind is read as other.
    • Platforms (§ 4.3): an id known on several platforms gives 400 without a platform, now with its id (L-4.3-8); a client's Lantern-Platform is the SHOULD of § 2 (L-2-7), as § 4.3 now says.
    • Pairing and invitations: a code typed is read ignoring case, spaces and dashes, on the server's page and in an invitation (L-5.2-14, L-5.5-4); interval is 1 to 60 seconds. Discovery: "a few times a second" is 10 replies a second to an address at most (L-4.1-3).
    • Caching (§ 14): a server that sends an ETag answers If-None-Match with it, weakly compared, or *, by 304 with the same ETag, Vary and Cache-Control (L-14-3), and its tag changes with the document a caller would get (L-14-4).
    • Errors (§ 12): a parameter twice, a body not I-JSON; the answer to a HEAD has no body.
    • The schemas' $id are their stable addresses, https://lantern.boreale.dev/schemas/v1/<name>.json (§ 3.2), and the times, dates, integers and pairing interval above are checked by them.
  • Requests (§ 11): their states and transitions as a table, done and declined final (L-11-3); an admin declines a request, with a reason its requester reads, or marks it done, at POST <base>/v1/admin/requests/{id}, and lists every account's at GET <base>/v1/admin/requests (L-11-4, L-11-5); a request gains updated and reason; the event request at each transition, to the account and to the scope admin, with the request's user (L-11-6, § 18.2).
  • Events (§ 18.1): the events after a resumed token come before the stream's first heartbeat, which tells a client it caught up (L-18.1-10).
  • Mirrors (§ 19.2): plain HTTP on loopback too, for testing, as § 2 allows.
  • Releases (§ 3.6): each version of the text released by a tag spec-v<version>, its files, a zip, their SHA-256 sums and build provenance attestations, checked with gh attestation verify.
  • Editorial, no change to any schema: Atlas's data a client may read (§ 6.1) no longer names prices; Lantern carries no notion of price or promotion.
  • Conformance (§ 17): the suite reads every mirror with --fetch-mirrors, fills a peer's slots of downloads, and checks what 0.6 settles; the road to 1.0 says where each criterion stands, and lists the questions still open (Annex C).

Its sections, against draft 0.5

3 added, 25 changed, read from the two texts.

Added (3)

• § 2.3 Values
• § 2.4 Routes and queries
• § 3.6 Releases

Changed (25)

• § 3.2 Document schema +37 −0 words
• § 4.1 On the LAN +10 −7 words
• § 4.2 Handshake +4 −1 words
• § 4.3 Platforms +9 −2 words
• § 5.2 Pairing (feature pairing) +29 −8 words
• § 5.5 Invitations +18 −1 words
• § 5.7 Administration (feature admin) +33 −0 words
• § 6.1 App +11 −5 words
• § 6.2 Listing +93 −7 words
• § 6.3 What the device is missing +55 −0 words
• § 6.4 Changes (feature changes) +24 −0 words
• § 6.6 Files +71 −0 words
• § 7.2 Many titles at once +9 −1 words
• § 8.2 Packages and manifests +6 −1 words
• § 9.1 Backups +23 −1 words
• § 11 Requests (feature requests) +338 −3 words
• § 12 Errors +44 −2 words
• § 13 Limits +15 −1 words
• § 14 Caching +74 −0 words
• § 17 Conformance +58 −5 words
• § 18.1 The stream +24 −0 words
• § 18.2 Events +16 −2 words
• § 19.2 Mirrors +8 −1 words
• § 21.3 Reading one +29 −0 words
• Annex C — The road to 1.0 +328 −8 words

Draft 0.5

Read draft 0.5 · lantern#11 · ca10e31

What the text says

• 0.5 (2026-10-30): what happens while nobody asks, files shared on the LAN, sync, encrypted backups and static libraries; still /v1/ and schema 1, as a draft. Every 0.4 route and field stays, with the additions below; four optional families are new, each declared in features: events, peers, sync and encrypted_saves.
  • Events (§ 18): Server-Sent Events at <base>/v1/events, whose ids are changes tokens, so that Last-Event-ID resumes where changes?since= would; events library, request, pairing, save, sync and shutdown, each only to the callers that could read what it is about; heartbeats, retry, a limit of streams per token; long polling with changes?wait=, whose document gains events. The handshake's limits add heartbeat, event_streams and wait.
  • Mirrors and peers (§ 19): mirrors on apps and packages; grants, signed by a key of the server's own (peers in the handshake), with which a paired console shares the files it holds, by their SHA-256, at /v1/blobs/sha256/{hex}; peers found by discovery ("peers": true, a reply lantern peer) or DNS-SD. A client checks what a mirror or a peer gives as what its server gives; plain HTTP is allowed for them on a private network only (§ 2).
  • Sync (§ 20): wishes and what each console has installed, kept per account with the scopes sync.read and sync.write, only with the user's consent; an item merge rule by time, with If-Match for a write all or nothing (new code 412 precondition_failed), and deletion, which a console asleep cannot undo (generation).
  • Encrypted backups (§ 9.4): lantern-save-e2e-1, XChaCha20-Poly1305 in chunks of 64 KiB with a file key wrapped by a key derived from the user's save key (HKDF-SHA-256); the key carried as a recovery phrase in the pairing alphabet, or a QR code; encryption on a backup.
  • Static libraries (§ 21): the read routes as files (handshake, pages of fixed cursors, titles, homebrew, cheats, files by their SHA-256), a handshake with static, and what a client computes itself; the reference server exports one, and the suite checks one (--static).
  • Deleting an account (§ 5.7): DELETE <base>/v1/admin/users/{name}, confirmed by the name, which revokes its devices and erases its data; the suite now deletes the account it makes.
  • Discovery (§ 4.1): the reference server advertises itself with DNS-SD, with the standard library alone.
  • The schemas check the ids of every profile, the draft ones included, in every document that carries them, and a cheat set's build_id per profile.
  • A threat model for each addition (§ 16), conformance levels +events, +peers, +sync, +encrypted_saves and Lantern Static (§ 17), client guidelines B.10 to B.12, and the road to 1.0 (Annex C).

Its sections, against draft 0.4

26 added, 14 changed, read from the two texts.

Added (26)

• § 9.4 End-to-end encryption (feature encrypted_saves)
• § 18 Events (feature events)
• § 18.1 The stream
• § 18.2 Events
• § 18.3 Long polling
• § 18.4 Limits
• § 19 Mirrors and peers (feature peers)
• § 19.1 What a client checks, whatever the source
• § 19.2 Mirrors
• § 19.3 Grants
• § 19.4 Peers
• § 19.5 Finding peers
• § 20 Sync (feature sync)
• § 20.1 Consent
• § 20.2 Collections
• § 20.3 Reading
• § 20.4 Writing and conflicts
• § 20.5 Deletion and retention
• § 21 Static libraries
• § 21.1 Layout
• § 21.2 Its handshake
• § 21.3 Reading one
• B.10 Events in the background
• B.11 Sharing on the LAN
• B.12 Sync and save keys
• Annex C — The road to 1.0

Changed (14)

• § 2 Transport +23 −1 words
• § 4.1 On the LAN +46 −0 words
• § 4.2 Handshake +68 −4 words
• § 5.7 Administration (feature admin) +178 −0 words
• § 6.1 App +18 −0 words
• § 6.4 Changes (feature changes) +19 −0 words
• § 8.2 Packages and manifests +10 −0 words
• § 9.1 Backups +28 −1 words
• § 11 Requests (feature requests) +26 −0 words
• § 12 Errors +68 −5 words
• § 13 Limits +44 −0 words
• § 15 Security and privacy +78 −0 words
• § 16 Threat model +586 −0 words
• § 17 Conformance +173 −11 words

Draft 0.4

Read draft 0.4 · lantern#10 · 442cc07

What the text says

• 0.4 (2026-10-30): access and the quality of the text; still /v1/ and schema 1, as a draft. Every 0.3 route and field stays, with the additions below; § 5 becomes "Authentication and access".
  • Requirement ids (§ 3.5): every MUST and SHOULD has its id, L-<section>-<n>, which the suite's checks name. Rules the 0.3 suite already enforced as plain statements are now written as requirements (MUST), without changing their meaning; a client sends its token and signatures to the server's origin alone (§ 2).
  • Device keys and signed requests (§ 5.4, feature signatures): an Ed25519 key made at pairing, key in the pairing request; requests of a bound token signed by RFC 9421 (@method, @target-uri, authorization, content-digest; created, nonce, keyid, alg) within a skew of 300 seconds, nonces kept against replay; the poll of a keyed pairing signed; new codes signature_required, signature_invalid, signature_expired, signature_replayed (401) and key_required (400). Tokens without a key are bearer-only, which a server MAY refuse. The handshake adds auth, account.bound and features.signatures.
  • Pairing (§ 5.2): verify_complete, for a QR code a client draws, the code and fingerprint still shown next to it; the token's document adds bound and rating_cap.
  • Invitations (§ 5.5), rating caps (§ 5.6, with a table of ages per rating system) and an administration API (§ 5.7, feature and scope admin): accounts, devices, pairings waiting, invitations; 409 for an account that exists, 410 for an invitation that does not.
  • Accept-Language (§ 2.2) chooses the language of errors and of the handshake's motd; a problem and the handshake carry language.
  • Compression (§ 2.1): zstd or br, and gzip, recommended on JSON, never on files; a note on HTTP/2.
  • Deprecation and Sunset (§ 3.4); how the text changes (§ 3.5).
  • atlas on apps, titles and homebrew (§ 6.1); installed_size on apps and packages, and a client that decides what fits (§ 6.3); ratings on homebrew (§ 8.1).
  • DELETE <base>/v1/requests/{id} (§ 11).
  • A security fix to Ed25519 verification (§ 8.4, § 5.4): a verifier refuses a key or an R of small order and encodings that are not canonical, before the equation, which alone accepted a forgery (a key and an R of small order, S = 0) for about one message in 8; a server refuses a device key of small order at pairing. The reference server and the suite's reference client did accept such forgeries until 0.4; vectors/ed25519-refused.json holds the cases.
  • A server refuses a document beyond the limits without failing (§ 13).
  • A threat model (§ 16); conformance levels, the name and the badge (§ 17); test vectors (vectors/); client guidelines (Annex B).

Its sections, against draft 0.3

19 added, 32 changed, 4 renamed, read from the two texts.

Added (19)

• § 2.1 Compression and HTTP versions
• § 2.2 Languages
• § 3.4 Deprecation and sunset
• § 3.5 Changes and proposals
• § 5.4 Device keys and signed requests (feature signatures)
• § 5.5 Invitations
• § 5.6 Rating caps
• § 5.7 Administration (feature admin)
• § 16 Threat model
• Annex B — Client guidelines
• B.1 Timeouts
• B.2 Retries
• B.3 Offline, from the cache
• B.4 Downloads that survive sleep
• B.5 Several servers
• B.6 Errors and fingerprints
• B.7 A port's data, before launch
• B.8 A cold start's budget
• B.9 Clocks

Changed (32)

• § 1 Principles +12 −2 words
• § 2 Transport +34 −11 words
• § 3.1 Protocol version +1 −0 words
• § 3.2 Document schema +38 −3 words
• § 4.1 On the LAN +31 −3 words
• § 4.2 Handshake +160 −8 words
• § 4.3 Platforms +17 −4 words
• § 6.1 App +148 −4 words
• § 6.2 Listing +35 −20 words
• § 6.3 What the device is missing +97 −1 words
• § 6.4 Changes (feature changes) +20 −9 words
• § 6.6 Files +37 −0 words
• § 7.1 A title +49 −7 words
• § 7.2 Many titles at once +24 −4 words
• § 7.3 Changes +13 −7 words
• § 8.1 An entry +72 −3 words
• § 8.2 Packages and manifests +77 −6 words
• § 8.3 Installing +22 −0 words
• § 8.4 Signature +133 −0 words
• § 8.5 Routes +21 −4 words
• § 8.6 Game ports +29 −3 words
• § 8.7 Requirements +12 −5 words
• § 9.1 Backups +22 −3 words
• § 9.2 In one request +9 −9 words
• § 9.3 Resumable upload +14 −6 words
• § 10 Cheats (feature cheats) +38 −0 words
• § 11 Requests (feature requests) +44 −1 words
• § 12 Errors +134 −14 words
• § 13 Limits +37 −3 words
• § 14 Caching +11 −1 words
• § 15 Security and privacy +11 −3 words
• § 17 Conformance +323 −75 words was § 16

Renamed or moved (4)

• § 5 Authentication and access was § 5 Authentication +0 −0 words
• § 5.1 Tokens was § 5.1 Tokens +60 −9 words
• § 5.2 Pairing (feature pairing) was § 5.2 Pairing (feature pairing) +227 −43 words
• § 5.3 Pinning, at pairing was § 5.3 Pinning, at pairing +41 −5 words

Draft 0.3

Read draft 0.3 · lantern#9 · 836e131

What the text says

• 0.3 (2026-10-30): every platform Aurore runs on, and four families; still /v1/ and schema 1, as a draft. Files become § 6.6, and the sections from 7 on are renumbered: errors are § 12.
  • Platforms (§ 4.3, Annex A): a core that knows no platform, and a profile per platform. Every app, title, homebrew, save and cheat set carries platform; the handshake lists platforms; a client names its own with Lantern-Platform (or ?platform=), and the server answers for it alone. Atlas's platform names, and 3ds, vita, ps4, android, ios, windows, macos, linux and web. Profiles: the Switch's complete; the 3DS's, the Vita's, the PS4's, Android's and Linux's (one platform for computers and handhelds alike) as drafts; the others open, where a client installs nothing.
  • Apps (§ 6.1): title_id and app_id are opaque strings of the profile's form, type and format come from its lists, and version and display_version become version_code and version_name. What is missing (§ 6.3) needs a platform.
  • Titles (§ 7): titles replaces media, with developer, genres from a fixed list and tags, players on one device and online, age ratings per organisation, a localized summary and description, images and an external video, and updated; many titles in one request, and their changes.
  • Homebrew (§ 8): a new family: entries with a stable reverse-DNS id, a kind and a build to compare, packages of one file or a zip with a manifest, per architecture where a platform has several, the rules a client follows to install and uninstall them, an optional ed25519 signature whose key is pinned per id, and the updates of what is installed; dependencies on other homebrew, and the platform's own id of what is installed, which a client never lets two entries share. Game ports name their original game, engine and data folder, and the files the user supplies from their own copy, which a server never serves. Mods are out of scope. Shelves come from kind and genres (the titles' list), with free tags, and the listing filters by kind and genre. Requirements (§ 8.7) a client checks before it offers a package: requires.min (glibc, ram_mb, screen, and the profile's keys) and requires.gpu; one it cannot read gives a warning, one that fails a refusal. Architectures add riscv64; one a reader does not know is never its own.
  • Saves (§ 9): resumable uploads in chunks; Content-Digest required on a save sent in one request, and checked (422 digest_mismatch); a save's kind, slot, game_version_code, profile and platform; the handshake's limits say the sizes and how many backups are kept.
  • Cheats (§ 10): several sets per build, each with its id, source, update time and SHA-256, read by id; writing them needs cheats.write.
  • Requests (§ 11) carry platform.

Its sections, against draft 0.2

25 added, 16 changed, 3 renamed, 2 removed, read from the two texts.

Added (25)

• § 4.3 Platforms
• § 6.3 What the device is missing
• § 7 Titles (feature titles)
• § 7.1 A title
• § 7.2 Many titles at once
• § 7.3 Changes
• § 8 Homebrew (feature homebrew)
• § 8.1 An entry
• § 8.2 Packages and manifests
• § 8.3 Installing
• § 8.4 Signature
• § 8.5 Routes
• § 8.6 Game ports
• § 8.7 Requirements
• § 9.1 Backups
• § 9.2 In one request
• § 9.3 Resumable upload
• Annex A — Platform profiles
• A.1 Nintendo Switch (switch)
• A.2 New Nintendo 3DS (3ds), draft
• A.3 PlayStation Vita (vita), draft
• A.4 PlayStation 4 (ps4), draft
• A.5 Android (android), draft
• A.6 Linux (linux), draft
• A.7 Open platforms

Changed (16)

• § 1 Principles +64 −7 words
• § 2 Transport +7 −2 words
• § 5.2 Pairing (feature pairing) +5 −6 words
• § 5.3 Pinning, at pairing +1 −1 words
• § 6.1 App +127 −18 words
• § 6.2 Listing +14 −1 words
• § 6.4 Changes (feature changes) +10 −1 words
• § 6.6 Files +23 −0 words was § 6.7
• § 9 Save backups (feature saves, scope saves) +0 −70 words was § 7
• § 10 Cheats (feature cheats) +142 −29 words was § 8
• § 11 Requests (feature requests) +18 −1 words was § 9
• § 12 Errors +41 −3 words was § 10
• § 13 Limits +56 −1 words was § 11
• § 14 Caching +16 −1 words was § 12
• § 15 Security and privacy +82 −3 words was § 13
• § 16 Conformance +68 −0 words was § 14

Renamed or moved (3)

• § 4 Discovery, handshake and platforms was § 4 Discovery and handshake +0 −0 words
• § 4.1 On the LAN was § 4.1 On the LAN +3 −3 words
• § 4.2 Handshake was § 4.2 Handshake +91 −2 words

Removed (2)

• § 6.3 What the console is missing
• § 6.6 Titles and media (feature media)

Draft 0.2

Read draft 0.2 · lantern#7 · a4c1609

What the text says

• 0.2 (2026-10-30): a protocol of its own, with nothing kept for the protocols in use before it; still /v1/ and schema 1, as a draft.
  • Discovery (§ 4.1): Lantern's own datagrams on UDP 47115, a DNS-SD _lantern._tcp advertisement, and discovery as a hint only. Ownfoil's datagram and port are gone.
  • Authentication (§ 5): bearer tokens only, per device, hashed by the server, revocable, possibly expiring; HTTP Basic is gone. Pairing is required of a private server, approved on the server's side only, with codes of an unambiguous alphabet (40 bits at least) that expire within 10 minutes and are rate-limited (429 slow_down). pairing is offered to every caller, anonymous included.
  • Transport (§ 2, § 5.3): HTTPS everywhere, plain HTTP on loopback only; a self-signed key is pinned at pairing, after the user compared its SPKI fingerprint on the console and on the server.
  • Integrity (§ 6.1, § 6.6): sha256 is required on every app, Repr-Digest on every file response, and a client always checks a download before installing it.

Its sections, against draft 0.1

2 added, 12 changed, 2 removed, read from the two texts.

Added (2)

• § 5.1 Tokens
• § 5.3 Pinning, at pairing

Changed (12)

• § 1 Principles +40 −5 words
• § 2 Transport +43 −30 words
• § 4.1 On the LAN +147 −64 words
• § 4.2 Handshake +46 −17 words
• § 5.2 Pairing (feature pairing) +220 −33 words
• § 6.1 App +7 −15 words
• § 6.6 Titles and media (feature media) +2 −1 words
• § 6.7 Files +52 −7 words
• § 10 Errors +22 −5 words
• § 11 Limits +8 −0 words
• § 13 Security and privacy +54 −10 words
• § 14 Conformance +11 −3 words

Removed (2)

• § 5.1 HTTP Basic
• § 5.3 Pinning on the LAN

Draft 0.1

Read draft 0.1 · lantern#6 · fda0f52

What the text says

• 0.1 (2026-10-30): first draft.
• 0.1 (2026-10-30), from the conformance suite: wrong credentials give 401 on the handshake too, and so does an unknown token; a family at 0 answers 404, 401 or 403; sort defaults to name and release is newest first; a page_size above the limit is lowered to it; codes for 405 and 416.
• 0.1 (2026-10-30): an expired cursor or since token gives 410, one the server never gave 400 (or 410 if it cannot tell); a 416 carries Content-Range: bytes */<size>; a failure of the server answers 500 with the code internal.

Its sections

The first draft: 29 sections and parts, 2,392 words.