Table of Contents
A decentralized, participatory archive and storytelling network built on ActivityPub and the Fediverse.
Project Framing
MakingHistory is not a standalone application. It is a protocol-first component of the wider Open Media Network (#OMN) ecosystem, sharing infrastructure, governance, and code with:
-
IndymediaBack - decentralized publishing and moderation
-
OGB (Open Governance Body) - federated governance
-
OMN Core - #4opens-aligned federation infrastructure
The project follows two design principles, treated as hard architectural requirements rather than branding:
-
#KISS (Keep It Simple) - build on existing standards and proven software wherever possible.
-
#4opens - Open Data, Open Source, Open Standards, Open Process.
The system avoids proprietary formats, closed governance, vendor lock-in, and unnecessary protocol extensions. New infrastructure is introduced only where existing Fediverse components cannot meet the project's needs.
Architectural Principles
Reuse existing software and infrastructure wherever possible.
Federation before centralisation.
Metadata-first: OMN is fundamentally about moving and curating metadata; media files are secondary?
Human moderation before automation.
Progressive enhancement, simple first, advanced capabilities layered on later.
Server-first federation, with optional P2P replication and local-first caching (rather than treating any single device as primary storage).
High-Level Architecture
┌────────────────────────────────────────────────────────────┐
│ Client Layer │
│ │
│ Web UI • Mobile/PWA • Exhibition/Kiosk Mode │
└────────────────────────────────────────────────────────────┘
│
ActivityPub Client-to-Server (C2S)
│
┌────────────────────────────────────────────────────────────┐
│ MakingHistory Node │
│ │
│ ┌────────────┐ ┌──────────────┐ ┌───────────────────────┐ │
│ │ActivityPub │ │ Archive & │ │ Story & Narrative │ │
│ │Actor │ │ Media Engine │ │ Engine │ │
│ │Inbox/Outbox│ │ │ │ (timelines, curation, │ │
│ └────────────┘ └──────────────┘ │ narrative assembly) │ │
│ └───────────────────────┘ │
│ ┌──────────────────────────────────────────────────────┐ │
│ │ Federated Moderation & OGB Integration │ │
│ └──────────────────────────────────────────────────────┘ │
└────────────────────────────────────────────────────────────┘
│
ActivityPub Server-to-Server Federation
│
┌─────────────────┼─────────────────┐
▼ ▼ ▼
Mastodon PeerTube Other OMN Nodes
Each archive - a family, activist group, community, museum, or organisation - operates as its own ActivityPub Actor, self-hosted on a VPS or hosted on a shared MakingHistory instance. As with PeerTube, each archive remains independently owned, portable, and federated, rather than locked into a single central database.
Data Model
EntityActivityPub mappingNotesArchiveActor (Group or Person)One actor per archive?Media itemDocument, Image, or Video, wrapped in CreateCarries core metadata (date, place, people, source, licence)HashtagHashtagUsed for flow filtering, discovery, curationSaved columnLocal boolean queryUser-defined dynamic view, not federatedMetadata editUpdateEvery edit becomes an auditable ActivityPub activityStoryArticle (or minimal Story extension)References existing archive objects rather than duplicating themAnnotationNoteStandard threaded commentsModerationFlag + OGB extensionsShared governance layer
The model deliberately minimises custom object types, preferring existing ActivityStreams vocabulary wherever possible.
Components
Archive Ingest
A low-friction workflow for digitising physical and digital archives:
Bulk directory upload
Drag-and-drop web upload
Optional desktop import tool
Lightweight metadata entry at upload time
Optional OCR and EXIF extraction
Immediate federation via Create(Document) activities
The goal is to minimise the barrier to contribution while allowing richer metadata to be organically layered on afterward.
Metadata & Curation Interface
The primary interface follows a multi-column workflow, inspired by TweetDeck and Mastodon's advanced view.
Default columns include:
New
Recent
Untagged
Users then create their own saved filters using boolean logic, e.g.:
Oxford AND #1980s NOT #duplicate
On mobile, a swipe-based workflow supports rapid tagging and categorisation. Metadata edits generate standard ActivityPub Update activities, so all subscribed clients refresh automatically.
Story Engine
Assembles curated collections of archive material into narrative structures. Stories are composed of existing ActivityPub objects minimising duplicating content, and should:
Be embeddable
Be federated
Be CC-licensed by default
Publish as standard Article objects wherever possible
This makes storytelling another federated activity, not a separate publishing system.
Front End
Item mode (primary browsing view):
Left/right navigation moves between new/old items; up/down scrolls within an item.
Holding an item opens metadata entry - tags, text, comments - permissions-dependent on the user's edit rights.
Archive visibility:
Public archives are published as stories.
Personal/private archives exist as a list of draft stories, not yet published.
List mode (open design question - flagged for further work):
Left swipe: add item to archive.
Right swipe: tentatively, add metadata via the same swipe UX as item mode - needs to be specified before implementation.
Back End
Core responsibilities:
Flows: content moves through the system based on boolean tag queries, supporting both in and out.
Ownership: each object retains a clear owning actor even as it's imported, exported, or referenced across archives. (need to think about this)
Editing & metadata: Update activities on flowing objects need consistent conflict handling as they propagate between nodes.
Storage: a strategy is still needed for the split between live/cache databases and distributed permanent storage - open design question.