His starting point is that a language model is probabilistic by construction. Hallucination is not a defect waiting to be trained away, it is what the machinery does. So you do not correct it from inside the model. You put something formal outside the model, and you check against it.

Where this lines up with what we build

Two of his points are load-bearing for us, and we arrived at them from a different direction.

The first is why a graph rather than a table. He puts it plainly: adding something to a relational schema means adding a column and restructuring around it, while adding something to a graph means attaching one more edge. That is the same property we rely on for a different reason — merging two RDF graphs is concatenation, so two peers can combine what they know without negotiating a schema first. He wants it for evolution over time. We want it for evolution across machines. Same property, two payoffs.

The second is reusing vocabularies that already exist rather than inventing private ones — schema.org, FOAF, Dublin Core. On a peer-to-peer network that stops being good manners and becomes the mechanism. Predicates are URIs, so two nodes that have never met can mean the same thing without ever having coordinated. There is no registry to agree on, because the names are already global.

Then there is a structural fit that falls straight out of the design. In our envelope, a query is itself an RDF object — it arrives as a statement carrying its engine-specific text as a literal. Which means a request can be inspected as data before it is executed, by exactly the same machinery that inspects everything else on the wire. Coyle argues that an agent should stay free of side effects until its result has been validated. On this network, the place to put that check already exists: every message is a statement, and statements can be checked.

That is the whole reason the wire language is RDF and not a packed binary struct. A message that describes itself can be examined by something other than the code that produced it — which is what you need when the thing on the other end is probabilistic, and what you need when it is simply a peer running software you did not write.

That much is unremarkable. Plenty of things embed SQLite. What decides whether a network is worth building is the part in the middle: what exactly goes over the wire.

The first draft, and why it was wrong

The original design put SQL text inside a Rust struct and sent that. It worked, and it was a dead end, because it quietly bound the whole network to three accidents at once:

• SQLite’s five storage classes became the network’s value model.
• SQLite’s dialect of SQL became the only payload anyone could parse.
• Rust’s serde became the de facto schema language.

The test that kills it is simple. A Postgres node wants to join. Under that design it cannot even read an incoming request, let alone answer one. The network would have been a SQLite network wearing a protocol.

Splitting the two things that were fused

The ambition is symmetric heterogeneous peers: a Postgres, DuckDB or Mongo node joins, answers queries through its own authenticator, and asks questions of its own. Getting there means separating two concerns the first draft had welded together:

• The wire language, which every peer must speak, and which therefore has to be engine-neutral.
• The query payload, which is irreducibly engine-specific and should be left that way.

The wire language is RDF. Every message on the network is an RDF object serialized as Turtle. A query is also an RDF object — one that carries its engine-specific text along as a literal:

[] a rsntr:Query ;
   rsntr:mod    "sql-sqlite" ;
   rsntr:signal "SELECT name, seen FROM _peers ORDER BY seen DESC" .

Peers speak the payload families they understand, and render what they can. A node that has no idea what sql-sqlite means can still parse the envelope, see that this is a query, and route or refuse it intelligently.

The deliberate non-goal is worth stating: we are not translating every engine into one universal query language. That path is where data-integration projects go to die.

This is not a new idea

Putting a query inside a statement has precedent we leaned on rather than invented:

• SPIN represents SPARQL queries as RDF objects — a node typed as a select query, carrying its query text as a property. Our envelope is that shape with the engine generalised.
• R2RML, a W3C recommendation, holds a valid SQL query as a literal in Turtle.
• Resonator’s own earlier transport already turned every network event into a one-line Turtle statement and accepted Turtle commands back — no command vocabulary, only RDF flowing in and out.

Where the RDF starts

The handshake has two layers, and only one of them is RDF.

So “everything is RDF” is precise rather than rhetorical: it begins the moment the cryptography has finished.

Where it actually is

v3 is a Rust workspace. It builds the core crates, rsntr (a console tool meant to be comfortable for shell pipelines and for LLM agents), and a Python package usable from a notebook. The node is AGPL-3.0-only; the Python package and the mod PDK are MIT, so writing a client never drags you into the copyleft.

