# FLUX WIKI — COMPLETE FIELD MANUAL
flux.dantesisofo.com/wiki/
FLUX_WIKI_v1.0
Generated: 2026-05-12
---
# WHAT IS FLUX
FLUX is an open photographic protocol for publishing life in chronological sequence.
Photographs are preserved in the order they were made.
The archive is the artwork.
---
## CORE SENTENCE
> You cannot make the same photograph twice.
This is the foundational statement of FLUX.
The light changes.
The body changes.
The street changes.
The photographer changes.
The world is always in flux.
Each photograph is a fragment of becoming.
Each issue is a record of movement through time.
---
## WHAT FLUX IS NOT
FLUX is not a portfolio.
FLUX is not a social platform.
FLUX is not a feed.
FLUX is not a gallery.
FLUX is not about selecting the best photographs.
FLUX is a protocol.
A protocol runs regardless of how the photographer feels on a given day.
A protocol does not have aesthetic preferences.
A protocol produces output and moves on.
---
## THE SYSTEM
FLUX collapses the distance between making, organizing, publishing, and archiving into a single repeatable workflow.
The photographer walks.
The photographer photographs.
The system does the rest.
The archive grows continuously.
Each session adds to the record.
Nothing is reorganized.
Nothing is backdated.
The sequence is permanent.
---
## PHILOSOPHICAL FOUNDATION
### Heraclitus
The root of FLUX is Heraclitus:
> You cannot step in the same river twice.
Applied to photography:
> You cannot make the same photograph twice.
The photographer enters the stream of becoming.
Each walk is different.
Each frame is unrepeatable.
Each day is new.
### Becoming and Being
The world is always becoming. Everything moves.
When photographing:
- time slows down
- self-consciousness disappears
- awareness heightens
- the body becomes present
- the senses open
So FLUX contains a paradox:
> The photographer enters becoming in order to experience being.
The world changes. The photograph preserves the encounter.
### Life Affirmation
FLUX says yes to:
- the street
- chaos
- imperfection
- movement
- repetition
- ordinary life
- daily practice
- walking
- seeing
- becoming
FLUX rejects perfectionism.
It affirms life as it is.
---
## THE OBJECT
A FLUX issue should feel:
- cheap and immediate
- reproducible
- disposable and archival simultaneously
- bureaucratic and poetic
- automatic and handmade
The contradiction is deliberate:
> Disposable and permanent.
Cheap paper. Preserved time.
---
FLUX_WIKI_v1.0 — flux.dantesisofo.com/wiki/what-is-flux/
---
# PROTOCOL
FLUX is an open photographic protocol for publishing life in chronological sequence.
The goal is not perfection.
The goal is continuous seeing.
---
## PRINCIPLE
YOU CANNOT MAKE THE SAME PHOTOGRAPH TWICE.
The light changes.
The body changes.
The street changes.
The photographer changes.
Each photograph is a fragment of time.
Each issue is a record of becoming.
---
## METHOD
1. Walk.
2. Photograph what is in front of you.
3. Use a simple camera.
4. Work quickly.
5. Do not overthink.
6. Keep the photographs in chronological order.
7. Publish the sequence.
8. Move on.
---
## STEP_01 — CAPTURE
```
CAMERA: any camera
FILE TYPE: small JPEG recommended
COLOR MODE: high-contrast monochrome
PURPOSE: preserve immediacy
```
Move quickly.
Do not hesitate.
Photograph what is in front of you.
---
## STEP_02 — SELECT
Select quickly.
Do not:
- overedit
- oversequence
- overanalyze
- search for perfect frames
Work from small thumbnails and contact sheets.
The goal is not perfection. The goal is continuous seeing.
---
## STEP_03 — SEQUENCE
Preserve chronological order.
No manual rearranging.
The sequence is built from real movement through time.
The order of capture is the structure.
---
## STEP_04 — GENERATE
The system automatically:
- generates the publication
- generates the contact sheet
- generates the metadata manifest
- creates the printable issue
No manual layout required.
---
## STEP_05 — PRINT
Print double sided.
Stack pages.
Align edges.
Staple left side using cover marks.
Cheap reproduction is encouraged.
The issue is not precious.
The issue is evidence.
---
## STEP_06 — ARCHIVE
Store issues chronologically.
Preserve issue numbers.
Make publicly accessible.
Print.
Distribute.
Download.
Reproduce.
---
## WHAT THE PROTOCOL ENFORCES
The protocol is not optional in the following:
- **Issue length.** A canonical FLUX issue contains 36 photographs.
- **Chronological order.** Photographs are always presented in the order they were made.
- **Issue numbers.** Once assigned, permanent. Never reused. Never reassigned.
- **Frame numbers.** Sequential within the issue. Gaps are acceptable. Renumbering is not.
- **Metadata.** Timestamps, GPS coordinates, camera settings are surfaced, not hidden.
- **Blank back cover.** Always blank. Not a place for colophons or credits.
- **Protocol page.** Appears in every issue. Never omitted.
- **Protocol QR code.** Points to the public generator. Required. Never omitted.
---
## THE 36-FRAME CONSTRAINT
36 photographs = 1 FLUX issue.
1 FLUX issue = 1 roll of film.
The 36-frame constraint comes from the standard 35mm film roll.
FLUX uses digital tools, but preserves a physical photographic limit.
The constraint creates rhythm, cohesion, printability, and completion.
A roll of film ends. A FLUX issue ends.
The limit is the structure. The structure is the work.
**Historical note:** The FLUX system previously operated at 50 photographs per issue (Dante Sisofo's personal archive, 2024–2025) and an early public generator prototype specified 15 photographs. Neither count is part of the canonical protocol. 36 is the locked standard for all current and future FLUX issues — personal and public.
---
## CANONICAL VISUAL LANGUAGE
The canonical FLUX protocol prioritizes high-contrast monochrome output.
This is a structural decision, not an aesthetic preference:
- Strengthens archive cohesion across issues and years
- Optimizes for laser-print reproduction on standard office hardware
- Eliminates post-processing friction
- Emphasizes light, form, and time over color information
- Creates a unified visual language across all issues and contributors
- Supports rapid publishing without additional workflow steps
The canonical FLUX archive is monochrome.
Alternative workflows may exist outside the canonical protocol. The protocol does not prohibit color. It does not prioritize it.
---
## WHAT THE PROTOCOL DOES NOT ENFORCE
- Camera model (any camera is acceptable)
- Subject matter (the photographer decides)
- Title (optional and subordinate to the issue number)
- Frequency (daily is ideal, but FLUX does not enforce a shooting schedule)
---
## END_OF_PROTOCOL
Create your own FLUX issue:
`https://flux.dantesisofo.com/generator/`
---
FLUX_PROTOCOL_v1.0 — flux.dantesisofo.com/wiki/protocol/
---
# ZINE SPECIFICATION
Every FLUX issue is a physical zine. The format is locked. It does not change between issues.
---
## PHYSICAL FORMAT
```
Orientation: landscape
Size: US Letter — 11 × 8.5 in
Color: black and white
Typeface: Courier (monospace) — only
Background: white
Photographs: 36 (one roll of film)
Pages: 44
```
---
## PAGE ORDER
| Page | Content |
|------|---------|
| p.01 | Front cover — issue number, date range, author, staple guides |
| p.02 | Blank inside front cover |
| p.03 | Protocol page — 3-column layout with protocol QR code |
| p.04 | Blank reverse of protocol |
| p.05–40 | Image sequence — 36 photographs, chronological |
| p.41 | Blank — follows last photograph |
| p.42 | Contact sheet — 6 × 6 thumbnail grid |
| p.43 | Manifest / index — frame list (+ manifest QR for personal archive issues) |
| p.44 | Blank back cover |
The page order is permanent. Every issue follows it.
---
## SPREAD LOGIC
The 36-frame layout produces a clean spread sequence:
- **First photograph** (p.05) lands on the **right page** of a spread, with the blank protocol reverse on the left. The image sequence begins on the right.
- **Last photograph** (p.40) lands on the **left page** of a spread.
- **p.41** (blank) occupies the right of that same spread.
- **Turn page → p.42/p.43:** Contact sheet on the left, manifest on the right.
- **Turn page → p.44:** Blank back cover.
This is not an accident. 36 divides cleanly. The structure closes without a pad page.
---
## FIXED IMAGE BOX
Every photograph is placed inside a fixed image box. The box dimensions are constant across all 36 image pages.
**Rules — non-negotiable:**
1. **Scale to fit, preserve aspect ratio.** The photograph scales down to fit inside the box. Never upscaled.
2. **Center within the box.** Horizontally and vertically. Empty space remains white.
3. **No cropping.** The entire photograph is always visible.
4. **No stretching.** Aspect ratio is never altered.
A portrait photograph in a landscape box will appear smaller than a horizontal photograph. This is correct. Visual consistency across pages matters more than maximizing any individual image.
---
## IMAGE GRID LOCK
All 36 photographs render to the same visual height within the fixed image box. This is the grid lock.
**Image area geometry:**
```
IMG_AREA_W = 8.75 in (PAGE_W − M_LEFT − M_RIGHT)
GRID_IMG_H = 6.80 in (PAGE_H − M_TOP − M_BOT)
Page ratio = 8.75 / 6.80 = 1.287:1
```
The caption strip is placed within the bottom margin (`CAP_Y = PAGE_H − M_BOT × 0.58`), not below the image area. `GRID_IMG_H` therefore spans the full margin-to-margin space, centering all images at the optical page centre (4.25 in from top on an 8.5 in page).
Any frame whose aspect ratio is **wider than 1.287:1** is width-limited — its natural height at full page width falls below `GRID_IMG_H`. Both 3:2 and 4:3 landscape frames are width-limited on this page.
**The generator resolves cross-orientation height consistency via `effectiveGridH` — a per-batch computed height floor:**
```
For each image:
fitH = (IMG_AREA_W / iw) × ih
if fitH < GRID_IMG_H:
effectiveGridH = min(effectiveGridH, fitH)
scale = min(effectiveGridH / ih, IMG_AREA_W / iw)
```
| Camera output | Landscape fitH | effectiveGridH | Both orientations render at |
|---------------|---------------|----------------|----------------------------|
| 3:2 (Ricoh GR native) | 8.75 × 2/3 = **5.83 in** | 5.83 in | 5.83 in |
| 4:3 | 8.75 × 3/4 = **6.56 in** | 6.56 in | 6.56 in |
| Portrait-only batch | — (no landscape) | 6.80 in (ceiling) | up to 6.80 in |
`effectiveGridH` is the minimum width-limited height across all images in the batch. Every image — landscape and portrait — is capped to this value. The shared image horizon is self-correcting: it adapts to the actual camera output in the issue without any manual input.
**Optical image scale:** All drawn image dimensions are multiplied by `IMG_SCALE = 0.98` (a 2% uniform reduction). This is applied after `effectiveGridH` scaling and does not alter the centering anchor, caption positions, or spread structure. The reduction adds equal breathing room on all four sides of each image — approximately 2.2 mm per horizontal edge — producing calmer gutter spacing during physical flip-through.
The result: a consistent visual rhythm across all 36 pages regardless of whether the photographer shot horizontal, vertical, or mixed — and regardless of camera aspect ratio.
This grid lock is not limited to full-page images. The 6 × 6 contact sheet cell geometry is also landscape-oriented, so the same height-limited behavior applies at thumbnail scale. The lock holds at every scale in the publication.
---
## CAPTION STRIP
Below each photograph, two lines of Courier:
```
Line 1: YYYY-MM-DD HH:MM:SS lat, lon (GPS appended if present)
Line 2: Photographer Name
```
6.5 pt, dim gray. The caption is metadata. It is not a caption in the editorial sense.
---
## RUNNING HEADER
Top-right corner of every image page:
```
FLUX_NNN NN/36
```
6 pt, light gray.
---
## CONTACT SHEET
All 36 frames arranged in a **6 × 6 grid**.
The 6 × 6 grid is not arbitrary. A 35mm film roll contains 36 frames. A standard contact sheet from a 35mm roll is printed in rows of 6. The grid preserves that logic in the digital output.
- Each cell has the same fixed dimensions
- Each photograph is placed inside its cell using the same scale-to-fit rule as image pages: preserve aspect ratio, center within cell, no cropping, no stretching
- Frame numbers appear below each thumbnail (zero-padded, 3 digits, issue-local: 001–036)
- The contact sheet is also exported as a standalone PNG for the digital archive
**The 6 × 6 grid extends the image grid lock to the contact sheet.**
The cell dimensions (approximately 101.7 × 65.1 pt in the PDF, 424 × 291 px in the PNG) are landscape-oriented. For standard Ricoh GR output:
- Landscape (4:3) thumbnails: height-limited → render at ≈ 86.8 × 65.1 pt
- Portrait (3:4) thumbnails: height-limited → render at ≈ 48.8 × 65.1 pt
Both orientations are height-limited. All 36 thumbnails share the same render height. The top and bottom edges of every thumbnail align across the full 6 × 6 grid — the same grid lock that governs full-page image placement holds at the contact sheet scale.
The previous 10 × 5 grid (designed for 50-frame issues) used portrait-oriented cells, causing landscape and portrait thumbnails to render at different heights. That inconsistency is eliminated by the 6 × 6 geometry.
---
## MANIFEST / INDEX PAGE
Two-column frame list. One line per frame:
```
001 — YYYY-MM-DD HH:MM:SS — lat, lon
002 — YYYY-MM-DD HH:MM:SS
...
036 — YYYY-MM-DD HH:MM:SS
```
For personal archive issues: a manifest QR code appears at bottom-left, linking to this issue's live archive page.
For public generator issues: the manifest page is documentation only — frame list, timestamps, GPS. No QR code.
---
## QR CODES
The QR code structure differs between personal archive issues and public generator issues.
---
### ALL ISSUES — PROTOCOL PAGE QR
```
Location: p.03 (protocol page), bottom-right
Target: https://flux.dantesisofo.com/generator/
```
This QR is identical in every issue ever printed — personal or public. It invites anyone holding the physical zine to create their own FLUX issue.
The protocol page QR is **required in every issue**. It cannot be omitted or redirected.
---
### PERSONAL ARCHIVE ISSUES ONLY — MANIFEST PAGE QR
```
Location: p.43 (manifest page), bottom-left
Target: https://flux.dantesisofo.com/issues/FLUX_NNN/
```
Personal archive issues carry a second QR on the manifest page. It connects the physical object to its permanent digital record: all photographs, contact sheet, metadata, downloadable PDF and originals ZIP.
This QR is unique per issue, generated from the issue number.
---
### PUBLIC GENERATOR ISSUES — ONE QR ONLY
Public generator issues contain the **protocol page QR only**.
The manifest page (p.43) exists in public generator output and contains the full frame list — timestamps, GPS coordinates, frame numbers. It is documentation. It does not carry a QR code.
**Reason:** The public archive infrastructure does not yet exist. Placeholder or programmable manifest QR behavior produces inconsistent outputs, broken URLs, and unnecessary complexity in printed artifacts.
**Future:** When the FLUX public publishing infrastructure is built, public issues will receive a permanent archive page and a manifest QR pointing to it. That is future infrastructure. Until it exists, public generator output is a downloadable issue only — no automatic publishing, no manifest QR.
---
## BLANK BACK COVER
The back cover is always blank. This is not an oversight.
The blank back cover is a deliberate design decision that reflects the physical zine tradition. The back cover is not a place for credits, colophons, or additional images. The work ends with the manifest page.
The blank back cover says: this is done.
---
## PRINT ASSEMBLY
1. Print double-sided (duplex) on standard 8.5 × 11 paper.
2. Stack all pages in order (p.01 on top).
3. Align all edges.
4. Do not fold.
5. Staple on the left side at the two staple guide marks on the front cover.
Result: a landscape-oriented zine, stapled on the left edge.
---
## STAPLE GUIDES
Two horizontal rules printed on the front cover only:
- Upper guide: 1.5 in from top edge, centered on x = 0.325 in
- Lower guide: 1.5 in from bottom edge, centered on x = 0.325 in
These marks exist solely to guide physical stapling. They do not appear on any other page.
---
## HISTORICAL NOTE
The FLUX system has operated under three distinct frame-count implementations:
**15 photographs** — early public generator prototype. Produced a 22-page PDF. This specification was never built or deployed. It is superseded and not part of the canonical protocol.
**50 photographs** — historical Dante Sisofo archive batching logic (issues 001–304, pre-2026). Produced a 58-page PDF with a 10×5 contact sheet grid. The 10×5 grid was portrait-oriented: both landscape and portrait thumbnails were width-limited, so they rendered at different heights. The grid lock did not hold at the contact sheet scale.
**36 photographs** — canonical FLUX issue structure, current and permanent. Produces a 44-page PDF with a 6×6 contact sheet grid. The 6×6 grid is landscape-oriented: both orientations are height-limited, all 36 thumbnails render at the same height, and the grid lock holds at every scale.
The canonical frame count is **36**. All future issues — personal and public — use the 36-frame standard.
---
FLUX_WIKI_v1.1 — flux.dantesisofo.com/wiki/zine/
---
# ARCHIVE
The FLUX archive is a static website presenting the complete chronological record of every published FLUX issue.
It is not a portfolio. It displays everything, in order. The archive is the system made visible.
---
## CORE PRINCIPLES
- **Static.** No server-side computation. No database. No CMS. HTML, CSS, JavaScript, JSON, and image files. Runs on any static host.
- **Self-contained.** Every issue page contains everything needed to understand that issue: contact sheet, all photographs, manifest, PDF.
- **Timeline-first.** Primary navigation is chronological. The timeline sidebar navigates by year, month, and day.
- **No editorial framing.** No category labels. No thematic tags. No written commentary. Issues are identified by number and date only.
- **Downloadable.** Original photographs, manifest CSV, archive JSON, and PDFs are all publicly available.
---
## VIEWS
The explore interface provides five views:
| View | Description |
|------|-------------|
| GRID | Thumbnail grid of all photographs, chronological |
| LIST | Table view with filename, timestamp, issue, download links |
| SEQUENCE | Continuous vertical scroll, full width, one frame per row |
| PUBLICATIONS | Index of all issues, newest first, with PDF and ZIP links |
| PROTOCOL | The FLUX protocol page |
---
## URL ROUTING
```
https://flux.dantesisofo.com/ ← explore interface
https://flux.dantesisofo.com/explore.html ← same
https://flux.dantesisofo.com/issues/FLUX_NNN/ ← individual issue page
https://flux.dantesisofo.com/FLUX_ISSUES/FLUX_NNN/FLUX_NNN.pdf
https://flux.dantesisofo.com/FLUX_ISSUES/FLUX_NNN/ORIGINALS.zip
https://flux.dantesisofo.com/FLUX_ISSUES/FLUX_NNN/manifest.csv
https://flux.dantesisofo.com/timeline.json ← complete archive data
https://flux.dantesisofo.com/wiki/ ← this wiki
https://flux.dantesisofo.com/generator/ ← public generator (future)
https://flux.dantesisofo.com/{project-slug}/ ← collaborative projects
```
---
## ISSUE PAGE
Each issue page at `https://flux.dantesisofo.com/issues/FLUX_NNN/` contains:
- Issue identifier and date range
- Contact sheet (full-resolution PNG)
- All photographs (derivative-quality JPEGs, viewable in lightbox)
- Metadata table (camera, format, page count, PDF size)
- Download bar: PDF, ZIP, manifest, contact sheet
- Individual JPEG download links
---
## WHAT IS DOWNLOADABLE
| File | Location | Contents |
|------|----------|----------|
| `FLUX_NNN.pdf` | Issue page | Complete 44-page publication (36 photographs) |
| `ORIGINALS.zip` | Issue page | All original source JPEGs |
| `manifest.csv` | Issue page | Per-frame metadata (EXIF, GPS, filenames) |
| `contact_sheet.png` | Issue page | Contact sheet at 300 DPI (6 × 6 grid) |
| `timeline.json` | Archive root | Complete archive data (all issues, all frames) |
---
## ISSUE ARTIFACTS
Every published issue generates these files in `FLUX_ISSUES/FLUX_NNN/`:
```
FLUX_NNN.pdf — complete publication
manifest.csv — frame-level metadata
issue.json — machine-readable issue metadata
cover.png — cover image at 300 DPI
contact_sheet.png — contact sheet at 300 DPI
derivatives/*.JPG — web-optimized images (1400 px long edge)
thumbnails/*.JPG — contact sheet thumbnails
ORIGINALS.zip — original source files
```
---
## FLUX QUEUE
Before an issue is formally published, new photographs enter the FLUX Queue (`FLUX_QUEUE`).
The queue holds photographs that have been processed but not yet assigned to a numbered issue. The queue is visible in the public archive as an unnamed, unnumbered stream of recent work.
When the queue accumulates enough photographs for a session, the issue is formally published and the queue entries become a numbered issue.
Queue photographs are always uploaded to S3 on every deploy, so the archive always reflects the most recent unprocessed work.
---
## CACHE STRATEGY
| Asset type | Cache-Control | Rationale |
|------------|---------------|-----------|
| `explore.html`, `timeline.json` | no-cache | Updated every deploy |
| `style.css`, `script.js` | 5 minutes + content hash | Propagates without invalidation |
| Issue pages (`index.html`) | no-cache | May change on rebuild |
| Photographs, PDFs, ZIPs | 1 year immutable | Content never changes |
---
## REPRODUCIBILITY
The archive is fully reproducible. Given the original photographs and the generator scripts, the entire website — all HTML, all derivatives, all contact sheets, all PDFs — can be regenerated from scratch.
The manifest CSV, archive JSON, and metadata are all publicly downloadable. A researcher, archivist, or future system can reconstruct the complete record from these files.
FLUX is built to last. The archive that exists today should be legible and usable in twenty years, regardless of whether the specific tools that built it still exist.
---
FLUX_WIKI_v1.0 — flux.dantesisofo.com/wiki/archive/
---
# GENERATOR
There are two distinct FLUX generators. They are not interchangeable.
---
## PERSONAL GENERATOR
The personal generator is the core production tool that converts a session of original photographs into a complete FLUX issue, assigned to the permanent personal chronological archive.
**Canonical photo count:** 36 photographs per issue.
**What it does:**
1. Reads EXIF data from every photograph (timestamp, camera settings, GPS)
2. Renames files to the canonical filename format using EXIF timestamp
3. Assigns the next sequential issue number from the personal archive
4. Assigns frame numbers in capture-timestamp order
5. Generates the manifest CSV
6. Generates web derivatives (1400 px long edge, JPEG 70)
7. Generates thumbnails for the contact sheet
8. Generates the contact sheet PNG (6 × 6 grid)
9. Generates the PDF (44 pages: cover, protocol, 36 images, contact sheet, manifest, blank back)
10. Updates the archive: rebuilds `timeline.json`, issue page HTML, `explore.html`
11. Deploys to S3
**What it does not do:**
- Edit photographs
- Select photographs
- Reorder photographs
- Add captions
- Alter metadata
The generator is a translation machine. Originals in. Publication out.
**Invocation:**
```bash
python3 generate_flux_issue.py 305 # generate issue 305
python3 generate_flux_site.py # rebuild site
python3 deploy_s3.py --bucket flux-dantesisofo --issues 305 --cloudfront E1QJZ6W1R67CZD
```
---
## PUBLIC GENERATOR
The public generator is a separate tool accessible at:
```
https://flux.dantesisofo.com/generator/
```
It allows any photographer to run the FLUX protocol on their own photographs without requiring access to Dante Sisofo's personal archive or file system.
**Status:** Live. Launched 2026-05-12. Browser-based, no installation required.
**Canonical photo count:** 36 photographs per issue.
The 36-frame count is not a default — it is the standard. It is the same for personal issues and public issues.
**Implementation:**
- No account required
- Browser-based (HTML + jsPDF — runs entirely client-side, no server upload)
- Requires exactly 36 JPEG photographs
- EXIF timestamp read for chronological ordering and caption data
- GPS coordinates read from EXIF and surfaced in caption and manifest if present
- Protocol page included in every generated PDF
- Output format structurally identical to personal archive volumes
- No GPS requirement (GPS used when present, never required)
**Image system:**
- EXIF-aware compression via `createImageBitmap({ imageOrientation: "from-image" })` — portrait images stored as landscape with EXIF rotation tag are correctly oriented before processing
- `effectiveGridH` computed per-batch from minimum width-limited landscape height — adapts to 3:2, 4:3, or mixed batches automatically
- `IMG_SCALE = 0.98` applied to all drawn image dimensions — 2% optical reduction, centering anchor unchanged, adds ~2.2 mm breathing room per horizontal edge
- All 36 frames centered at optical page centre (4.25 in from top on an 8.5 in page)
**Output difference from personal generator:**
The public generator does not assign issue numbers from Dante Sisofo's personal chronological sequence. Public generator output is a standalone artifact — a complete FLUX issue, but not an entry in the personal archive.
---
## FLUX QUEUE
Before photographs are formally assigned to a numbered issue, they enter the FLUX Queue.
The queue is a staging area inside `FLUX_ISSUES/FLUX_QUEUE/`. Photographs in the queue have been processed (renamed, derivatives generated, manifests built) but have not yet received an issue number.
The queue is visible in the public archive as an unnumbered stream of recent work. When the queue contains 36 photographs for a session, a new numbered issue is published.
**Workflow:**
1. Drop JPEGs into `FLUX_UPLOAD/`
2. Run `./flux_update.command`
3. System automatically processes new photographs into the queue
4. When 36 queue photographs exist, the system publishes the next issue
---
## QR CODES IN GENERATED ISSUES
The QR code structure differs between personal archive issues and public generator issues.
---
### PERSONAL ARCHIVE ISSUES — TWO QR CODES
**QR 1 — Protocol page (p.03), bottom-right:**
```
Target: https://flux.dantesisofo.com/generator/
```
**QR 2 — Manifest page (p.43), bottom-left:**
```
Target: https://flux.dantesisofo.com/issues/FLUX_NNN/
```
Personal issues carry both QRs. The protocol QR is a standing invitation to any reader. The manifest QR connects the physical object to its permanent digital record.
---
### PUBLIC GENERATOR ISSUES — ONE QR CODE ONLY
**QR 1 — Protocol page (p.03), bottom-right:**
```
Target: https://flux.dantesisofo.com/generator/
```
The public generator embeds the protocol page QR only.
The manifest page (p.43) is present and contains the full frame list — timestamps, GPS coordinates, frame numbers. It is documentation. It does not carry a QR code.
**Reason:** The public archive infrastructure does not yet exist. Placeholder or optional manifest QR behavior — user-provided URLs, generator redirects, blank spaces — creates inconsistent printed artifacts and premature infrastructure complexity.
**Public generator output = downloadable issue only.**
No automatic publishing. No manifest QR.
---
### FUTURE PUBLIC PUBLISHING INFRASTRUCTURE
The public generator is live. The next layer — public archive infrastructure — is not yet built.
When built:
- User generates issue via public generator
- System creates a permanent public archive page for that issue
- Manifest QR is automatically generated, pointing to that page
The public archive would be searchable by photographer, date, and issue number, and chronologically ordered across all public contributors.
**This infrastructure does not yet exist.** When it does, the manifest QR for public issues becomes as locked and permanent as the protocol QR.
---
## HISTORICAL FRAME COUNTS
The FLUX system has operated under three different frame-count logics. These are distinct implementations, not variants of the same protocol.
---
### 15 PHOTOGRAPHS — early public generator prototype
**Context:** Experimental specification for an early public generator concept.
**Status:** Superseded. Never built or deployed.
**Not part of the canonical FLUX protocol.**
This count was chosen arbitrarily as a lower barrier for public participation. It produced a 22-page PDF. The logic was never implemented in a working generator. The specification is documented here only for historical completeness.
---
### 50 PHOTOGRAPHS — historical Dante Sisofo archive batching
**Context:** The original personal archive queue logic. Dante Sisofo's first 304 issues were generated using this batch size.
**Status:** Historical. No new issues will be generated at 50 frames.
**Not the canonical protocol — a production artifact of the early system.**
This count was not derived from any photographic tradition or formal constraint. It was a working batch size chosen for the personal archive pipeline. It produced a 58-page PDF with a 10×5 contact sheet grid (50 cells for 50 frames). The grid was portrait-oriented, meaning landscape and portrait thumbnails rendered at different heights — the grid lock did not hold.
---
### 36 PHOTOGRAPHS — canonical FLUX issue
**Context:** Current and permanent standard for all FLUX issues — personal and public.
**Status:** Locked. All future generators use this count.
**This is the protocol.**
36 = one roll of 35mm film. The constraint is not arbitrary — it comes from the physical medium FLUX references. It produces a 44-page PDF, a 6×6 contact sheet grid (36 cells for 36 frames), and a clean spread sequence with no orphaned pages.
The 6×6 grid is the correct geometry for 36 frames. Both landscape and portrait thumbnails are height-limited in the cell, so all 36 frames render at the same height — the same grid lock that governs full-page image placement extends to the contact sheet.
---
## NAMING CONVENTION
**Personal archive:**
```
FLUX_001 FLUX_002 ... FLUX_NNN
```
**Canonical filename format:**
```
YYYY-MM-DD_HH-MM-SS_PhotographerName_OriginalCameraFilename.JPG
```
Example:
```
2026-05-07_20-40-55_DanteSisofo_R0022598.JPG
```
**Collaborative project filenames:**
```
{project-slug}_NNN_{photographer-slug}_{YYYY-MM-DD}_{HH-MM-SS}.jpg
```
---
FLUX_WIKI_v1.1 — flux.dantesisofo.com/wiki/generator/
---
# PROJECTS
FLUX projects are collaborative, event-based, or site-specific photographic documents. They are distinct from the personal chronological archive.
---
## WHAT A PROJECT IS
A FLUX project brings multiple photographers together to document a single place, event, or condition simultaneously. The output is:
- A single web page documenting the project
- A gallery of all photographs from all contributors, chronological, filterable by photographer
- An interactive map showing GPS locations of all photographs
- A downloadable PDF
- A downloadable ZIP of all original photographs
- A downloadable manifest CSV
Projects are published at:
```
https://flux.dantesisofo.com/{project-slug}/
```
This URL is permanent. Once embedded in a QR code and printed, it cannot change.
---
## HOW PROJECTS DIFFER FROM PERSONAL FLUX
| Dimension | Personal FLUX | Project |
|-----------|---------------|---------|
| Authorship | Single photographer | Multiple photographers |
| Sequence | Personal chronological archive | Global chronological sequence across contributors |
| Issue numbers | From personal archive | None — project is standalone |
| Timeline | Integrated into personal archive | Separate standalone page |
| Generator | Personal FLUX generator | Project-specific assembly tool |
| Map | GPS stored, surfaced in archive | Central feature — interactive GPS map |
---
## BROAD STREET IN FLUX
**Status:** Published — 2026-05-10
**URL:** [flux.dantesisofo.com/broad-street/](https://flux.dantesisofo.com/broad-street/)
The first FLUX project and the proof of concept for the entire protocol.
A one-day photographic walk down Broad Street in Philadelphia. Two photographers:
- Dante Sisofo
- Dylan Stone
The project demonstrated that:
- two photographers can walk the same street on the same day using the same visual language following the same path
- and still produce two different visions
This is the core idea of FLUX made visible:
> The river is shared. The seeing is not.
**Why Broad Street:**
Broad Street is linear, civic, historical. It cuts through Philadelphia from north to south. It contains bureaucracy, commerce, poverty, beauty, decay, motion, and infrastructure. It can be walked, mapped, photographed, and archived in a single day.
The street became the river.
**Project components:**
- 50 photographs (35 Dante Sisofo + 15 Dylan Stone)
- Interactive Leaflet map with GPS coordinates
- Dark monochrome aesthetic
- Downloadable PDF
- QR codes embedded in printed handouts (URL locked before project launched)
---
## PROJECT NAMING CONVENTION
```
{project-slug}/ ← URL
{project-slug}_NNN_{photographer-slug}_YYYY-MM-DD_HH-MM-SS.jpg ← filename
```
Where `NNN` is a global sequence number across all photographers, assigned in chronological order by capture timestamp.
---
## RELATIONSHIP TO PERSONAL ARCHIVE
Photographs from a project made by Dante Sisofo may also appear in the personal FLUX archive as part of a regular numbered issue. The two records are independent. A photograph can exist in both without conflict.
---
## FUTURE PROJECTS
Projects to document as the system grows:
- `SCHUYLKILL_IN_FLUX` — along the Schuylkill River
- `PHILADELPHIA_IN_FLUX` — city-wide multi-photographer archive
- Student/workshop projects with defined geographic or temporal scope
---
FLUX_WIKI_v1.0 — flux.dantesisofo.com/wiki/projects/
---
# BROAD STREET IN FLUX
Case study. First canonical collaborative FLUX project.
Philadelphia, Pennsylvania. May 10, 2026.
---
## PROJECT RECORD
```
DATE: 2026-05-10
PHOTOGRAPHERS: Dante Sisofo, Dylan Stone
ROUTE: Cheltenham Avenue → Philadelphia Navy Yard
DISTANCE: ~11 miles
FRAMES: 50 total (35 Dante Sisofo / 15 Dylan Stone)
CAMERA: Ricoh GR IIIx
IMAGE CONTROL: High Contrast B&W
FILE TYPE: Small JPEG
GPS: Embedded via GR World (Ricoh app)
DURATION: ~7 hours (07:45 → 15:31)
```
---
## CONCEPT
Two photographers. One street. One day.
Both moved north to south across the full spine of Philadelphia — Cheltenham Avenue
at the northern boundary to the Navy Yard at the southern terminus — documenting the
city in real time from two separate positions on opposite sides of Broad Street.
Every photograph contains the exact date, time, and GPS coordinates of the moment it
was made. The GPS data is not a tag added in post. It is embedded in the original JPEG
at the moment of exposure via the Ricoh GR World mobile app.
The goal was not to make "good photographs."
The goal was to make a complete temporal and geographic document of a city in flux.
This project functions as:
- a street photography archive
- a GPS-mapped document
- a chronological sequence
- a zine
- a reproducible methodology
---
## STEP_01 — CAMERA SETUP
### Camera
**Ricoh GR IIIx**
The Ricoh GR is the correct tool for this protocol.
Small. Fast. Pocketable. Shoots small JPEG. GPS-compatible via Ricoh app.
### Image Control Settings
```
Image Control: High Contrast B&W
High/Low Key: -2
Contrast: +4
Highlight Contrast: -4
Shadow Contrast: 0
Sharpness: +4
Shading: +4
Clarity: +4
Grain: ON
Grain Size: 2
Toning: OFF
```
These settings produce a high-contrast monochrome output in-camera.
No post-processing. The JPEG is the final file.
Reference: [Ricoh_GRIV_Monochrome_Settings_Dante_Sisofo.pdf](../media/broad-street/downloads/ricoh-gr-monochrome-settings.pdf) (20 MB)
### Shooting Rules
**Small JPEG only.** No RAW. No large JPEG. Small JPEG files transfer faster,
automate faster, archive more efficiently, and produce no editing backlog.
**Move continuously.** Do not double back. Do not overthink. Photograph what is
in front of you. Respond to light, gesture, form, and movement.
---
## STEP_02 — GPS WORKFLOW
This is the most technically critical step. If GPS is not configured correctly,
the automation pipeline breaks. All downstream outputs — captions, CSV, maps, zines —
depend on GPS coordinates embedded in the JPEG metadata at capture time.
### GPS Test Session
Before the project walk, a GPS test session was conducted on May 3, 2026 — one week
prior. 42 test frames were made on foot near Philadelphia to confirm that GPS coordinates
were accurately embedded, persisted through camera sleep/wake cycles, and survived the
transfer pipeline.
The test confirmed accurate GPS embedding across an extended walk.
Source: `source/in-flux-broad-street/gps t3est/`
### Ricoh GR World Setup — On Camera
```
Menu → Wrench Icon → Wireless Communication
Wireless LAN: ON
Action Mode: ON
Pairing: Execute Pairing
Smartphone Link with Store Location: ON
```
### Ricoh GR World Setup — On iPhone
```
Settings → Privacy & Security → Location Services → GR World
Allow Location Access: Always
Precise Location: ON
Inside GR World App:
App Settings → Background Location Information Transmission: No Time Limit
App Settings → Location Information Transmission Frequency: High
```
### Confirming GPS Is Active
Indicators of confirmed GPS recording:
- Camera shows connected status
- Satellite icon active in viewfinder
- Blue iPhone location arrow active (visible in status bar)
- Test photographs contain populated GPS EXIF fields
Test before the walk begins. Make 1–2 test photographs and verify GPS fields in EXIF.
Do not begin the project walk until GPS confirmation is complete.
---
## STEP_03 — THE WALK
### Start
```
Meet time: 07:00
Start point: Cheltenham Avenue (northern boundary, Philadelphia / Cheltenham Township)
Direction: South
End point: Philadelphia Navy Yard
```
### Methodology
Dante photographed one side of Broad Street.
Dylan photographed the opposite side.
Rules during the walk:
- Keep moving south
- Do not double back
- Minimal street crossing
- No discussion of what to photograph
- No synchronizing shots
The sequence of capture becomes the structure of the archive.
The order of the walk is the order of the zine.
### Sequence
First frame: 07:45:58 — 1436 West Cheltenham Avenue, West Oak Lane, Philadelphia
Last frame: 15:31:24 — Philadelphia Navy Yard area
Total duration: approximately 7 hours 46 minutes.
---
## STEP_04 — IMPORT AND FOLDER STRUCTURE
### Folder Structure Created Before the Walk
```
BroadStreet_InFlux/
├── Dante/
│ └── Photos/
├── Dylan/
│ └── Photos/
└── Output/
```
After the walk, each photographer transferred their photographs from the camera to
their laptop via the Ricoh GR World app or direct USB connection, then dragged the
files into their respective Photos/ folder.
### Canonical Archive Structure
After processing, photographs were renamed to the canonical FLUX filename convention:
```
broad-street-in-flux_{seq:03d}_{photographer-slug}_{YYYY-MM-DD}_{HH-MM-SS}.jpg
Examples:
broad-street-in-flux_001_dante-sisofo_2026-05-10_07-45-58.jpg
broad-street-in-flux_003_dylan-stone_2026-05-10_07-57-08.jpg
broad-street-in-flux_007_dante-sisofo_2026-05-10_08-24-37.jpg
```
Sequence numbers are assigned chronologically across both photographers combined.
Gaps in a single photographer's sequence indicate frames by the other photographer
during that time window.
---
## STEP_05 — AUTOMATION PIPELINE
A single script execution reads all JPEG files, extracts EXIF metadata (including GPS),
performs reverse geocoding to convert coordinates to street addresses, generates captions,
and produces all downstream outputs automatically.
### What the Script Does
```
INPUT: JPEG files from Dante/ and Dylan/
OUTPUT:
broad-street-in-flux-google-my-maps.csv GPS + address data for Google My Maps
broad-street-in-flux-captioned-zine.pdf Captioned zine PDF
```
### Caption Structure
Every photograph is automatically captioned:
```
2026:05:10 08:24:37
6831 North Broad Street, East Oak Lane, Philadelphia, PA
Dante Sisofo
```
Caption components: timestamp, full street address (from GPS reverse geocode),
photographer name. No manual captioning. No manual sequencing.
Reference script: [auto-script.pdf](../media/broad-street/downloads/auto-script.pdf)
### Archive JSON
The archive generator produces a structured JSON manifest:
```json
{
"filename": "broad-street-in-flux_007_dante-sisofo_2026-05-10_08-24-37.jpg",
"originalFilename": "R0022840.JPG",
"photographer": "Dante Sisofo",
"photographerSlug": "dante-sisofo",
"date": "2026-05-10",
"time": "08:24:37",
"address": "6831 North Broad Street, East Oak Lane, Philadelphia, PA",
"lat": 40.05787,
"lon": -75.140704
}
```
50 entries. Every frame. Archive: [archive.json](../media/broad-street/downloads/archive.json)
---
## STEP_06 — GPS MAP (PROTOTYPE)
GPS coordinates embedded in the photographs were used to plot the walk geographically.
This was an early field test of GPS-mapped photography workflows — not a finalized
automated system, but a manual prototype that confirmed the data was usable.
### Early Mapping Workflow
The automation script exported a CSV of GPS coordinates and street addresses.
That CSV was manually imported into Google My Maps to visualize the route.
```
1. Script generates: broad-street-in-flux-google-my-maps.csv
Columns: Latitude, Longitude, Address, Photographer, Timestamp
2. Google My Maps → Create new map → Import CSV
Place markers by: Latitude / Longitude
3. Google Photos album imported separately
Photographs manually attached to approximate capture locations
```
This confirmed that GPS embedding was working correctly across 11 miles and 7+ hours
of walking — and that the coordinate data survived the full transfer and processing pipeline.
The Google My Maps export is a prototype visualization, not the canonical archive interface.
The live archive at `flux.dantesisofo.com/broad-street/` is the primary access point.
The CSV is preserved as a secondary geotagging artifact.
This early mapping work helped define what an automated FLUX project generator would
eventually need to produce: coordinates, addresses, and spatially indexed photographs,
generated without manual import steps.
CSV file: [broad-street-in-flux-google-my-maps.csv](../media/broad-street/downloads/broad-street-in-flux-google-my-maps.csv)
---
## STEP_07 — ZINE PRODUCTION
The captioned zine PDF is generated automatically by the script.
### Print Settings
```
Paper Size: 8.5 × 11 in
Orientation: Landscape
Double-Sided: ON
Flip On: Short Edge
```
### Assembly
```
Stack sheets.
Two staples on left side.
```
The object should feel temporary, reproducible, distributable.
The zine is not precious. The zine is evidence.
---
## STEP_08 — ARCHIVE GENERATION
The HTML generator (`generator/flux-generator.html`) produces a complete static
archive website from the photographs and metadata. The archive includes:
- Chronological image grid
- Photographer filtering
- Map integration
- Downloadable PDF
- Downloadable ZIP of originals
- Metadata manifest
Archive: `archive/index.html` (local package)
Live: [flux.dantesisofo.com/broad-street/](https://flux.dantesisofo.com/broad-street/)
---
## OUTPUTS
### Digital
```
archive/index.html Live archive web page
archive/broad-street-in-flux_dante-sisofo_dylan-stone.pdf Project PDF (31MB)
archive/data/archive.json 50-entry GPS manifest
archive/data/metadata.csv Metadata CSV
archive/downloads/photos.zip All originals (236MB)
documents/broad-street-in-flux-google-my-maps.csv GPS coordinates CSV (prototype map export)
```
### Physical
```
Printed zine (staple-bound, 8.5×11, landscape)
Loose photograph stack (50 prints, unbound, chronological)
```
### Video
```
video/broad-street-behind-the-scenes.mp4 167MB — behind the scenes documentation
video/broad-street-in-flux-book.mp4 32MB — zine flip-through
```
### Audio
```
audio/15th-street-philadelphia-city-hall-station.m4a Field audio, 15th Street
```
---
## LIVE ARCHIVE
[flux.dantesisofo.com/broad-street/](https://flux.dantesisofo.com/broad-street/)
Chronological grid. Photographer filter. Downloadable PDF. Downloadable originals ZIP.
GPS manifest. All 50 frames.
---
## DOWNLOADS
[broad-street-in-flux.pdf](../media/broad-street/downloads/broad-street-in-flux.pdf) — 31 MB — full project PDF
[flux-generator.html](../media/broad-street/downloads/flux-generator.html) — 60 KB — offline HTML generator
[broad-street-in-flux-google-my-maps.csv](../media/broad-street/downloads/broad-street-in-flux-google-my-maps.csv) — GPS coordinates CSV
[archive.json](../media/broad-street/downloads/archive.json) — 50-entry GPS manifest
[metadata.csv](../media/broad-street/downloads/metadata.csv) — metadata manifest
[auto-script.pdf](../media/broad-street/downloads/auto-script.pdf) — automation script
[ricoh-gr-monochrome-settings.pdf](../media/broad-street/downloads/ricoh-gr-monochrome-settings.pdf) — 20 MB — camera settings document
photos.zip — 236 MB — all 50 originals — available at [live archive](https://flux.dantesisofo.com/broad-street/)
---
## PROTOCOL DISCOVERIES
What this project confirmed or clarified about the FLUX protocol:
**GPS must be confirmed before the walk begins.**
A one-week pre-test session (May 3, 2026) was necessary to confirm GPS embedding
worked correctly across camera sleep/wake cycles and extended walking sessions.
The test is not optional.
**GR World must be set to "No Time Limit."**
The default background location transmission limit causes GPS data to stop being
embedded after a set period. This setting must be explicitly changed before the walk.
**Small JPEG is the correct file type for this workflow.**
RAW files would have added processing time, storage overhead, and editing friction
with no benefit for a high-contrast in-camera monochrome workflow.
**Chronological interleaving of two photographers works.**
Assigning sequence numbers across both photographers simultaneously — based on
capture timestamp — produces a coherent combined sequence. The archive reads
as one document, not two separate sets.
**The automation pipeline must be tested before the walk.**
Running a test import and verifying GPS extraction, reverse geocoding, and
caption generation before the project date eliminates uncertainty during processing.
---
## LESSONS LEARNED
**What worked:**
- Ricoh GR World GPS workflow: reliable, accurate, embeds coordinates in real time
- Automation pipeline: one script execution generated all outputs
- Chronological interleaving: the combined sequence reads as one coherent document
- High-contrast monochrome: consistent visual language across both photographers
- DIY zine assembly: cheap, fast, reproducible
**What would change:**
- Dylan had fewer frames (15 vs 35). A clearer briefing on target frame count
per photographer would produce a more balanced archive.
- The route took longer than estimated (~7.5 hours vs ~4 projected).
Future walks should build in more time or establish checkpoints.
- The `gps t3est/` session revealed that GPS embedding is not automatic without
explicit setup. This step should be formalized in any participant kit.
---
## REFERENCES
| Asset | Location |
|-------|----------|
| Camera settings | [ricoh-gr-monochrome-settings.pdf](../media/broad-street/downloads/ricoh-gr-monochrome-settings.pdf) |
| Automation script | [auto-script.pdf](../media/broad-street/downloads/auto-script.pdf) |
| GPS coordinates CSV (prototype) | [broad-street-in-flux-google-my-maps.csv](../media/broad-street/downloads/broad-street-in-flux-google-my-maps.csv) |
| GPS setup screenshots | `media/screenshots/gps/` (local package) |
| Prototype map screenshots | `media/screenshots/maps/` (local package) |
| Generator screenshots | `media/screenshots/generator/` (local package) |
| Physical zine photos | `media/book/` (local package) |
| Field documentation video | [embedded above](#step_03--the-walk) |
| Zine flip-through video | [embedded above](#step_07--zine-production) |
| GPS manifest | [archive.json](../media/broad-street/downloads/archive.json) |
| Live archive | [flux.dantesisofo.com/broad-street/](https://flux.dantesisofo.com/broad-street/) |
| Project PDF | [broad-street-in-flux.pdf](../media/broad-street/downloads/broad-street-in-flux.pdf) |
---
FLUX_PROJECT_v1.0 — flux.dantesisofo.com/wiki/broad-street/
---
# NODES
A FLUX Node is a physical archive terminal connected to the live FLUX publishing system.
---
## DEFINITION
FLUX Nodes are physical public access points connected to the live FLUX archive. A node continuously receives newly published FLUX issues as they are generated.
The result is a distributed public photographic archive that exists simultaneously:
- digitally
- physically
- locally
- chronologically
- continuously
FLUX Nodes transform the photographic archive from a static website into a living public system.
---
## CORE PRINCIPLE
Traditional photography platforms operate as feeds.
FLUX operates as an archive.
Feeds disappear.
Archives accumulate.
A FLUX Node allows the archive to exist physically in public space.
---
## WHAT A NODE CONTAINS
Each node may include:
- monitor or display
- archive access terminal
- printer (black and white laser)
- filing cabinet
- zine rack
- physical archive storage (chronological folders)
---
## NODE TYPES
### Library Node
The ideal first FLUX Node.
Libraries already understand archives, preservation, chronology, public access, civic documentation, and historical record keeping.
A library node may contain:
- archive terminal (monitor + keyboard)
- laser printer
- filing cabinet with chronological issues
- zine rack with printable copies
Public visitors can browse the archive, inspect contact sheets, print issues, download files, explore the chronology, and interact physically with the record.
### Camera Store Node
A continuously updating photographic archive inside a camera store.
Demonstrates the live publishing workflow to active photographers.
Merges photography culture with archival systems.
### Gallery / Museum Node
Functions as both archive and installation.
The node displays:
- newest issue
- publication queue
- archive statistics
- issue timeline
- live archive updates
The emphasis shifts from static exhibition toward continuous documentation.
### University Node
Research-oriented archive system.
Possible emphasis: metadata, chronology, sequencing, urban documentation, open publishing systems, photographic systems theory.
---
## SYNC LOGIC
At regular intervals, a node checks:
```
https://flux.dantesisofo.com/timeline.json
```
If a newer issue exists:
- download PDF
- print issue automatically
- update local archive display
- refresh monitor
Optional behaviors: notification sound, indicator light, queue display, archive statistics.
---
## PRINTING LOGIC
**Standard:** Black and white laser printer.
Reason: cheap, reliable, fast, reproducible, archival aesthetic. Identical to the paper the photographer prints at home.
**Filing cabinet:** Each issue stored chronologically. Physical folders become navigable public memory.
**Zine rack:** Printed issues available for visitors to take. The issue is not precious. Cheap reproduction is encouraged.
**Thermal printer variant (experimental):** Continuously prints the latest photographs as a live stream. More installation-oriented.
---
## INSTITUTIONAL FRAMING
FLUX Nodes should not initially be framed as:
- photography portfolio
- personal art project
- social media platform
- startup product
Frame instead as:
- continuously updating public photographic archive
- civic documentation system
- open publishing archive
- public visual timeline
- experimental archive infrastructure
- distributed photographic library
---
## WHY LIBRARIES
Libraries naturally align with FLUX because they already preserve public knowledge, local history, archives, documents, chronology, and civic memory.
FLUX extends library logic into live photographic publishing.
---
## FIRST NODE — PHILADELPHIA
The suggested first node:
```
FLUX NODE — Philadelphia
```
Contains: monitor, archive interface, laser printer, filing cabinet, printed chronological issues, zine shelf.
Public can: browse, print, inspect, download, interact.
The node demonstrates the concept through operation.
---
## LONG-TERM VISION
Multiple FLUX Nodes distributed throughout the city.
Libraries. Camera stores. Universities. Studios. Museums.
Each connected to the same continuously updating archive system.
The city documents itself in real time.
Not as feed.
Not as portfolio.
As living chronological memory.
---
## FINAL DEFINITION
FLUX Nodes are public physical interfaces connected to a continuously updating chronological photographic archive.
They transform photography from isolated images into distributed civic memory.
A FLUX Node is not merely a terminal.
It is a living access point into the flow of time.
---
FLUX_WIKI_v1.0 — flux.dantesisofo.com/wiki/nodes/
---
# MANIFESTO
---
## WHAT IS FLUX
FLUX is an open chronological photography publishing protocol.
Photographs are preserved in the order they were made.
The archive is the artwork.
The goal is to eliminate friction between:
```
CAPTURE
SELECT
SEQUENCE
PUBLISH
ARCHIVE
```
Each issue becomes part of a continuously expanding visual record of time.
---
## THE CORE SENTENCE
> You cannot make the same photograph twice.
The light changes.
The body changes.
The street changes.
The photographer changes.
Each photograph is a fragment of becoming.
Each issue is a record of movement through time.
---
## THE OBJECT
A FLUX issue feels like:
- a file
- a report
- a case document
- a municipal record
- evidence
- a field report
- a document of lived reality
The manila folder is important.
The office printer is important.
The staple is important.
The plain paper is important.
The small text is important.
The bureaucratic document aesthetic is not accidental.
FLUX uses the visual language of bureaucracy and turns it into art.
The FLUX object critiques bureaucracy while adopting its form.
---
## THE CONTRADICTION
> Disposable and permanent.
Cheap paper. Preserved time.
Ordinary material. Sacred through sequence and context.
---
## ANTI-BLOAT
A small percentage of people physically maintain the city:
- construction workers
- plumbers
- carpenters
- landscapers
- cleaners
- electricians
- laborers
- people who build and repair things
Meanwhile much of modern society is trapped in managerial layers, administration, screens, abstraction, and bureaucracy.
FLUX responds by returning to:
- walking
- seeing
- printing
- touching
- making
- physical documents
- direct experience
- real places
- embodied perception
FLUX is anti-bloat.
FLUX is anti-friction.
FLUX is anti-perfection.
FLUX is pro-life, pro-body, pro-seeing, pro-making.
---
## WHAT FLUX IS NOT
FLUX is not Instagram.
Instagram is about attention, likes, feeds, performance, identity, engagement, algorithmic visibility.
FLUX is about chronology, memory, archive, physical output, presence, continuity, daily seeing, preservation.
Instagram is social media.
FLUX is archival media.
---
## OPEN PROTOCOL
FLUX should become open and upgradeable.
Not a closed social platform.
Not the next Instagram.
Not a startup.
More like:
- open protocol
- open publishing system
- open archive format
- open photographic workflow
- open-source cultural infrastructure
People should be able to use it, fork it, improve it, generate their own zines, publish their own archives, contribute fixes, build on top of it.
---
## INSTITUTIONAL STATEMENT
For curators, galleries, and institutions:
> FLUX is a photographic publishing system that transforms daily image-making into chronological archives. Each issue preserves photographs in the order they were made, using metadata, timestamps, contact sheets, and printable zines to turn ordinary photographic practice into a physical and digital record of time.
> FLUX treats the archive as the artwork. Rather than isolating single masterpieces, it preserves the flow of photographic seeing through chronological sequence, metadata, and reproducible printed matter.
> FLUX is a post-digital photographic protocol combining street photography, metadata, automation, zine publishing, and archival practice. It creates a bridge between the physical and digital image, turning photographs into timestamped documents of becoming.
---
## FOR NORMAL PEOPLE
> FLUX helps photographers turn their daily photos into printable chronological zines.
Or:
> Shoot photos. Upload them. FLUX turns them into a zine.
Or:
> FLUX is a way to photograph life as it changes.
---
## TAGLINES
- You cannot make the same photograph twice.
- The archive is the artwork.
- Photography as a way of being.
- Publish the flow.
- Preserve becoming.
- Shoot. Sequence. Publish. Move on.
- A photographic protocol for life in motion.
- Chronological photography for a world in flux.
- The river is shared. The seeing is not.
---
## FINAL DEFINITION
FLUX is a system for photographing life in motion.
It begins with walking.
It continues through seeing.
It preserves photographs chronologically.
It transforms metadata into poetry.
It turns the archive into the artwork.
It rejects perfection.
It embraces becoming.
It makes photography physical again.
It makes publishing automatic.
It allows the photographer to move on.
> Keep seeing.
> Keep publishing.
> Keep moving.
---
FLUX_WIKI_v1.0 — flux.dantesisofo.com/wiki/manifesto/
---
# INFLUENCES
FLUX exists in a lineage. This is where it comes from.
---
## HERACLITUS
The philosophical root.
> You cannot step in the same river twice.
Applied to photography:
> You cannot make the same photograph twice.
The photographer enters the stream of becoming.
Each walk is different.
Each frame is unrepeatable.
Each day is new.
The photograph is not merely an image. It is a timestamped fragment of becoming.
---
## EUGÈNE ATGET
The primary photographic inspiration.
Atget walked Paris and documented streets, doors, windows, architecture, people, storefronts, infrastructure, and disappearing urban life. He worked daily, systematically, and directly. His work became powerful over time because he preserved a vanishing world.
FLUX continues this spirit through modern tools.
| Atget | FLUX |
|-------|------|
| Large wooden camera | Ricoh GR |
| Tripod | Handheld |
| Glass plates | High contrast JPEG |
| Slow process | Automated pipeline |
| Darkroom | Zine generator |
| Physical archive | Digital + physical archive |
The spirit is the same:
> Walk the world.
> Photograph what is there.
> Preserve time.
---
## PROVOKE
FLUX is inspired by Provoke magazine (Japan, 1968–1969) through:
- roughness
- high contrast
- grain
- anti-perfection
- photography beyond language
- printed matter
- urgency
- immediacy
- rejection of polished photographic norms
The photograph does not need to explain itself. The archive does not need to become a literary narrative. The chronological sequence allows the work to exist as evidence, rhythm, and trace.
FLUX does not force photographs into stories. It lets the chips fall as they may.
> FLUX is photography before explanation.
---
## ON KAWARA
The precedent for time-based daily practice as artwork.
On Kawara's date paintings transformed the daily record of a date into a systematic body of work. The accumulation was the work. The discipline was the content.
FLUX extends this logic into photography: the daily record of seeing, accumulated chronologically, becomes the archive.
---
## ROMAN OPALKA
A precedent for the archive as life project. Opalka's continuous counting — a lifelong commitment to a single systematic act — mirrors FLUX's commitment to continuous photographic publishing.
---
## BERND AND HILLA BECHER
Systematic, typological, serial photography. The Bechers photographed industrial structures — water towers, cooling towers, blast furnaces — in a consistent frontal style, building a comprehensive archive of disappearing industrial forms.
FLUX inherits their systematic approach, their commitment to seriality, and their sense that the archive is the artwork.
---
## DAIDŌ MORIYAMA
The visual DNA.
Moriyama's high contrast, grainy, blurred, immediate street photography — photographing at speed, photographing compulsively, treating photography as a physical practice — is a direct ancestor of FLUX's visual language.
The RICOH GR is the descendant of the camera he made famous.
---
## WALKER EVANS
Evans treated documentary photography as an archival act. His FSA project produced not just images but a systematic record of a time and place. The archive was always as important as any individual image.
---
## THE CONCEPTUAL ART TRADITION
FLUX also connects to artists who worked with time, repetition, archives, dates, and systems. The work is the system. The system is the statement.
This tradition asks: what if the discipline itself were the artwork?
FLUX answers: it is.
---
FLUX_WIKI_v1.0 — flux.dantesisofo.com/wiki/influences/
---
# ROADMAP
Where FLUX is going.
---
## CURRENT PRIORITY
**Documentation and stabilization phase.**
- Lock the protocol language
- Lock the zine layout
- Lock QR code structure
- Lock naming conventions
- Build the wiki
- Clean the archive
- Standardize all existing PDFs
- Improve the generator
- Onboard first users
Do not build the future until the present is stable.
---
## SUMMER 2026
Use the summer to consolidate, not expand.
- Consolidate and document the system
- Refine existing infrastructure
- Write the manifesto
- Lock the protocol
- Build the public generator (v1)
- Help existing students begin making issues
- Prepare institutional language
- Begin FLUX Node proposal for one library
This is builder mode, not launch mode.
---
## V1 — CURRENT STATE
- Personal FLUX generator: operational (304 issues)
- FLUX archive: live at `flux.dantesisofo.com`
- Collaborative projects: Broad Street In Flux published
- Protocol page: locked
- Zine format: locked
- Wiki: building now
---
## V2 — PUBLIC GENERATOR
**Target:** `https://flux.dantesisofo.com/generator/`
A browser-based or downloadable tool that allows any photographer to run the FLUX protocol on their own photographs.
Requirements:
- No account required
- Standard: 36 photographs per issue (canonical — same as personal generator)
- Protocol page included in every output PDF
- Output structurally identical to personal volumes
- GPS optional
The public generator is the outward-facing expression of the system's reproducibility philosophy. Anyone who scans the protocol QR code can run it.
---
## V2 — FLUX NODE (PROTOTYPE)
Physical archive terminal in one public institution.
Start extremely small. One successful node is more important than scale.
Target: a library or camera store in Philadelphia.
---
## V3 — INFRASTRUCTURE
Possible future hardware:
- Maxed-out MacBook Pro
- Mac mini (always-on local server)
- NAS archive (local backup of all originals)
- S3 bucket (current — continues as public layer)
Ideal flow:
1. Photograph
2. Transfer to phone via RICOH app
3. Phone to home machine via sync
4. Archive receives files automatically
5. Metadata extraction
6. Queue update
7. Zine generation (when threshold reached)
8. Web page creation
9. PDF + ZIP upload
10. Archive update
11. FLUX Node sync (if applicable)
---
## V3 — COLLABORATOR ONBOARDING
Once the public generator exists:
- Students begin making their own issues
- Private community shares PDFs and archive pages
- First non-Dante FLUX issues published
- A naming convention for public user issues is finalized
Possible naming:
```
FLUX_001 — PhotographerName
```
Where `FLUX_001` is the photographer's own sequential number, not Dante's.
---
## V4 — AI SELECTION
Train an AI model on:
- Original photographs
- Accepted frames (selects)
- Rejected frames
- Chronological sequences
- Metadata
- Visual preferences over time
Goal:
- Learn what the photographer keeps
- Learn what the photographer rejects
- Learn sequencing rhythm
- Automate culling
- Automate zine production
The dream:
> Go out and photograph. FLUX does the rest.
This is not the immediate priority. This is V4 or V5.
---
## OPEN SOURCE
FLUX should become open and upgradeable.
Not a closed social platform.
Not the next Instagram.
More like:
- open protocol
- open publishing system
- open archive format
- open photographic workflow
- open-source cultural infrastructure
People should be able to use it, fork it, improve it, generate their own zines, publish their own archives, contribute fixes, build on top of it.
The generator code, the protocol specification, and the archive format should all be publicly documented and reproducible.
---
## WHAT NOT TO BUILD
- No social feed
- No likes or engagement metrics
- No algorithmic ranking
- No advertising layer
- No subscription paywall for the archive
- No proprietary file formats
- No vendor lock-in
---
## FINAL PRINCIPLE
The stronger the archive system becomes:
- the less explanation is needed
- the less manifesto is needed
- the more self-evident the concept becomes
The archive itself creates belief.
---
FLUX_WIKI_v1.0 — flux.dantesisofo.com/wiki/roadmap/
---
FLUX_WIKI_v1.0 — flux.dantesisofo.com/wiki/