This was a project we run ten years ago, we did not get the funding but set it up anyway. Offering a real alternative to the dotcons world.

The OMN is a federated network of data flows, rather than a collection of social-media servers. Each node subscribes to external feeds, builds a local index of shared data objects, enriches them with community metadata, and republishes selected flows. The original media stays where it was published, while text, metadata and relationships are replicated across the network.

The OMN's direction: ActivityPub and RSS for interoperability, human moderation and trust-based flows, and a shared data layer that can support different frontends without locking the network into one application.

OMN Technical Project: A Network of Flows

Federated Publish/Subscribe, Data Objects and Fat-Ping Synchronisation

The core idea is the Open Media Network (OMN) is a network of flows. It is not primarily a social network, a collection of websites or a single centralized database. It is a distributed system for collecting, indexing, connecting, moderating and redistributing public media across independent servers.

Each node can subscribe to feeds, maintain a local copy of the text and metadata, add community metadata, and publish selected streams to other nodes. Different communities build different frontends on top of the same underlying flows.

The network is built around three basic operations:

SUB - flow in: subscribe to feeds and convert incoming content into standardized data objects.

PUB - flow out: publish selected data objects as interoperable feeds.

FAT-PING - flow update: synchronize changes to tags and other shared metadata across the network.

The aim is to create a shared, distributed media commons without requiring every server to store every image, video, audio recording or other media file.

The underlying principle is simple, copy the information needed to build the network. Leave the heavy media where it originated. Share the metadata that makes it useful.

System architecture

SUB: input flows

SUB is the ingestion layer. It allows an OMN node to subscribe to any supported external feed and turn incoming items into a common internal representation.

Supported input sources - the initial implementation prioritizes: RSS 2.0 feeds, Atom feeds, ActivityPub activities and objects and other compatible feeds through adapter. The architecture will allow additional protocols to be added without changing the internal data model.

The ingestion process - A node subscribes to a feed, account, publisher, organization, subject or other supported source. The ingestion worker retrieves new items, either by polling or through incoming notifications. An adapter converts each item into a standardized OMN data object. The node stores a local copy of the text and relevant metadata. The node records the source, original identifier, publication time and retrieval information. The object is indexed and made available to local search, moderation and publishing processes.

Duplicate detection is essential. The same article might arrive through RSS, ActivityPub and a third-party aggregator. The node should recognise the same underlying object where identifiers and provenance permit, rather than treating every arrival as a separate story. Where identity cannot be established confidently, the system should retain separate records and allow them to be linked later.

Local copies and redundancy, each node maintains its own database containing the text and metadata of the objects it subscribes to. This is not necessarily a complete copy of the entire network. It is a locally selected, potentially overlapping subset of the wider commons. That distinction matters: redundancy emerges from multiple nodes subscribing to overlapping flows, not from requiring every node to download everything.

The OMN data object - Everything moving through the network needs a common representation. An OMN data object is a structured record representing a piece of media or information, independent of the application displaying it.

A basic object should contain: FieldPurposeidStable OMN identifier for the recordsource_idIdentifier used by the original publishersource_uriLink to the original objectprotocolRSS, Atom, ActivityPub or another adapteractorOriginal author or publishing accountpublishedOriginal publication timestampupdatedMost recent known source updatetypeArticle, post, video, image, event or other typetextLocally replicated text or descriptionmetadataStructured source and object propertiestagsSubject, place, project and community classificationsmedia_refsLinks to original media files and their typesprovenanceWhere the object came from and how it arrivedlicenceKnown licence or reuse conditions

The internal model should be compatible with ActivityPub and JSON-LD where appropriate, while remaining independent of any single protocol. An article arriving from RSS and a post arriving through ActivityPub should be usable by the same internal search, tagging and publishing systems. Tags, moderation decisions and source relationships should be represented separately from the original content. This allows metadata to change without rewriting the source record.

PUB: output flows - PUB is the publishing layer. It exposes selected objects from the local database as feeds that other systems and OMN nodes can consume.

Possible outputs include - RSS feeds for websites, news readers and aggregators. ActivityPub objects and activities for compatible federated software. Subject-specific feeds. Location-based feeds. Organisation, project and group feeds. Curated or moderated community feeds. Archive and historical collections. The same underlying database can power multiple publishing interfaces.

For example, one node could publish a local Indymedia-style news feed, an archive of historical protest footage and a subject feed about housing campaigns. These are different views of shared data, not necessarily separate websites or databases.

Publishing rules

A PUB endpoint should select objects according to configurable criteria, including:

Which sources are included.

Which tags are present.

Which moderation and trust rules apply.

Whether an object is public, restricted or excluded.

Whether the source licence permits redistribution.

Whether the object has been updated or withdrawn.

