FLUX DOCUMENTATION SYSTEM Layer 7 — PRESERVATION | preservation flux.dantesisofo.com/wiki/preservation/
The archive lives everywhere.
Bitcoin merely proves it existed.
We are entering a world where:
Photography is approaching a crisis of authenticity.
The fundamental question becomes:
How do we prove a photograph was truly made by a human being, at a specific moment in time, witnessing reality?
The FLUX system naturally aligns with archival authenticity because it preserves:
This is fundamentally different from isolated masterpiece culture.
A single image can be manipulated.
But an entire chronological issue containing timestamps, GPS data, sequencing, neighboring frames, publication dates, cryptographic hashes, and distributed mirrors becomes exponentially harder to falsify retroactively.
The issue is the unit of authenticity. Not the photograph.
FLUX is creating a chain of visual custody for reality itself.
The value is no longer simply:
The value becomes:
Proof that a human being truly stood somewhere at a specific moment in time and witnessed reality.
In the AI era, authenticity becomes more valuable than perfection. Not the cleanest image. Not the most optimized aesthetic. The most verifiable image.
This is especially consequential for:
FLUX is not integrating blockchain technology for speculation or crypto gimmickry.
The purpose is:
The blockchain is not the archive itself.
The blockchain is the witness — the ledger, the timestamp, the proof of existence.
The actual archive remains decentralized across many layers.
The goal is not to trust one company or one technology. The goal is layered permanence.
Physical prints
+
Local drives
+
NAS systems
+
Public websites
+
Amazon S3
+
IPFS (distribution layer)
+
Arweave (permanent storage layer)
+
Bitcoin timestamp proofs
+
Libraries
+
Collectors
+
Public mirrors
This is how archives survive centuries.
Not through one blockchain. Not through one corporation. Not through one server.
Civilizations preserve information through redundancy.
These are not equivalent and the distinction matters.
IPFS is a content-addressed distribution network. Files on IPFS are identified by their content hash (CID). If even one byte changes, the CID changes. IPFS is excellent for distribution and verification — but files require ongoing pinning. Stop paying, and the file can disappear from the network.
Arweave is permanent storage. Pay once, stored forever — the economic model is designed around perpetuity. Arweave is the correct layer for archival permanence.
The correct architecture uses both:
IPFS → content-addressed distribution, verification, CDN
Arweave → permanent long-term storage, true preservation
FLUX already generates most of what a preservation protocol requires.
The pipeline currently produces, for every issue:
FLUX_NNN.pdf — complete publicationmanifest.csv — frame-level metadata with timestamps and GPSissue.json — machine-readable issue metadatacontact_sheet.png — 6×6 visual indexORIGINALS.zip — original source filesWhat the preservation layer adds:
.ots proof fileflux.dantesisofo.com/verify/FLUX_NNNThe archive already exists. The verification layer extends it.
FLUX PDF + ZIP + manifest
↓
Upload to Arweave (permanent) and IPFS (distribution)
↓
Generate SHA256 hashes and IPFS CID
↓
Timestamp hash on Bitcoin via OpenTimestamps
↓
Generate FLUX_NNN.ots proof file
↓
Publish verification page at flux.dantesisofo.com/verify/FLUX_NNN
No files stored on-chain. Only hashes, timestamps, and references.
This keeps the system lightweight, sustainable, decentralized, and future-proof.
Stored on: local SSDs — NAS — Amazon S3 — IPFS — Arweave
Only proofs go on-chain. The files live everywhere else.
A fully preserved FLUX issue contains:
FLUX_NNN/
├── FLUX_NNN.pdf — complete publication
├── FLUX_NNN.zip — original source files
├── manifest.csv — frame-level metadata
├── issue.json — machine-readable metadata
├── contact_sheet.png — 6×6 contact sheet
└── FLUX_NNN.ots — Bitcoin timestamp proof
The SHA256 hash of the PDF is the canonical fingerprint of the issue. If even one pixel changes, the hash changes. The timestamp proof confirms the hash existed before a certain Bitcoin block.
Each issue carries a verification manifest:
FLUX_NNN
Photographer: Dante Sisofo
Published: YYYY-MM-DD
Frames: 36
Pages: 44
PDF SHA256: 9f8a4d7bc...
ZIP SHA256: 13ad92...
IPFS CID: bafybeigdyr...
Arweave TX: abc123...
OpenTimestamp: FLUX_NNN.ots
Bitcoin block: verified
Canonical archive: flux.dantesisofo.com/issues/FLUX_NNN/
Verification: flux.dantesisofo.com/verify/FLUX_NNN
The cleanest physical implementation is a third QR code inside every verified issue:
QR CODE → flux.dantesisofo.com/verify/FLUX_NNN
A person scans the QR code inside the printed object. They arrive at the canonical verification portal showing:
This transforms the printed object into:
The FLUX issue format is unexpectedly powerful because PDFs are:
A single FLUX issue can simultaneously exist on a hard drive, in an email, inside a library, on IPFS, inside Arweave, on archive.org, inside private collections, inside physical storage boxes, and across mirrored servers worldwide.
That is resilience. The format was chosen for publishing. It turns out to be ideal for preservation.
The Coalition for Content Provenance and Authenticity (C2PA) is the emerging industry standard for camera-level authenticity. Adobe, Canon, Nikon, the BBC, and the New York Times are all members. Leica already ships a camera that embeds cryptographic C2PA signatures at the moment of capture — provenance anchored before the file leaves the camera.
C2PA addresses authenticity at the capture layer. FLUX addresses authenticity at the publication and archive layer. These are complementary, not competing.
As C2PA adoption grows, FLUX issues generated from C2PA-signed originals will carry authenticity proof from shutter click through permanent archive. The chain of custody becomes unbroken from the moment of exposure to the moment of indefinite preservation.
FLUX is already aligned with where this is going.
Once the preservation protocol stabilizes, FLUX VERIFIED EDITIONS can be designated as the canonical long-term archival objects.
These issues are:
The back cover of a Verified Edition carries the verification manifest directly on the printed object:
FLUX_NNN
SHA256:
9f8a4d7bc...
IPFS CID:
bafybeigdyr...
Bitcoin Timestamp:
Verified
Canonical Archive:
flux.dantesisofo.com/verify/NNN
Published:
YYYY-MM-DD
The archival metadata aesthetic aligns with the FLUX philosophy. Bureaucratic. Infrastructural. Documentary. Cold. Official. Anti-ephemeral.
The object becomes simultaneously artwork and evidence.
Continue publishing. Continue testing. Continue building.
The current period is the Genesis Era — pre-verification, pre-permanence infrastructure. The purpose is exploration, not finality. Every issue published now becomes part of the historical record regardless.
Before designating Verified Editions, finalize:
These become difficult to standardize retroactively. Lock them before scaling.
Once the protocol stabilizes, Verified Editions become the canonical long-term archival objects. The verification infrastructure is built once and runs permanently.
FLUX is no longer merely photography publishing.
It becomes archival-native publishing — a system designed from the ground up for authenticity, provenance, verification, permanence, decentralized preservation, and historical continuity.
Especially in the age of artificial intelligence.
The archive is the artwork. The proof is the infrastructure. The photograph is the evidence.
The minimum viable preservation stack requires nothing exotic:
Website (existing)
+
Amazon S3 (existing)
+
IPFS via Pinata or Filebase
+
Arweave via Bundlr or ArDrive
+
OpenTimestamps (free, open source)
That alone creates decentralized preservation, historical proof, censorship resistance, and independent publishing infrastructure — without turning FLUX into crypto spectacle.
Every FLUX object should carry a permanent canonical identifier that never changes.
Current filenames (FLUX_001.pdf, R0022598.JPG) are operational. They can be renamed, moved, reformatted. A canonical ID cannot.
Proposed format:
FLUX-2026-001-023
Encoding: FLUX — YEAR — ISSUE — FRAME
This ID follows the object across:
The canonical ID matters more than the filename. Filenames are addresses. Canonical IDs are identities.
The archive operates as nested manifests. Each level verifies the level below it.
MASTER_ARCHIVE_MANIFEST
↓
ISSUE_MANIFEST (FLUX_NNN)
↓
IMAGE_MANIFEST (FLUX_NNN_IMG_NNN)
File structure:
master_manifest.json
├── FLUX_001_manifest.json
│ ├── FLUX_001_IMG_001.json
│ ├── FLUX_001_IMG_002.json
│ └── FLUX_001_IMG_003.json
│
├── FLUX_002_manifest.json
│ └── ...
The master manifest contains the hash of every issue manifest. Each issue manifest contains the hash of every image manifest. Tampering with any level breaks the chain.
Every FLUX object maintains historical state information — a lifecycle record of what has happened to it.
CREATED — file generated by the FLUX pipeline
PUBLISHED — deployed to flux.dantesisofo.com
PRINTED — physical copy produced
EXHIBITED — displayed in a physical space
MIRRORED — copied to IPFS or Arweave
TIMESTAMPED — OpenTimestamp proof generated
ARCHIVED — deposited with a library or institution
Each state transition is timestamped. The chain of custody becomes a historical record of the object's life.
All manifests, metadata, and archival documents must remain human-readable without proprietary software.
Preferred formats:
Avoid: proprietary databases, binary formats, software-dependent containers.
The archive should remain understandable centuries from now. A researcher in 2150 should be able to open a FLUX manifest in a text editor and understand it without any FLUX-specific tooling.
A future human should be able to reconstruct the complete archive from:
without needing proprietary software, accounts, or living infrastructure.
The FLUX system is already designed around this. The generator code, manifest schema, and archive format are all documented and reproducible. The preservation protocol makes this explicit and permanent.
Every storage technology eventually dies.
Floppy disks. CD-ROMs. Flash drives. Cloud services. Blockchains. All of them have expiration dates that are unknown in advance.
The protocol explicitly acknowledges:
Migration is part of preservation.
Files will move. Mirrors will change. Storage systems will evolve. Platforms will disappear.
What survives migration:
hashes — content fingerprints, technology-independent
manifests — human-readable, format-stable
canonical IDs — permanent identifiers
timestamps — anchored to Bitcoin, survives any single platform
The FLUX system is designed to be migrated. When S3 eventually becomes the wrong choice, the manifests and hashes make migration verifiable. When IPFS evolves, the Arweave layer persists. When Arweave evolves, the Bitcoin timestamps remain.
Plan for migration. Build for migration. Migration is not failure — it is continuity.
What happens to the archive when Dante Sisofo dies?
This is not a morbid question. It is a serious archival question that most photographers never ask, and that most photographic archives fail to answer until it is too late.
A real preservation system must survive beyond its creator.
The FLUX system partially addresses this through decentralization — files on IPFS and Arweave exist independently of any single person or server. But decentralization alone is not succession planning.
Future solutions to implement:
The archive should be designed so that its creator's death triggers continuity, not loss. The work was made in public. It belongs to the public record. The infrastructure should reflect that.
The archive should intentionally encourage and enable public mirroring.
Every person or institution that mirrors the archive strengthens it. There is no competitive disadvantage to copies. Copies are the point.
Target mirrors:
The archive survives by spreading. Every copy is infrastructure. Every mirror is insurance against loss.
The FLUX archive is explicitly not a closed system. The timeline.json is publicly accessible. The PDFs are publicly downloadable. The manifests are publicly available. This is by design. The openness is the preservation strategy.
The archive must never depend entirely on any single corporation, service, or platform.
The following are dependencies, not foundations:
The archive must remain:
portable — moveable between storage systems
independent — operable without specific corporate services
exportable — complete data export always available
reproducible — reconstructable from public data
Every architectural decision should be evaluated against this principle. When a dependency becomes unavoidable, document it and maintain a migration path.
The archive does not attempt to prove objective truth.
This distinction matters enormously.
The archive proves:
This exact document existed
in this exact form
at this exact moment in time.
It does not prove:
What FLUX preserves is the existence of the artifact at a specific moment. The artifact is the evidence. What it is evidence of is for historians, curators, and future readers to interpret.
The cryptographic proof is humble. It says: this existed. Nothing more. Nothing less. That is enough.
The canonical verification page at flux.dantesisofo.com/verify/FLUX_NNN should answer one question first:
VERIFIED
Everything else is secondary. The page hierarchy:
1. VERIFIED (or: UNVERIFIED — immediately visible)
2. Photographer
3. Date and timestamp
4. Issue and frame
5. Original image (full-resolution viewable)
6. Download links (PDF, ZIP, original JPEG)
7. SHA256 hash
8. IPFS CID
9. Arweave transaction ID
10. OpenTimestamp proof and Bitcoin block
11. Mirrors
12. Full technical metadata
The user who scans the QR code on a gallery wall should understand in three seconds whether the object is authentic. The technical depth is available for those who want it. It is not the first thing they see.
The archive lives everywhere.
Bitcoin merely proves it existed.
FLUX is not merely storing photographs.
FLUX is preserving witnessed human existence against digital entropy.
| Document | Layer | Relationship |
|---|---|---|
| GALLERY PROTOCOL | Layer 3 — Field | The exhibition layer that uses the verification infrastructure |
| BOOTSTRAP | Layer 4 — Infrastructure | The NAS/compute infrastructure that feeds the preservation pipeline |
| INTELLIGENCE | Layer 5 — Intelligence | The embeddings layer whose outputs also need preservation |
| ROADMAP | Layer 8 — Roadmap | The development timeline for verification infrastructure |
| ARCHIVE | Layer 2 — Protocol | The archive structure the preservation protocol extends |
FLUX_PRESERVATION_PROTOCOL_v1.1 — flux.dantesisofo.com/wiki/preservation/