An on-chain torrent.
Index where your content lives across storage networks. If one mirror goes down, find another.
The Connection Model
Rather than worrying about where data is stored or how it gets there, Urma focuses on keeping content findable. It maps a name to one or more places where that content lives.
Each name points to mirror locations - alternative sources for the same content. They can be on the same storage network or different ones. Urma does not check that mirrors match perfectly across networks. It is an index: you have a name, you get the mirrors. Any verification happens when you actually download, checking hashes per chunk.
infoNote
How It Works
The protocol works through a chain of signed claims and manifests. A publisher says a mirror exists for a piece of content, stakes a claim on the network, and broadcasts it. No one checks the claim at broadcast time; it's just an assertion. Staking costs something, which makes spam expensive and raises the bar for bad actors. Actual checks happen at download time, per chunk, by hash.
Publish
A publisher puts content on a storage network, builds the manifest pages and root pointer (backend-specific), and wraps them in an UrmaClaim. Staking the claim on-chain costs something: it makes spam expensive and signals the publisher has skin in the game.
Discover
Clients compute the name from a source claim ID and query the network for all mirrors at that name.
Verify
Each blob is verified via SHA-384 hash comparison. Signatures are checked against the channel public key. Poisoned mirrors fail on first download.
Claim Naming
Every Urma name comes from a source content's ClaimID. The format is simple:
u-{source_claim_id_hex}The u- prefix marks this as an Urma name. The rest is a 40-character hex encoding of the 20-byte source ClaimID. Clients compute this from content they already know about, then look up all mirrors registered to that name.