Honest about the moving parts: iroh is the third reconsideration of the base transport, and it sits behind a transport trait precisely because Bluetooth and radio should be able to take its place later. The envelope is the part we expect to outlive the transport under it.

Source and documentation live at resonator.network.

A triple is three columns

RDF’s entire data model is the statement: a subject, a predicate, and an object. That is it. There is no table, no schema to declare first, no migrations.

Written in Turtle, the serialisation we use, a statement looks like this:

<ed25519:a1b2…> rsntr:lastSeen "2026-08-18T09:14:00Z"^^xsd:dateTime .

Subject, predicate, object, full stop. A graph is just a pile of these.

Three consequences follow, and all three are load-bearing for a peer-to-peer network:

That last one is the property a heterogeneous network lives or dies on. A binary struct is all-or-nothing: you either have the exact type definition or you have noise. A pile of statements degrades gracefully.

SPARQL, and the trick we lean on

SPARQL is the query language for graphs of triples — pattern-matching over subject/predicate/object, in roughly the shape SQL has over rows.

The part we actually build on is stranger and more useful: a SPARQL query can itself be written as RDF. This is an old idea — SPIN expressed queries as RDF objects, a node typed as a select query carrying its text as a property.

Which means a message and a query about messages are the same kind of object. One parser. One dispatch rule: look at the type and act accordingly. That is what lets the envelope carry a SQL payload for one node and a SPARQL payload for another without the receiver needing a second protocol.

What we deliberately do not use

Almost all of it. We are not building an ontology, not doing reasoning, not running an inference engine, not writing OWL, and not shipping RDF/XML. There is no committee.

The working set is three things: triples as the model, Turtle as the syntax, and SPARQL as the query language. Everything else in the RDF world is available if someone wants it and irrelevant if they do not.

What it costs

Being straight about the trade: RDF on the wire is larger than a packed binary struct carrying the same information. Turtle is text. Predicates are URIs, and URIs are long.

That cost is real and we pay it deliberately, because the alternative — a compact format that only nodes sharing our exact type definitions can read — buys bytes at the price of the one property we actually want, which is that an unfamiliar peer can still make sense of what it receives.

It does impose limits worth designing around. Gossip messages have a small default ceiling, on the order of a few kilobytes, so anything large travels as a reference rather than inline. Compact RDF serialisations exist and are worth revisiting; for now, legibility beats compression.

The short version

RDF is a good fit here for an unglamorous reason. A peer-to-peer network is a place where you cannot assume the other side runs your code, your version, or your database. The format that suits that is one where a message is a pile of self-describing statements, and understanding some of them is a valid outcome.

The wrong question

A conventional audio classifier asks: is this one of the 527 things I was trained on? That is a good question if your world is made of those 527 things.

A room is not. A room has a particular fridge, one specific door that sticks, a tap that drips at a rate you would recognise instantly and no dataset has ever labelled, and a cough at three in the morning. None of these are classes anyone shipped. Ask a fixed classifier about them and it will confidently return the nearest label it owns, which is worse than saying nothing.

Katir never assumes it knows what a sound is. It notices that something happened, learns which of those somethings keep recurring, and asks you about the rest.

What that looks like in use

You name the fridge once. From then on, the fridge is the fridge.

Sounds that repeat get recognised as the same thing without you labelling every occurrence. Sounds the system cannot place are not forced into a category to make the numbers look tidy — they go into a ranked review queue, each item carrying the reason it ended up there. The queue is the product: it is the system telling you where its own judgement ran out.

Nothing leaves the phone

Capture, detection, recognition and the dashboard all run on the device. There is no account to sign into and no telemetry. The only thing ever fetched over the network is the model itself, once.

Speech is discarded before it is written to disk — not deleted afterwards. The system still records that it heard something and dropped it, so you can audit the gate working without anything reconstructable being kept.

An ordinary phone is enough. This is not a device that needs a hub, a subscription, or a server in someone else’s building.

Measured

Scored on a 600-second household soundscape with exact ground truth, at a half-second onset tolerance.

Katir is Android v0.1.0 and in development. More at katir.resonator.am.