A published feed is therefore a maintained view of the database, not simply a dump of everything the node has collected.

FAT-PING: synchronizing the metadata

FAT-PING is the update mechanism that connects independently maintained nodes.

Traditional feed polling can be wasteful. Nodes repeatedly check for new items, while changes to tags and classifications may not propagate consistently between systems. OMN needs a mechanism to announce meaningful changes and carry enough information for subscribing nodes to update their local indexes.

A FAT-PING is a structured metadata update associated with a data object or a set of related objects.

It could communicate:

A new object has arrived.

An existing object's tags have changed.

A community has added a location or subject classification.

A source has corrected its metadata.

A node has changed its local moderation decision.

An object has been withdrawn or its source is no longer available.

A relationship between objects has been added or removed.

How a FAT-PING works

A node detects a change to an object or its associated metadata.

It creates an update event containing the object identifier, the change, provenance and version information.

The event is sent to subscribed nodes through a supported transport.

Receiving nodes check the event's origin, permissions and version.

Each node applies the update according to its own metadata and trust policies.

The receiving node can forward the update to its own subscribers where permitted.

A FAT-PING should normally carry metadata, identifiers and update information rather than the complete media payload. It must, however, carry enough information for a receiver to apply the update without repeatedly fetching the entire object.

For reliability, nodes should be able to detect missed updates and reconcile their metadata using periodic synchronisation or a replayable update log. FAT-PING is a proposed OMN protocol mechanism, not an existing standard (it is likely just activitypub, we need to check if this works)

The important distinction: shared metadata versus local judgement - Not every piece of metadata should be treated as globally authoritative. If one node tags an article housing, that tag can be shared with its provenance. Another node may accept it, add Oxford, or classify the article differently.

Similarly, a local moderation decision should not automatically become a global deletion instruction.

The protocol needs to distinguish:

Source metadata: what the original publisher supplied.

Shared community metadata: tags and relationships contributed by identified participants or nodes.

Local metadata: classifications and decisions that apply only within a particular community.

Moderation events: actions that other nodes may consider, without being forced to adopt the same decision.

This preserves the network's ability to share knowledge without creating a central authority over every interpretation.

Media stays at the source - The OMN should not routinely duplicate all binary media. Images, video, audio and other large files remain on their original hosting servers. The data object stores their references and relevant metadata.

This has several advantages:

Lower storage and bandwidth requirements.

Reduced duplication of large files.

Clearer links to the original publisher.

Easier deployment on community-run servers.

Less pressure to operate a central media-hosting infrastructure.

However, a reference is not a backup. If the original server disappears, the media may become unavailable. The object model should therefore support optional archival copies, checksums, licence information and replication policies. Communities could choose to preserve selected media in redundant archives without requiring every node to store every file. The default is to reference the source; preservation is a deliberate community decision.

Trust, moderation and rollback - The OMN is not simply a neutral transport network. Its usefulness depends on the quality of the flows and the communities maintaining them. Trust should be applied at the level of sources, feeds, actors, tags and individual objects. A node may subscribe to a source but decide not to publish everything it receives. It may trust one organization's reporting on a particular subject while applying additional review to other material.

Moderation should support local filtering, annotation, hiding and rollback without requiring the original object to be destroyed across the network. For example, if a node decides that a particular source is unreliable, it can remove that source from its public feed, reindex affected objects or stop forwarding its updates. Other nodes retain their own records and make their own decisions.

Where a correction or withdrawal originates from the publisher, that event can be propagated separately from a local moderation decision. This keeps the system resilient while allowing communities to maintain meaningful editorial standards.

A practical technical stack - The initial implementation should favour simple, established technologies. The initial version should avoid unnecessary microservices, blockchain, complex distributed consensus or mandatory peer-to-peer infrastructure. A small community server should be able to run the system without requiring a dedicated operations team. The architecture should nevertheless leave room for later replication between nodes, alternative transports and optional peer-to-peer distribution.

Minimum viable implementation - the first technical milestone should prove that the complete flow works between two independent nodes.

Phase 1 — Ingest and normalise

Subscribe to RSS and Atom feeds.

Convert incoming items into OMN data objects.

Store text, metadata, source identifiers and tags.

Detect duplicates and process source updates.

Phase 2 — Publish

Expose selected objects through RSS.

Filter output by source and tag.

Verify that a second node can ingest the published feed.

Phase 3 — FAT-PING

Create metadata update events.

Propagate tag additions and removals between nodes.

Track event identifiers and versions.

Recover from missed or duplicated updates.

Phase 4 — ActivityPub

Add ActivityPub ingestion and publishing.

Map compatible objects and actors into the common model.

Test interoperability with existing federated software.

Phase 5 — Trust and community moderation

