Update Project Framing

Project-Framing.md

@@ -154,4 +154,114 @@ Ownership: each object retains a clear owning actor even as it's imported, expor
 
 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.
+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
+
+# 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 comment
+* `Like` - expressing a reaction
+* `Announce` - reposting or sharing
+* `Follow` - subscribing to an actor
+* `Update` - changing metadata or content
+* `Delete` - 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.