The Federated Social Pinning Service relies on minimal, structured metadata to identify, locate, and validate pinned files. Instead of complex schemas, the system uses simple fields embedded in Federated Wiki pages or companion `.json` files.
Each pinned object should have a **canonical wiki page** that contains or links to its metadata. This page acts as the human-readable and machine-parsable source of truth.
# Required Metadata Each file tracked by the system should include: - CID: The IPFS content identifier (multihash) of the file - File Name: Human-readable name, may match original file - Content Type: MIME type or description (e.g. `video/mp4`, `application/pdf`) - Published By: Name or identity of the archivist who uploaded it - Pinned By: List of known pinning allies or services currently hosting it - Date Added: UTC timestamp when first added to the system
# Optional Metadata Additional useful metadata includes: - Size: File size in bytes - Languages: For multilingual files or subtitles - Hash Alias: Alternative name for the hash (if renamed to its CID) - Source URL: Where the file was originally found or documented - Related Pages: Other wiki pages that annotate, fork, or comment on this file - Tags: Freeform keywords (e.g. `extinction`, `mars`, `history`)
# Naming Strategy Files may be optionally renamed to match their CID: ``` QmW2WQi7j6c7UgJvKdnx36Wq6gXsRo8nGSE9KXZ5uYTCND.mp4 ``` This avoids ambiguity and ensures consistency across mirrors. The corresponding wiki page title can remain human-readable (e.g. "Apollo 11 Footage") and link to the CID-named file.
# Metadata Storage Metadata can live in any of the following places: - Inside a Federated Wiki page (as paragraphs or JSON blocks) - In a `.json` sidecar file with the same base name as the CID - In a shared metadata repository (e.g. `anarchive-metadata/`) All formats must be simple and readable. Avoid nesting and over-modeling.
# Use in Verification Mesh The metadata is used by Verification Mesh tools to: - Locate files and confirm hash match - Cross-check reported size and type - Determine if re-pinning is needed - Record health of each file across the network A minimal schema supports high flexibility and encourages participation across devices and levels of technical skill.
# Future Ideas - Hash Catalog: A federated index of known files and their metadata - Metadata Sync Agent: A tool to sync `.json` files from local folders to wiki or vice versa - Multilingual Descriptions: Forks of metadata blocks in multiple languages
This system aims to balance **machine verifiability** with **human usability**.