This directory contains a minimal Python implementation used to build example Lumions for the functionality ladder described in the RFCs. The demo is entirely LLM-generated code. Mindless implementation of an RFC is a great use case for LLMs, because ambiguity will trip them up where a human may well make the same logical assumption as the RFC writer. The challenge is to write the Lumion RFCs such that it is possible to write a strictly conformant implementation. If we get it right, all we need to do is tell the LLM to write a conformant implementation. There were plenty of failures to get here.

The demo requires Python 3 and the cryptography package.

The implementation writes two files for each Lumion:

• *.lumion: the binary Lumion encoding.
• *.b64url: the optional unpadded base64url text form from the encoding RFC.

We supply the prompt used to generate the Python implementation in this directory, adjust to suit and see if you get an interoperable program in the language of your choice.

Demo Scenario

The ladder uses a small employee record for Alice in a research department. The same plain application data is reused across the rungs, with one Lumion property added at a time.

The pretend record is:

Field	Meaning in the scenario	Lumion feature demonstrated
message	A minimal text value, signed row	Shows the smallest signed Lumion body.
name	Employee display name, Alice	A clear field that remains visible in most examples.
department	Employee department, research	Another ordinary clear field, useful for multi-part examples.
salary	Salary value, first 100000, later 110000	Demonstrates redaction and fixed writer-set updates.
employee_id	Stable employee identifier, E123	Demonstrates an immutable field.
private_note	Confidential note, private note	Demonstrates encrypted content covered by the Lumion name.

Reading the ASCII Art

The ASCII-art output is a pretty-printer for the prototype encoding.

The top-level lines mean:

Label	Meaning
Lumion header	The fixed Lumion magic string, encoding version, and total byte length.
name	The carried Lumion name, shown in unpadded base64url. A verifier recomputes this.
signer	The Ed25519 public key that verifies the body signature, shortened for display.
body	The signed version count and optional prior Lumion name.
root	The hash over the ordered part hashes.
signature	The body signature, shortened for display.
parts	The addressable fields/field-groups that can be redacted, encrypted, or governed.

Each part line shows:

Label	Meaning
kind	The scenario field name, such as salary or employee_id.
state	clear, encrypted, or removed. Removed means the content is gone but its part hash remains.
rule	open, writer-set, or immutable.
writers	Number of writer keys in the fixed permitted writers.
descriptor	The signed part descriptor, unchanged by redaction and shortened for display.
part hash	The part hash, shortened for display.
clear bytes	Disclosed content for a clear part.
encrypted bytes	Ciphertext for an encrypted part. The plaintext is not printed.

To run the demo:

python3 demo/lumion_demo.py selftest

The Entire Lumion Functionality Ladder

python3 demo/lumion_demo.py ladder --out demo/out --asciiart

--asciiart or -asciiart prints an ASCII-art view of each Lumion as it is created. The ASCII art shows the Lumion header, carried name, signer, version/prior link, part-hash root, signature, and part slots.

Use --seed for byte-identical generated output across runs with the same seed:

python3 demo/lumion_demo.py ladder --out demo/out --seed 1

One Rung At A Time

1. Signed Row

python3 demo/lumion_demo.py signed --out demo/out --asciiart

Creates 01-signed-row.lumion: one signed body with one clear part. This is the base integrity/authorship property.

2. Named Row

python3 demo/lumion_demo.py named --out demo/out --asciiart

Creates 02-named-row.lumion: a signed row with a content-derived carried name. The ASCII art shows the name and the part-hash root that feeds it.

3. Versioned Row

python3 demo/lumion_demo.py versioned --out demo/out --asciiart

Creates 03-versioned-row.lumion from 02-named-row.lumion. The version is incremented and the prior Lumion name is signed into the new body.

4. Redactable Row

python3 demo/lumion_demo.py redactable --out demo/out --asciiart

Creates two Lumions:

• 04-redactable-full.lumion: name, salary, and department are present.
• 04-redactable-without-salary.lumion: salary is removed.

The two files have the same Lumion name and signature. The redacted salary slot keeps only its part hash.

5. Confidential Row

python3 demo/lumion_demo.py confidential --out demo/out --asciiart

Creates 05-confidential-row.lumion with one clear part and one encrypted part. The ASCII art shows ciphertext bytes, not plaintext. The prototype verifies that a holder of the content key can decrypt the encrypted part.

6. Access Rules

python3 demo/lumion_demo.py access --out demo/out --asciiart

Creates two versions:

• 06-access-rules-v0.lumion: salary has fixed permitted writers, and employee ID is immutable.
• 06-access-rules-v1.lumion: salary changes under the permitted writer.

The command also constructs a bad update signed by the wrong writer and verifies that it is rejected.

ASCII Art For any Existing Lumion Files

python3 demo/lumion_demo.py inspect demo/out/04-redactable-without-salary.lumion --asciiart

For convenience, a file path without an explicit command is treated as inspect:

python3 demo/lumion_demo.py --asciiart demo/out/03-versioned-row.b64url

Both binary *.lumion files and base64url text *.b64url files can be inspected.

Without --asciiart, inspect prints a compact one-line-per-part summary:

python3 demo/lumion_demo.py inspect demo/out/06-access-rules-v1.lumion

Notes

The demo uses a deterministic demo signing key so that examples are easy to run, but salts, encryption nonces, and generated content keys are fresh on each run by default. Names therefore change between runs for Lumions whose named content includes fresh randomness. Passing --seed makes those generated bytes deterministic for interoperability checks.