Building Neurowire: one canonical model, six feed formats
Neurowire treats feeds as a data-modelling problem: one canonical model that every parser produces and every serializer reads, so adding a format is a single serializer.
The core engineering decision behind Neurowire is that feeds are a data-modelling problem, not a parsing or scraping problem. Every parser produces the same canonical feed model, and every serializer reads that one model. The payoff is direct: adding a new output format is writing one serializer, not editing every parser, and supporting a new input is writing one parser, not touching every output.
Neurowire started from a simpler frustration: information overload. There is too much to read today, especially around AI, and following it through the usual platforms means keeping an account on someone else’s algorithm and reading what that algorithm decides to surface. Neurowire exists so anyone can easily build their own news feed from sources they trust, no gatekeeper in the middle. You can try it now at neurowire.app.
Why put a canonical model in the middle?
The naive approach to a feed tool is a matrix. You have N input formats and M output formats, and if you wire them directly you end up maintaining N times M conversions. RSS to Atom, RSS to JSON Feed, Atom to Markdown, and on it goes. Every new format multiplies the work and the bugs.
Neurowire collapses that matrix by inserting one canonical feed model between the two sides. Parsers only ever target the model. Serializers only ever read the model. So the cost of N inputs and M outputs drops from N times M to N plus M. That single architectural choice is what makes everything downstream composable, and it is the same reasoning behind the docs launch.
What does the model serialize to?
From one canonical feed, Neurowire emits six formats. Atom and RSS 2.0 cover anything that already speaks feeds. JSON Feed 1.1 covers modern clients. Markdown gives you a readable digest you can drop into a doc or a chat. Self-contained HTML produces a page that needs nothing else to render. And NWF, the native Neurowire Feed format, is the compact representation tuned for storage and transfer.
Because the model is the contract, none of these serializers know about each other, and none of them know which parser produced the feed they are writing. You can add a seventh format tomorrow by writing one function that walks the model and writes bytes.
How do sources, meshes, and constructs fit?
The model sits at the centre, but Neurowire layers a few composition concepts on top so you can build real pipelines.
- Sources and taps are where content enters. A source is anything Neurowire can parse into the model. A tap is a per-host recipe that turns a feed-less HTML page into a source.
- Meshes fetch several sources in parallel and merge them into one feed, handling dedupe and ordering.
- Constructs bundle multiple meshes into a single repository, grouped or flattened.
So you move from scattered sources, to a merged topic feed, to a curated bundle, and at no point do you leave the canonical model. Each layer just produces another instance of the same shape.
Where to read the code
The full documentation lives at neurowire.starside.io, and the source is on GitHub under Starside Labs. This site dogfoods the engine: its writing feeds are serialized from the same model the docs describe. If you want the architecture in one sentence, it is this: build the model right, and every format becomes a thin layer over it. More of the open-source work sits under projects, and you can reach me through contact.