ipfs.kane-il.us/legal/20250827T191034Z_ipfs_in_pl...

68 lines
3.8 KiB
Markdown
Raw Blame History

This file contains ambiguous Unicode characters

This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.

# IPFS in Plain English (for legal readers)
Host: https://ipfs.kane-il.us · Repository: `w3pbs/ipfs.kane-il.us` (Gitea, branch `main`) · Version: v1.0 · Generated (UTC): 2025-08-27 19:10:34Z
---
## What IPFS does
- IPFS gives every document a CID (content ID) that is a fingerprint of the exact bytes.
- If anything changes—even one character—the document gets a different CID.
- Example: if a body of text contains `01/01/1978` and that changes to `01/01/1987`, the CID changes. The original text keeps its original CID and remains retrievable at that CID.
---
## Why this matters in legal settings
- **Integrity:** Opening the same `/ipfs/<CID>` always returns the same document. If the bytes were different, the CID would be different.
- **Stable citations:** Every publish is timestamped and logged. CIDs never change, so filings can cite them permanently.
- **Audit trail:** Each publish has a signed manifest (path ↔ CID) and an entry in the permanent log at `/_log/publish.jsonl`. This log, not transient web pages, is the provenance record.
- **Court admissibility:** The CID itself is the authoritative reference. Filings should cite the CID to guarantee immutability, not just a URL or repository path.
---
## Repository vs. Immutable Retrieval
- **Repository (Gitea):** The repo at [gitea.barternetwork.us](https://gitea.barternetwork.us/w3pbs/ipfs.kane-il.us) holds the structured hierarchy (`/legal`, `/civics`, `/naics`, etc.). It provides human-readable organization, history, and convenience for operators.
- **Immutable files:** For authentic, court-admissible retrieval, always use the **CID**. The Gitea repo structures the files, but the CID guarantees their identity forever.
---
## Snapshots and navigation
- There is **no mutable “latest” pointer** (no IPNS, no DNSLink).
- Each published file is permanent, timestamped in its filename (`YYYYMMDDThhmmssZ_<slug>.md`), and referenced in the manifest/log.
- Gateway directory listings under `https://ipfs.kane-il.us` expose these timestamped files directly.
---
## How to verify (no installs needed)
1. Open `https://ipfs.kane-il.us/_log/publish.jsonl` (or the manifest for the filings date).
2. Find the file path and note its CID (and, if provided, SHA-256).
3. Confirm the CID matches the value on the filings cover sheet.
4. *(Optional)* Fetch the same `/ipfs/<CID>` via a second public gateway to cross-check—it will return the same bytes for the same CID.
---
## Scope & privacy
- Only court-public materials are published. Private or sealed content is not placed on IPFS.
---
## Terms (brief)
- **CID:** Content ID (hash of the exact bytes).
- **Manifest:** JSON file mapping file paths to their CIDs; cryptographically signed.
- **Publish log:** Append-only JSONL file at `/_log/publish.jsonl` recording each publish.
- **Snapshot:** Timestamped file committed once, never changed.
- **Gitea repo:** Source of structure and convenience; not itself proof of immutability.
---
## Email-sized blurbs (pick one)
**Ultra-plain (2 sentences):** IPFS assigns each document a unique CID that is a fingerprint of its exact text. If anything changes—even one character—the CID changes, so opening the same CID always returns the original document.
**With date example:** IPFS identifies each document by a CID. If `01/01/1978` is changed to `01/01/1987`, that small change produces a new CID—so the original text keeps its original CID and can always be retrieved.
**With “repo vs CID”:** The Gitea repo provides the folder structure, but the CID is the legal proof. For citations, always use the CID—because the CID is immutable, permanent, and court-admissible.
---
*Disclaimer: This explainer is informational, not legal advice, and does not represent any government.*