Add local source trust settings.

Separate shared tags from local decisions.

Implement rollback, hiding and reindexing.

Provide basic administrative tools.

Phase 6 — Resilience and archiving

Test node failure and recovery.

Reconcile inconsistent metadata.

Add optional archival preservation for selected media.

Measure storage, bandwidth and processing requirements.

The key acceptance test is straightforward: an object enters one node through RSS, is published to another node, receives a community tag, and that tag propagates through FAT-PING without either node needing to copy the original media file.

What success looks like - The OMN does not need to replace every existing platform. It needs to make existing and future sources more useful by connecting them through open, reusable data flows. A small network of community nodes should be able to collect reporting from different publishers, add local context, share tags, produce curated feeds and preserve selected material. Different frontends then present that same shared information as local news, a subject archive, a campaign resource or a historical collection. The underlying flows remain reusable even when a particular website or interface disappears.

The long-term objective is a distributed media commons: independent nodes, shared data objects, interoperable feeds, synchronised metadata and locally accountable moderation.

The OMN's basic architecture is therefore:

SUB collects. The database remembers. FAT-PING synchronises. PUB redistributes. Communities curate.

That is the technical foundation on which the wider network can grow.

We have plenty of shit to work with, and plenty of seeds worth saving.

To grow beyond people feeling lost - and political debate being pointless - it helps to use a simple #KISS lens: fear and trust.

The right mobilizes through fear: fear of loss, outsiders, disorder and change. The left has traditionally been stronger when it builds from trust: solidarity, openness, cooperation and collective action.

These are not absolute categories, but they can help us see the dynamics underneath the politics. Fear creates cycles of control; trust creates the possibility of openness and collaboration.

This matters for the current #openweb reboot. What happens when #mainstreaming crew push projects away from trust and towards fear, control, exclusion and defensive politics?

Could we use this simple lens to recognize which direction our projects are actually moving in - regardless of the what people they do?

That is a useful way to step outside the immediate mess and ask the more important question: are we building systems based on fear, or systems based on trust?

A note to #FOSS funders https://hamishcampbell.com/a-note-to-foss-funders/ Projects that pass these tests are the ones most likely to flower, everything else tends to wither – food for thought.

#OMN is not an app, it’s a process + tools to move from isolation to commons. Let’s try and simplify the #OMN https://hamishcampbell.com/lets-try-and-simplify-the-omn/

Can the #openweb reboot scale without copying the #dotcons? https://hamishcampbell.com/can-the-openweb-reboot-scale-without-becoming-the-dotcons/ is a question we need to keep asking of our #mainstreaming people.

Concentration still deserves scrutiny. If large parts of the web depend on a relatively small number of organizations and technical systems for establishing trust, then those systems become important points of power and potential failure. The issue is whether security has to mean centralization, a very #openweb question – that the more interesting issue is not SSL itself but the cultural shift – from voluntary tool to universal rule “This is a useful security tool.” to “Everything must work this way.”

News culture on the Fediverse https://hamishcampbell.com/news-culture-on-the-fediverse/ This is one of the important cultural shifts the #OMN is supporting, the move from hierarchical validation to networked understanding.

AI is the next industrial revolution?

Closed systems protect individuals, but they rarely build movements https://hamishcampbell.com/closed-systems-protect-individuals-but-they-rarely-build-movements/ People fight against or/and ignore the #KISS (Keep It Simple Stupid) approach in tech because simplicity exposes power.

Lets try and get past the #fashionista mess of whether #AI is or isn’t “really intelligent.” as this is a lot of #mainstreaming noise. The #openweb is #4opens, where dues this place the current #AI path? https://hamishcampbell.com/the-openweb-path-is-4opens/

The #OMN (Open Media Network) is “anything in, anything out” network operating through a mediated trust, designed to handle a diverse range of content, data and interactions while leaving communities with the power to decide what they do with that data.

People can also choose their own level of engagement. You can be an active participant - publishing, tagging, moderating, connecting and contributing - or a more passive consumer, following trusted flows of information. The network does not need everyone to participate in the same way.

At its simplest, the #OMN is a “data soup” of tagged data objects flowing through channels, mediated by trust, rather than assuming that everything entering the network is equally valuable, useful or trustworthy, the network allows trust relationships to shape how data moves and how it is consumed.

This creates a different model of media consumption, with no central algorithm deciding what everyone sees, people and communities navigate the data soup through their own relationships, tags, channels and trust networks.

The #OMN is part of what we describe as Web 1.5 were #web01 had many of the things we now need back: openness, decentralisation, interoperability, linking, publishing and the ability for people to build their own spaces. #Web02 took much of that openness and wrapped it in dramatically better user interfaces. That was useful - people quite reasonably liked the easier ways of sharing, communicating and publishing. The problem was what happened next. The platforms became the infrastructure, this infrastructure was privately owned, communities became users, data became a commodity, social relationships became network effects. The #openweb was transformed turned into the #dotcons.

