Update Project Framing
hamishcampbell
parent
e91dabae6e
commit
f5c0cffb5f
|
|
@ -1,28 +1,28 @@
|
|||
A decentralized, participatory archive and storytelling network built on ActivityPub and the Fediverse.
|
||||
|
||||
Project Framing
|
||||
### 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
|
||||
* IndymediaBack - decentralized publishing and moderation
|
||||
|
||||
OGB (Open Governance Body) - federated governance
|
||||
* OGB (Open Governance Body) - federated governance
|
||||
|
||||
OMN Core - #4opens-aligned federation infrastructure
|
||||
* 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.
|
||||
* #KISS (Keep It Simple) - build on existing standards and proven software wherever possible.
|
||||
|
||||
#4opens - Open Data, Open Source, Open Standards, Open Process.
|
||||
* #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
|
||||
### Architectural Principles
|
||||
|
||||
Reuse existing software and infrastructure wherever possible.
|
||||
Reuse existing software and infrastructure wherever possible.
|
||||
|
||||
Federation before centralisation.
|
||||
Federation before centralisation.
|
||||
|
||||
Metadata-first: OMN is fundamentally about moving and curating metadata; media files are secondary?
|
||||
|
||||
|
|
@ -32,9 +32,8 @@ 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
|
||||
### High-Level Architecture
|
||||
|
||||
```
|
||||
┌────────────────────────────────────────────────────────────┐
|
||||
│ Client Layer │
|
||||
│ │
|
||||
|
|
@ -62,19 +61,19 @@ High-Level Architecture
|
|||
┌─────────────────┼─────────────────┐
|
||||
▼ ▼ ▼
|
||||
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
|
||||
### 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
|
||||
### Components
|
||||
|
||||
4.1 Archive Ingest
|
||||
**Archive Ingest**
|
||||
|
||||
A low-friction workflow for digitising physical and digital archives:
|
||||
|
||||
|
|
@ -92,7 +91,7 @@ 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
|
||||
**Metadata & Curation Interface**
|
||||
|
||||
The primary interface follows a multi-column workflow, inspired by TweetDeck and Mastodon's advanced view.
|
||||
|
||||
|
|
@ -110,7 +109,7 @@ 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
|
||||
**Story Engine**
|
||||
|
||||
Assembles curated collections of archive material into narrative structures. Stories are composed of existing ActivityPub objects minimising duplicating content, and should:
|
||||
|
||||
|
|
@ -124,7 +123,7 @@ Publish as standard Article objects wherever possible
|
|||
|
||||
This makes storytelling another federated activity, not a separate publishing system.
|
||||
|
||||
Front End
|
||||
**Front End**
|
||||
|
||||
Item mode (primary browsing view):
|
||||
|
||||
|
|
@ -144,7 +143,7 @@ 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
|
||||
**Back End**
|
||||
|
||||
Core responsibilities:
|
||||
|
||||
|
|
|
|||
Loading…
Reference in New Issue