A modern counterpart to the proposal that gave us the World Wide Web -- this time for a universally open, peer-to-peer information layer built on Iroh.
The World Wide Web succeeded because it was open: anyone could read any page, anyone could publish without permission, and links connected everything. Over thirty years that openness has been hollowed out:
- Read requires permission. The web you actually access is mediated by gatekeepers -- DNS registrars, CDNs, cloud providers, search engines, app stores. Publish a page and it's only reachable if a dozen intermediaries let it through.
- Websites are fragile. A server goes down, a domain expires, a cloud bill goes unpaid -- the information vanishes. The web has no inherent archive or distribution mechanism.
- Offline is broken. The web assumes always-on connectivity. Billions of people experience disconnection daily, yet the web has no native store-and-forward mode.
- Files are identified by location, not content. A URL like
https://example.com/file.pdfbreaks when the file moves, changes, or the domain is repurposed. There is no way to verify you got what you asked for. - No cross-application data sharing. Every app owns a silo. There is no standard way for one application to read another's data with user-consented permissions.
Existing alternatives address some of these but introduce new problems:
| System | Strengths | Weaknesses |
|---|---|---|
| BitTorrent | Efficient swarm distribution, content-addressed | No mutable content, no incremental sync, no permissions model |
| IPFS | Content-addressed, decentralized naming | Heavy daemon, poor garbage collection UX, complex, slow to start |
| Syncthing | Folder sync, offline-capable, easy setup | No public-by-default model, no cross-app sharing, folders are opaque blobs |
| NNCP / UUCP | Async store-and-forward, resilient | No real-time sync, complex routing, no swarm distribution |
| ActivityPub | Federated social web | Server-centric, no offline, no P2P, content addressed by URL |
What we need is a system that combines all their strengths and none of their weaknesses -- a universal information layer that is public by default, content-addressed, swarm-distributed, offline-native, and permissioned with cryptographic capabilities.
We propose a new information system built on Iroh -- a Rust library providing content-addressed blobs, synchronised key-value documents, peer-to-peer connectivity over QUIC, and capabilities-based access control.
The system is not an application. It is a protocol and permission layer that any application can adopt -- like HTTP is not an application but a protocol any application can use.
| Property | How OIN achieves it |
|---|---|
| Public by default | Every namespace (document collection) has a public read capability derived from its namespace ID. Sharing the ID is like publishing a URL -- anyone who knows it can read. |
| Content-addressed | Every blob is identified by its BLAKE3 hash. If you have the hash, you can verify you got the exact bytes, from any peer. |
| Swarm distribution | Once a blob or document is fetched, the local node becomes a seed. Popular content is replicated across many nodes automatically. No server needed. |
| Offline-first | Documents sync incrementally via Iroh's event-log replication. Peers exchange changes when they meet -- over LAN, over relay, or via stored gossip. Reads always hit a local cache first. |
| Cryptographic identity | Every node has an Ed25519 keypair. Every document event is signed by its author. Trust is cryptographic, not institutional. |
| Store-and-forward | Relays and gossip enable async delivery. A peer in the field can collect updates and forward them when connectivity returns -- like NNCP but automatic. |
| Cross-app permissions | Capabilities (read capability = namespace ID, write capability = namespace secret) can be shared between applications. An OSM editor app can grant a map renderer app read access to a namespace. |
| Mutable & immutable | Blobs are immutable (content-addressed). Documents are mutable (append-only event logs). Collections tie them together -- a document can reference blob hashes, forming a mutable file tree atop immutable content. |
┌─────────────────────────────────────────────────────────┐
│ Open Information Network │
├─────────────┬──────────────┬─────────────┬──────────────┤
│ Blobs │ Documents │ Authors │ Capabilities │
│ (Content- │ (Key-value │ (Ed25519 │ (Read/Write │
│ addressed │ event logs) │ keypairs) │ tokens) │
│ files) │ │ │ │
├─────────────┴──────────────┴─────────────┴──────────────┤
│ Iroh Core (QUIC, relay, gossip) │
└─────────────────────────────────────────────────────────┘
Blobs -- The unit of immutable content. A file, an image, a video. Identified by blob:<hash>. Any peer that has the hash can provide the bytes.
Documents -- The unit of mutable state. A key-value store backed by an append-only event log. Each entry is signed by an author. Documents are identified by their namespace ID, which also serves as the read capability. Think of a document as a "live website" — the keys are paths, the values are blob hashes or inline data.
Authors -- Ed25519 keypairs. Multiple authors can write to the same document if they possess the write capability (namespace secret). Authors are identified by their public key.
Capabilities -- The permission model:
ReadCapability=NamespaceId(public key of the namespace). Anyone with this can read the document and fetch its blobs.WriteCapability=NamespaceSecret(private key of the namespace). Anyone with this can author new events in the document.
| Concept | Web (HTTP) | OIN |
|---|---|---|
| Page identity | https://example.com/page |
iroh://<namespace-id>/<key> |
| Content identity | URL (location-based) | blob:<hash> (content-based) |
| Publishing | Rent a server + domain | Share a read capability |
| Reading | HTTP GET to server | Direct from any peer |
| Linking | <a href="..."> |
<link rel="iroh" href="iroh://..."> |
| Caching | CDN (centralised) | Every peer is a cache |
| Auth | Cookies, OAuth, sessions | Cryptographic capabilities |
| Offline | Nothing | Full local replica |
| Archive | Wayback Machine (central) | Any peer can seed |
| Concept | BitTorrent | OIN |
|---|---|---|
| Content ID | Info hash (mutable only via new torrent) | BLAKE3 hash (immutable) + document (mutable) |
| Distribution | Swarm via tracker/DHT | Swarm via relay + gossip + DHT-like discovery |
| Mutable content | No (must make new torrent) | Yes (documents append events) |
| Incremental sync | No (piece-by-piece but all-or-nothing) | Yes (event log replication) |
| Permissions | None | Read/write capabilities |
| Metadata | .torrent file / magnet link |
Namespace ID + blob hash |
| Seeding | Explicit, per-torrent | Automatic, per-blob |
| Concept | Syncthing | OIN |
|---|---|---|
| Identity | Device ID (certificate) | Node ID + Author ID (Ed25519) |
| Data model | Folder of files | Document (key-value) + Blobs (content-addressed) |
| Sharing | Folder share (full access) | Read capability / Write capability (granular) |
| Discovery | Global discovery server + LAN | Relay + gossip + LAN mDNS |
| Sync | Full folder scan + delta | Event log replication (append-only) |
| Public sharing | No (private folders only) | Yes (share namespace ID) |
| Cross-app | No (Syncthing is an app) | Yes (protocol layer) |
| Concept | IPFS | OIN |
|---|---|---|
| Content ID | CID (hash + codec) | BLAKE3 hash |
| Mutable | IPNS (name system, slow) | Document (fast event log) |
| Overhead | Heavy daemon, GC, pinning | Lightweight, no GC needed |
| Startup | Slow (DHT bootstrap) | Fast (relay + direct connect) |
| Pinning | Explicit (must pin) | Automatic (local replica = seed) |
| Permissions | None (all public) | Capabilities (read/write) |
| Library | Go (heavy) | Rust (light, embeddable) |
The killer feature of OIN is that permissions are cryptographic tokens that can be shared between applications.
- Application A creates a document and obtains
NamespaceId(public) andNamespaceSecret(private). - Application A wants to let Application B read the document. It shares the
NamespaceId-- which is just a public key, safe to share. - Application A wants to let Application B write to the document. It shares the
NamespaceSecret-- a private key that must be transmitted securely.
App A (Map Editor) App B (Map Viewer)
│ │
├─ Creates namespace "my-map-data" │
│ (gets ns_id + ns_secret) │
│ │
├─ Shares ns_id with App B ──────────────────► │
│ (via OS intent / clipboard / QR code) │
│ ├─ Reads "my-map-data"
│ │ Fetches blobs via hash
│ │ Renders map
│ │
├─ Shares ns_secret with App B ──────────────► │
│ (via secure channel / same-device IPC) │
│ ├─ Writes new events
│ │ Signs with author key
│ │ Syncs back to swarm
This is analogous to OAuth scopes, but:
- No central auth server
- No token expiry (unless application-layer enforces it)
- Tokens are cryptographic keys, not opaque bearer strings
- Works entirely offline
| Capability | Token | What you can do |
|---|---|---|
| Public read | NamespaceId (public key) |
Read document, fetch blobs |
| Read + subscribe | NamespaceId |
Read + receive live updates via gossip |
| Write | NamespaceSecret (private key) |
Author new events |
| Admin | NamespaceSecret + Author key |
Write + sign + delete (tombstone) events |
See UX_WORKFLOWS.md for detailed user workflows comparing OIN to web browsing, torrenting, and Syncthing.
The key UX insight: users never see hashes, keys, or capabilities. They see:
- "Share this link" → shares a namespace ID (read capability), wrapped in a human-readable link like
iroh://<topic>/<key>. - "Share edit access" → shares a namespace secret, transmitted via QR code or secure channel.
- "Save for offline" → subscribes to a document, which replicates it locally.
- "Seed this" → the app marks blobs as "keep", ensuring local availability.
This proposal is the foundation for Mapa's P2P layer. Mapa uses OIN primitives directly:
- Collections are Iroh documents (event logs of map features).
- Templates are collections of blob references (icons, presets).
- Visibility levels (Private, Invite-Only, Following, Extended Network, Public) map directly to capability sharing.
- Peer discovery uses Iroh gossip + geohash-based topics for spatial discovery.
- Offline sync uses Iroh's document replication -- changes propagate when peers meet.
But OIN is not just for maps. The same primitives work for:
- Publishing articles and zines (blogging)
- Sharing photo albums
- Collaborative document editing
- Software distribution (like the web, but P2P)
- Scientific data sharing
- Community mesh networks
The web gave us universal read access. BitTorrent gave us efficient distribution. Syncthing gave us offline sync. NNCP gave us store-and-forward resilience. IPFS gave us content addressing. Iroh now lets us combine all of these into a single, lightweight, embeddable protocol.
We propose building the Open Information Network -- not as a new application, but as a protocol and permission layer that any application can adopt. Public by default. Content-addressed. Swarm-distributed. Offline-native. Capability-secured.
The original "Information Management: A Proposal" gave us the web. This is the proposal for what comes next.
"The web as I envisaged it, we have not seen yet. The future is still so much bigger than the past." -- Tim Berners-Lee
A side-by-side comparison of how people interact with the Open Information Network (OIN) versus the Web, BitTorrent, and Syncthing.
1. Buy a domain and hosting
2. Set up a web server (Apache, Nginx, etc.)
3. Write HTML, CSS, JS files
4. Upload via FTP / rsync / git push
5. Configure DNS to point domain to server IP
6. Configure TLS certificate (Let's Encrypt)
7. Hope the server stays up and the bill gets paid
Result: website lives at https://example.com
→ goes down if server fails or bill is unpaid
→ not accessible offline
→ only as fast as the server's bandwidth
1. Create a .tar.gz of your files
2. Generate a .torrent file (or magnet link) with tracker URLs
3. Upload to a tracker or add DHT nodes
4. Start seeding from your machine
5. Share the .torrent file or magnet link
Result: people can download, but...
→ you must keep seeding for others to get it
→ no updates (must create a new torrent for v2)
→ no partial sync (download everything or nothing)
1. Install Syncthing on all devices
2. Create a shared folder
3. Share the folder ID + device QR code with peers
4. Peers accept the share
Result: folder stays in sync between trusted devices
→ private by design (no public access)
→ no cross-app data sharing
→ folder is an opaque blob (no fine-grained access)
1. Open your OIN-enabled app (browser, editor, file manager)
2. Click "Publish" or "New Document"
3. App creates a namespace (generates keypair)
4. Drag files / write content into the document
- files become blobs (content-addressed, deduplicated)
- metadata becomes document entries (signed events)
5. App shows a "share link":
→ iroh://<namespace-id>/<path>
6. Share the link anywhere -- email, QR, NFC, chat
Result: content is live immediately
→ every peer that opens the link becomes a seed
→ content is verifiable by hash (no tampering)
→ works offline (local replica)
→ updates are incremental (event log append)
→ zero cost, no server, no domain
User perception: "I shared a link and it just worked. People can see it even when I'm offline."
1. User clicks a link or types a URL
2. DNS resolves domain → IP address
3. Browser connects to server (TCP + TLS handshake)
4. Browser sends HTTP request
5. Server sends HTML response
6. Browser parses HTML, fetches CSS/JS/images (more requests)
7. Page renders
What the user experiences:
- "Page not found" (404) if server is down
- "No internet" if offline
- "Slow" if server is far away or overloaded
- "Broken" if CDN or third-party resource is down
1. User gets a .torrent file or magnet link
2. Opens in torrent client
3. Client connects to tracker / DHT to find peers
4. Client downloads pieces from swarm
5. When complete, user opens the downloaded file
What the user experiences:
- Must have a dedicated torrent client app
- Must wait for full download before viewing (usually)
- No browsing -- it's a batch download
- No incremental updates
1. Peer shares a folder with user
2. User accepts the share on their device
3. Syncthing syncs all files to local folder
4. User opens files in whatever app they choose
What the user experiences:
- Seamless sync, but private -- no discovery
- Must pre-arrange sharing (not ad-hoc)
- No "browsing" -- it's a synced folder
1. User receives a link: iroh://<ns-id>/photos/vacation
2. Opens in any OIN-enabled app (browser, gallery, file manager)
3. App resolves namespace ID → finds peers via relay/gossip/LAN
4. App fetches document entries (key-value event log)
5. App discovers blobs referenced by entries (BLAKE3 hashes)
6. App fetches blobs from fastest available peer(s)
7. Content renders immediately -- streaming for large blobs
8. App caches everything locally (full replica by default)
What the user experiences:
- Opens instantly if content is cached (always, after first visit)
- Opens even when offline (local replica)
- Works from any OIN-enabled app, not just one browser
- Content is verified (hash check) -- trust is automatic
- Subsequent visits are instant -- no server round-trip needed
- Updates appear automatically (event log replication)
User perception: "I open the link, the content is there. It's fast. It works offline. I can share it with anyone."
Traditional approach:
- Shared Google Doc / Notion / Wiki
- Central server coordinates edits
- Users log in with accounts
- Real-time via WebSockets
Traditional approach:
- Server is the authority
- No server = no collaboration
- Accounts = permission management
- Export = fragile (HTML dump, PDF)
- Each user edits local files
- Syncthing syncs changes between devices
- Conflict resolution: "Syncthing keeps both versions"
Problems:
- All users have full write access to the folder
- No per-user authorship tracking (just file timestamps)
- Conflicts are frequent with concurrent edits
- No "read-only" sharing (share a folder = full access)
1. User A creates a document (generates namespace keypair)
2. User A gives the namespace secret to User B
(via secure QR scan, encrypted message, or on same device)
3. User B opens the document, now has write capability
4. User A and B both write entries to the document
5. Each entry is signed with the author's Ed25519 key
6. Changes replicate between peers via Iroh's sync protocol
7. Conflict resolution: per-key last-writer-wins (CRDT-friendly)
8. User C wants to read: User A shares only the namespace ID
9. User C gets a read-only replica, no write access
Advantages:
- Authorship is cryptographic (every entry is signed)
- Granular permissions (read vs write)
- No central server
- Works offline (changes sync when peers meet)
- Read-only sharing is safe (public key is public)
- Multiple apps can collaborate on the same document
(map editor writes features, map viewer reads them)
User perception: "I invited my team. We edit the same space. Everyone's changes are signed. I can give read-only access to anyone with a link."
Offline = broken
- No cached pages = nothing to see
- Service Workers help but are limited
- No way to queue actions for later
- No way to forward content to another peer physically
Designed for async:
- Queue files and commands
- Transfer via physical media (floppy, tape) or periodic dial-up
- Store-and-forward through intermediate nodes
Problems:
- Manual routing (complex configuration)
- No real-time when connectivity IS available
- No swarm distribution
- No content addressing
- Can download pieces gradually
- Can resume interrupted transfers
- But: no incremental updates, no two-way sync
- Seeder must be online for initial transfer
1. User opens content while online → full replica cached locally
2. User goes offline → opens same content from local cache
3. User makes edits while offline → events queued locally
4. User meets another peer:
a. Over LAN (Wi-Fi Direct, Bluetooth)
b. Over relay (when connectivity returns)
c. Via physical transport (sneakernet -- USB key with OIN)
5. Queued events sync automatically
6. Peer who received events can forward them to others
→ Store-and-forward, automatic
Advanced: "Sneakernet mode"
- User A in a remote village visits a town with internet
- Phone syncs all queued peer content via the town's relay
- User A returns to village -- content propagates locally
- No changes were lost. Every event replicated eventually.
User perception: "I never worry about connectivity. Changes sync when they can. The system is patient."
- APIs (REST, GraphQL) between services
- OAuth for delegated auth
- Webhooks for events
Problems:
- All server-mediated
- Requires internet, accounts, API keys
- P2P apps can't consume each other's data
- "Your calendar app can't read your map app's data"
Scenario: Map Editor + Map Viewer + Chat App
1. Map Editor (App A) creates a document:
NamespaceId = 0x7c9a... (public)
NamespaceSecret = 0x3f1b... (private)
2. Map Editor shares NamespaceId with Map Viewer (App B):
→ App B reads the map data, renders it
→ App B receives live updates via sync
3. Map Editor shares NamespaceSecret with Chat App (App C):
→ Chat App can embed map links as rich previews
→ Chat App reads the document to generate previews
→ No API needed, no server, no OAuth dance
4. User installs a new OIN-enabled photo app (App D):
→ App D asks: "Which namespaces do you want to share?"
→ User selects the map namespace (read-only)
→ App D can now show photos attached to map features
User perception: "All my apps can talk to each other. I control who reads what. No accounts needed."
| Task | Web (HTTP) | BitTorrent | Syncthing | OIN |
|---|---|---|---|---|
| Publish | Rent server, configure DNS, upload files | Create torrent, seed | Share folder | Click "Publish", share link |
| Read | HTTP GET from server | Wait for download, open file | Wait for sync, open file | Open link, renders instantly |
| Share | Send URL | Send .torrent / magnet | Share folder ID + accept | Send link (read) or QR (write) |
| Update | Re-upload files | New torrent needed | File changes sync | Append events to document |
| Offline | Broken (mostly) | Can resume later | Full local sync | Full local replica + queue |
| Discover | Search engines | Tracker / DHT | Pre-arranged | Gossip + geohash + relay |
| Permissions | Accounts + OAuth | None | All-or-nothing | Read capability / Write capability |
| Cross-app | REST APIs (server mediated) | None | None | Capability tokens (direct) |
| Verification | HTTPS (CA-signed, central) | Infohash (no author sig) | Device cert (CA-like) | BLAKE3 hash + Ed25519 author sig |
| Cost | Server + domain + bandwidth | Tracker (optional) | None | None |
| Seeding | Server must stay up | User must seed | All peers are seeds automatically | Every peer is a seed automatically |
"Think of a namespace like a domain, but anyone can have one instantly for free. Instead of getting content from a server, you get it from other people who have already opened it. When you open something, your device automatically helps serve it to others -- like seeding a torrent, but automatic."
"Think of a document like a torrent that updates automatically. Instead of downloading a batch of files, you subscribe to a live folder. New content appears as it's published. Your device seeds everything you've ever opened, automatically."
"Think of OIN as Syncthing for the whole world, not just your devices. Folders can be public by default. Sharing is as simple as sending a link. Any app can participate, not just Syncthing. Permissions are granular -- read vs write."
"Think of OIN as IPFS that actually works. No heavy daemon. No slow DHT. No confusing pinning system. Content addressing with mutable documents that sync fast. Permissions built in. All the good ideas, none of the bad UX."
Instead of raw namespace IDs, the UI wraps links in a friendly format:
Display: "iroh://alice.social/blog/hello-world"
Resolves: iroh://<ns-id-hash>/blog/hello-world
Users can also share raw:
iroh://x3t7...9k4a/photos/beach
| Purpose | QR encodes | Result |
|---|---|---|
| Share a page | iroh://<ns-id>/path |
Receiving peer reads the page |
| Share write access | iroh+secret://<ns-secret>/<prefix> |
Receiving peer can write |
| Share a peer identity | iroh+peer://<node-id> |
Receiving peer adds to contacts |
| Icon | Meaning |
|---|---|
| 👁️ | Read-only access (namespace ID shared) |
| ✏️ | Write access (namespace secret shared) |
| 🔑 | Full admin (namespace secret + author key) |
| Indicator | Meaning |
|---|---|
| 🟢 Online + synced | Content up to date with all reachable peers |
| 🔵 Offline + cached | Content available from local cache |
| 🟡 Peers pending | Content exists but not yet fetched from peers |
| 🔴 Unavailable | No peer has this content (yet) |