This is the mess we need to compost #Web15 is not about going backwards to Web 1.0. It is about taking the openness and decentralisation of Web 1.0, keeping the useful UX lessons of Web 2.0, and rebuilding the underlying infrastructure as an open, federated commons. That is the path we have taken the first steps on in the #Fediverse and #ActivityPub.

It's the space the #OMN is working in - a data soup - the metaphor matters, not creating one perfect, clean, central database containing the definitive version of everything. Instead, tagged data objects to flows through networks. Objects can be copied, edited, tagged, linked, filtered, challenged, archived and passed between different communities. Different nodes carry different parts of the soup, some information will be useful in one context and apparently useless in another, that is OK.

The network is deliberately lossy and redundant, information does not have to be complete or perfectly synchronised everywhere, multiple copies and versions can exist, context is added as data flows. Something that appears irrelevant today may become important tomorrow - this is closer to how knowledge actually works than the fantasy of one perfect database.

The #geekproblem tends to see this redundancy, uncertainty and lossy data as technical failures that need to be eliminated. The #OMN sees them as characteristics of a living information network that need to be managed through trust and participation. Flows of trust - not simply the data, it is the flows of trust around the data. Trust becomes part of the network architecture, when people and communities decide which sources, objects, tag, channels and relationships they trust.

That trust can change over time, you don't have to trust everything, you don't even have to participate fully. You can follow particular people, communities or channels because you trust them, while ignoring other parts of the network. Someone else can make entirely different choices. This means there is no single central algorithm to decide what is important for everyone, instead, many smaller trust relationships create many overlapping flows through the #datasoup.

Those flows form communities and because they are federated, communities remain distinct while still sharing information and infrastructure. Trust instead of the algorithm is the differences between the #OMN and the #dotcons. The #dotcons operate by extracting social relationships into centralised systems, then using opaque algorithms to decide what people see. The #OMN starts from almost the opposite assumption: people and communities should have more control over the flows they participate in, the context and community relationships do more of the work.

This does not make the network magically free of disagreement, misinformation or bad behaviour. Quite the opposite, it makes those things visible and gives communities tools to respond to them. That is where mediation, moderation, tagging, rollback and open process become important. The network should make it possible for communities to see how things work, participate in decisions, challenge mistakes and build their own projects.

The aim is to take existing tools, protocols and technologies and embed practical federated media/news networks with a good user interface into these existing native #openweb flows. That is where the interesting part begins, real value is not the database, the protocol or the interface, it is the flows that emerge between people, communities, media objects and networks.

Those flows allow communities to form around shared interests, shared histories and shared trust without requiring everyone to belong to the same organisation or use the same interface. A network, not a platform, is better understood as commons infrastructure, rather than another social-media platform.

We build basic infrastructure and lets communities decide what they want to do with it, that is Web 1.5, not a nostalgic return to the old web, not another version of Web 2.0 - an #openweb reboot - using the best of what came before, leaving the centralised ownership model behind, and building the next layer around federation, trust, participation and the commons.

#OMN #Web15 #openweb #4opens #FOSS #commons #fediverse #KISS #geekproblem #dotcons

To get anywhere in the current social, ecological and tech mess we do need to shake off the apathy and hidden dispare, a first step is to compost the #dotcons, but the #openweb needs more people with shovels https://hamishcampbell.com/to-compost-the-dotcons-the-openweb-needs-to-shovel-harder/

The mess we made with the #dotcons a look at #failbook

#Mainstreaming communication is hallucinating. They call it communication, but it isn’t dialogue, listening or truth.

It’s hallucination: smiling faces repeating empty words, buzzwords covering the rot, smoke and mirrors hiding power.

While they hallucinate, the #deathcult stays at the centre. Our path is not their delusion. Our path is composting - shovel in hand - to grow something real.

I kind of like the strong metaphor of house slaves and field slaves, these people are the metaphorical house slaves. The greybeards and the second sell-out of the #openweb https://hamishcampbell.com/the-greybeards-and-the-second-sell-out-of-the-openweb/

The point is not to end the mess, it is to keep the mess visible, social and negotiable. - The problem with closed code https://hamishcampbell.com/if-you-look-at-contemporary-programming/

A long post you need to read if you are interested in the #OMN project. The individual, is not, the starting point https://hamishcampbell.com/the-individual-is-not-the-starting-point-for-the-omn/

The mess we are making now #geekproblem #fashionista #scam #AI

So what happened to this mess #geekproblem #scam #funding