Add Project Framing
hamishcampbell
parent
85f96adb03
commit
7e6825b1ec
|
|
@ -0,0 +1,155 @@
|
|||
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
|
||||
|
||||
4.1 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.
|
||||
|
||||
4.2 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.
|
||||
|
||||
4.3 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.
|
||||
Loading…
Reference in New Issue