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.
THIS ADDED TEXT IS DRAFT
There are three main interfaces:
- Column - a copy of Mastodon Advanced, also known as TweetDeck. Designed for power users and monitoring multiple tag feeds.
- Story - a copy of the three-column Indymedia interface. Designed around following and building stories. Screen 1l4 1/2 1/4
- Mobile - a swipe-based consuming interface, similar to Tinder. Designed for simple, quick consumption on mobile devices. Screen scroll or object swipe
MakingHistory Specification: Federated Data Flows
Overview
Federated forum software such as Lemmy and Discourse demonstrates how the #Fediverse can support distributed conversations without requiring everyone to use the same server.
The technology is ActivityPub, an open protocol for exchanging social activities between independently operated servers.
A post, comment, vote, follow or repost can be represented as a structured ActivityPub object and delivered between servers. This allows communities to remain locally hosted while still participating in wider federated conversations.
For #MakingHistory, this is important because it provides a model for building distributed, persistent and community-controlled archives rather than putting all history into one central database.
How the federation works
Actors
ActivityPub represents people, communities and other participating entities as Actors with persistent identifiers, normally expressed as URLs. A person or community can have an identity that remains addressable across the network rather than being defined only by a particular website interface.
Inboxes and Outboxes
Each ActivityPub actor has an inbox for receiving activities and an outbox for publishing activities. When somebody interacts with a remote community, their home server sends an ActivityPub message to the remote server's inbox. The receiving server processes the activity and distributes relevant updates to other subscribers. This creates a network of server-to-server communication rather than one central service controlling the whole conversation.
Activities and Objects
Actions are represented as structured activities. Examples include:
Create- creating a post or commentLike- expressing a reactionAnnounce- reposting or sharingFollow- subscribing to an actorUpdate- changing metadata or contentDelete- removing an object
The objects themselves have persistent identifiers, allowing different servers to refer to the same piece of content.
Distributed conversations
Federated conversations create an important historical problem: the conversation is no longer stored in one place. A thread may contain objects originating on several different servers. A reply might be stored locally while its parent exists remotely. Another server may hold a further reply. Servers therefore need mechanisms for retrieving missing objects and reconstructing conversation context. For #MakingHistory this is more than a technical problem, it is an archival problem. A history should not disappear simply because one server goes offline, changes software or decides that an old conversation is no longer important. Persistent object identifiers, metadata and relationships between objects therefore become important parts of the archive.
Subscription and distribution
A user can subscribe to a remote community without having an account on the server that originally hosts it. The local server becomes a participant in the federation, receiving relevant activities and making them available to its own users. This creates a useful distinction between: where something is published and where people encounter it. That distinction is central to the #openweb. It allows communities to remain independent while still sharing information.
Federation and moderation
Federation does not mean that every server must accept everything from every other server. Administrators and communities are reponsable for opening and closeing flows, retain the ability to limit or block federation with other servers. This is an important part of the social architecture. However, defederation is a blunt instrument. Blocking an entire server can remove access to useful people and information as well as harmful material. The long-term goal should be to provide more information about the provenance, context and trust relationships surrounding historical material.
ActivityPub and PeerTube
PeerTube demonstrates another side of the same federated architecture. Both forum systems and PeerTube use ActivityPub for social interactions, but their data requirements are very different. A forum mainly exchanges relatively small text objects and metadata. Video and image sets requires substantial storage, bandwidth and delivery infrastructure. PeerTube therefore has additional mechanisms for distributing video efficiently, including peer-to-peer delivery through WebTorrent. The underlying social principle is similar: federate the relationships and metadata while allowing different systems to specialise in the media they handle. This is useful for #MakingHistory because historical projects rarely contain only one type of media.
A living archive may contain:
- text
- photographs
- video
- audio
- documents
- links
- comments
- metadata
- timelines
- people
- organisations
- places
- events
The archive therefore needs to connect these different media rather than attempting to turn everything into one giant database.
The MakingHistory direction
The important lesson from ActivityPub is not simply that we can federate forums. It is that history itself can be represented as a network of connected objects. A story can have: an author → an event → a place → a community → media → responses → corrections → later developments These relationships can remain visible and updateable over time. This moves #MakingHistory away from the traditional idea of an archive as a static collection of finished documents. Instead, it becomes a living historical record. The history can be added to, corrected, contextualised and connected without erasing the previous record.
What this means for #OMN
The #OMN can build on these existing open-web ideas while addressing a different problem. ActivityPub provides the basic federation layer. #OMN adds a social-media publishing and governance layer around:
- Publish
- Subscribe
- Moderate
- Rollback
- Edit Metadata
The aim is not simply to replicate existing social-media platforms. It is to make federation of trust flows useful for grassroots media and collective memory. The combination of ActivityPub, open metadata, human moderation, trust flow networks and persistent archives provides a possible infrastructure for community-controlled media commons.
The #4opens principle
For this to remain genuinely open, the infrastructure should follow the #4opens:
Open Data — the information and metadata should remain accessible.
Open Source — the software should be inspectable, reusable and modifiable.
Open Standards — systems should communicate using interoperable standards rather than proprietary APIs.
Open Process — the governance and decision-making around the system should be visible and accountable.
These are not simply technical preferences. They are social protections against the recreation of the #dotcons inside supposedly alternative technology.
MakingHistory as infrastructure
The wider objective is therefore not to build another social-media platform. It is to create infrastructure where communities can make, share and preserve their own history. ActivityPub provides one important piece of that infrastructure. #MakingHistory adds the archival and historical purpose. #OMN provides the grassroots media framework. #OGB provides a direction for federated governance. #IndymediaBack provides current media. Together these projects can help turn the #openweb from a collection of disconnected services into a more resilient federated media commons.
The technical challenge is federation. The social challenge is trust. The historical challenge is memory. The political challenge is keeping all three under community control.